Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Bug in BVariantCopy() in src/burn/engine/variant.cpp #4609

wixbot opened this Issue Nov 25, 2014 · 6 comments


None yet
2 participants

wixbot commented Nov 25, 2014

There's really two bugs here, with the same root cause.

Bug #1: If you declare a variable as hidden and supply a default value (even if it is the empty string) you cannot change the variable's value (either from the command-line or from a BA) without incurring an error when you subsequently try to retrieve it (including when serializing from the UI engine to the Apply engine).

Bug #2: If you don't supply a default value to a hidden variable, it will actually be stored for most of its life in plaintext (it is encrypted and immediately decrypted).

The problem occurs because BVariantSetEncryption() assumes that the variant passed is correctly marked as to whether it is already encrypted or not, and that the fEncrypt flag is a "command", while what BVariantCopy() effectively passes to it is the opposite (in almost every case pSource is not encrypted).

What that method should instead do is preserve the value of pTarget->fEncryptValue, set pTarget->fEncryptValue = pSource->fEncryptValue, then pass the preserved value from pTarget as the "command" flag to BVariantSetEncryption(). That would result in the desired behavior in all cases.

The workaround for the failure to retrieve the "hidden" values is to never set a default value in the bundle authoring.
There is no workaround for the plaintext in memory storage of the variable's value.

Originally opened by bmurri


wixbot commented Dec 3, 2014

Bug reproduces on three separate installers. Bundle installs fine, but attempts to Repair, Uninstall, or Upgrade are met with an access error when a connection string variable marked with the Hidden attribute is accessed. The Hidden variable has a Value attribute for a default.

Workaround was to remove the Hidden attribute. Less than ideal, but it will work for now.

Originally posted by jmcooper8654


wixbot commented Dec 5, 2014

Originally changed by rseanhall
AssignedTo set to shall


wixbot commented Dec 5, 2014

Wix3 pull request: 184.

Wix4 pull request: 77.

Originally posted by rseanhall


wixbot commented Dec 11, 2014

WiX v3.9.1208.0, a candidate for the WiX v3.9 R2 servicing release with this fix, is now available. It's not publicly visible on the list of weekly releases but you can get the installer at http://wixtoolset.org/downloads/v3.9.1208.0/wix39.exe. Please take a look and see if that release fixes your problem. If we don't hear back by 21-Jan, we plan on releasing v3.9 R2 shortly thereafter.


wixbot commented Dec 18, 2014

I have performed the following tests:

  1. Validate Build and Install with Beta R2

  2. Validate Build and Upgrade with Beta R2

2A) Validate Repair with Unmodified Bundle

2B) Validate Uninstall with Unmodified Bundle

  1. Validate Build and Install with Hidden Attributes on Both ConnectionStrings with Beta R2

  2. Validate Build and Upgrade with Hidden Attributes on Both ConnectionStrings with Beta R2

  3. Validate Repair on Modified Bundle with Beta R2

  4. Validate Uninstall on Modified Bundle with Beta R2

Previously, I would see signs of the bug on repair, uninstall, and upgrade. I have not been able to replicate, so 1208 (Beta R2) looks like a fix.

Originally posted by jmcooper8654


wixbot commented Jan 22, 2015

Originally changed by rseanhall
Resolution set to fixed
Status changed from Open to Resolved

@wixbot wixbot added bug burn labels Dec 20, 2015

@wixbot wixbot added this to the v3.9 milestone Dec 20, 2015

@wixbot wixbot closed this Dec 20, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment