cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Does repackager have a problem with REG_QWORDS?

I think I've discovered a problem with Repackager and would appreciate it if anyone here could try to confirm (or otherwise) what I have found. The packaging environment is a virtualised (on VMWare) 64bit Windows 7 and I am using snapshotting.

Any registry value of type REG_QWORD gets picked up by repackager irrespective of whether or not it has changed between snapshots. Furthermore, repackager reports these values as of being of type REG_SZ.
These REG_SZ keys then get included in the repackaged .msi. So, it is conceivable that a single .msi could change EVERY (or at least, many) REG_QWORD in the registry to REG_SZ and this may lead to operating system corruption. One example of where this definitely happens is with the following key

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide]
"PublisherPolicyChangeTime"=hex(b):5d,38,a3,58,e0,f9,cb,01

This key is in my repackaging image as a REG_QWORD value. If I launch repackager and perform two snapshots (without changing anything), repackager reports it as a REG_SZ value. The resulting .msi will, on installation, actually modify this key to a REG_SZ and corrupt the operating system.

I initially thought that this was a problem with a particular package (notepad++ - see http://community.flexerasoftware.com/showthread.php?t=199811 ) but now realize that it is a more general problem.

As another demonstration, I created a REG_QWORD value at HKLM\SOFTWARE\mike_test BEFORE launching repackager

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\mike_test]
"test123"=hex(b):45,23,01,00,00,00,00,00

I then launched repackager, took two snapshots and observed that this key is reported as a REG_SZ value. I did not change it in between taking the two snapshots.

Whenever you take two snapshots on a clean system, you always expect a certain amount of operating system noise. However, it turns out that much of what I thought was 'noise' was actually just a lot of unchanged REG_QWORDs that get picked up in this manner.

Best Wishes,
Mike
(3) Replies
Tried it the way you described:

result in the NIR file:
[HKEY_LOCAL_MACHINE\SOFTWARE\JEROEN]
"test"=hex(11):67,45,23,01,00,00,00,00

But it should have been:
[HKEY_LOCAL_MACHINE\SOFTWARE\Jeroen]
"test"=hex(b):58,76,00,00,00,00,00,00

But this aint't working either... it still writes a REG_SZ

I guess this hex(11) should have been a hex(b) ??

Nevertheless, this seems to me as a bug!
REG_QWORD is also not supported in IS2011
Alpesh
By
Flexera Alumni
Hi,

I believe that the Windows Installer itself does not support REG_QWORD. Please look at the values that Windows Installer supports --> http://msdn.microsoft.com/en-us/library/windows/desktop/aa371168(v=vs.85).aspx.

I hope this helps.

Thanks!
Thanks for that Alpesh. I have a couple of comments:

- The most serious bug is that repackager (in snapshotting mode) 'captures' several REG_QWORD registry entries that have nothing to do with the application being packaged and coverts them to REG_SZ. The resulting .msi can corrupt the target machine. I think that support for REG_QWORD in Windows installer is irrelevant as far as this bug is concerned.

- I was worried about packaging applications that explicitly set a REG_QWORD as part of the installation process. Your observation that Windows Installer itself does not support REG_QWORD leads me to believe that I might be worrying unnecessarily. However, I have written some scripts to detect REG_QWORD activity just in case.

Cheers,
Mike