ISWIX, LLC View Christopher Painter's profile on LinkedIn profile for Christopher Painter at Stack Overflow, Q&A for professional and enthusiast programmers

Monday, November 21, 2011

The Curious Case of the Corrupted Characters

Recently I was shown a machine where the PowerShell cmdlet Get-WmiObject was failing to query the Win32_Product class.  The strange thing was that  WMIC path Win32_Process was working.

I almost wanted to blow this off as yet another example of how Win32_Product is broken but there was a catch: I could fix and break the behavior at will by uninstalling and installing the MSI I was working on.

I started to wonder how this could be.  I could only assume that there was some bad data causing casting problems in PowerShell ( COM interop is a pain ) so I decided to run MSI validation to see if it warned me of anything.

Sure enough, it did.  A big ICE24 error alerted me to a problem in the ProductVersion property.  Well, at least it tried to.  2.0.1600 sure looked like a valid ProductVersion to me.  For the life of me I couldn't get it to stop complaining about that value so I decided to export the Property table to an IDT file.  Sure enough notepad showed me a special character and a Hex editor showed me that there were actually two special characters corrupting my property.

I kept digging and found the root of the problem in the build automation NAnt file.   A text file was being created and loaded into a NAnt property using the loadfile elemnt.   Those two extra characters were coming along for the ride.

Let's see all the ways this could have been caught:

1) NAnt could have trimmed the property automatically.
2) ISCmdBld could have trimmed the property.
3) MSI Validation could have been turned on in the build.
4) MsiPublishProduct could actually enforce the required datatype of the property
5) The MSI WMI provider could trim the property.
6) The Get-WmiObject could trip the property or report a better error.

And of course, this post wouldn't be complete without me mentioning that there is a much better alternative to Win32_Product called the ProductInstallation class as found in WiX DTF's Microsoft.Deployment.WindowsInstaller interop.  It's a very nice encapsulation of the unmanaged MsiEnumProducts function and doesn't have the horrible performance problems that Win32_Product has.