I've been scratching my head about this one, and have googled around for answers, but didn't find anything interesting - I am sure it's probably a matter of my search terms at this point, but I hope someone out there knows why I am seeing this behavior.

I am looking to link an msi install to it's corresponding \Windows\Installer\msi_munged_file_name.msi. I use /l*vx logging to get the MSI install log, and I see an entry like this:

PROPERTY CHANGE: Adding DATABASE property. Its value is 'C:\Windows\Installer\1f219540.msi'.

And I watch as the file system does indeed get that file created. But, after MSI finishes, the file gets renamed. o_O

I've gone through 2 iterations of this, and both times the file has been renamed to what it was before +3 hex, I think. So, in this case I wind up with a file named:


I am curious as to why the rename happens, and if the algorithm is to indeed +0x3 the last character in the file name, or if this is just coincidence on my 2 runs so far.

I've used Orca.exe to verify that the file that results in C:\Windows\Installer is indeed my msi.

This is for research I am doing on Windows Installer, and I am trying to better understand the MSI/Windows Installer platform.

Thanks in advance!

  • I should add that there is no record whatsoever of the new file name in the setup log file I am producing via the /l*vx param to msiexec.exe.
    – joebalt
    Mar 3, 2014 at 21:18
  • the MSI files in folder C:\Windows\Installer\ are just cached versions of the original MSIs (basically a copy with all the actual files removed, so only reg keys, metadata and maybe custom actions). there is afaik no official documentation about the installer cache and there is nothing to gain playing around with it. btw the iteration problably happens because the file already exists
    – weberik
    Mar 5, 2014 at 10:04

2 Answers 2


I found a way to get what I needed. It appears that during an install, Windows Installer performs a "transform" on your product code - I found this referred to as a "packed GUID" - it's an odd (to me) reversal of sorts on the product code GUID. There are many references to this out there.

So, I wrote code to take a product code GUID, "pack it" to get to the key:

@"HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\" + 
                packedGuid + 

You can then read the value for LocalPackage and have your full path to the locally cached MSI file.

I learned a great deal about Windows Installer via this exercise.


Assuming you're using signtool, you have to include the option flag /d MyProduct.msi

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.