Close Encounters with AppVerifier

With the release of one of our products, one of the customers came to a standstill.  Obvious reason was the new version couldn’t sustain on older platform Win 2003.  The mixed mode application died before it could start. Thinking it could be a slam-dunk bombarded the entire arsenal available including following.

•  Use of certified vcredist_x86  (VS2008 SP1) (target machines were still 32bit)
•  Removal of older registry
•  Windows patching
•  Manually copying VC libraries (CRT,MFC etc) from working machine into target Win 2003 winsxs folder.
• Interestingly older version of the product works fine, so verified all binaries closely with versions and their dependency.
• Tried with comparing outputs of Process monitor, but log outputs of working and non-working were almost same, no clue.
• Installed .NET4.0 x86 , although required was only 3.5 SP1

The documents said recommended was .NET3.5 SP1, but I as per my knowledge the CLR loaded with the application was 2.0. Of course .NET 3.5 SP1 still holds CLR2.0. This was replicable on all Win 2003 machines, and I still had no clue how to go about this issue.

Not even Windbg gave any clues, the stack just died before it could load any useful information. Since App could not start it was difficult to attach a debugger. From search I could get some info using Gflags , so I set the Gflags pointing the .exe under image options and then checking the debugger and its path.

Now when I click the .exe , Windbg pops up and it loads the first DLL. Using next go commands a few DLL’s been loaded, but at one point loading a third party DLL, it threw AV c0000005, and unloaded DLL. That’s it. Still in no man’s land!

After few more searches, I came across MSDN WIT blogs, which used AppVerifier and thought to give a try. Although I had just seen this once,  but never used it. Attached the filename of exe to AppVerifier and checked few basic options. Checking the logs showed nothing, but same old access violation error. Decided to check all possible options, and voila!!  The app started! 

So something had done the trick. Now it was time to uncheck one by one settings, and catch the culprit (insane, he is the hero for me) who made it work. Surprisingly its HigherversionLie which makes it work on Win 2003. MSDN showed the HigherversionLie is used for integration testing , and this one actually raises the Major/Minor version to +2 while testing. So in all it seemed the app was trying to find version of OS before startup using GetVersion/GetVersionEx possibly and failed if it returned < 5. Since HigherversionLie raised this bar with +2 , it worked! Rest all in Dev hands to check..Good night, and yes Merry Christmas – Happy Holidays…