Thoughts from the EPS Windows Server Performance Team
Hello AskPerf readers. My name is Scott McArthur and I am a Support Escalation Engineer with the Setup & Cluster team. I know you’re probably thinking that one of us has somehow found our way to the wrong blog! I recently ran into an interesting scenario while working on a customer issue, and since this has some impact on Application Compatibility, I figured AskPerf would be the best place to write about it.
The customer’s issue I was working on dealt with an application install failure on a 64-bit installation of Windows Vista. The application in question required Windows Vista Service Pack 1 as a prerequisite for installation, and the system administrator duly installed SP1 and then proceeded to launch the installation of the application. And then, a funny thing happened – the application returned an error, indicating that Service Pack 1 for Windows Vista was not installed. According to the Windows Update logs, the SP1 installation appeared to have completed without incident. Trying the installation of the application on another machine, the administrator found that he encountered the same problem on every Windows Vista SP1 machine. As Alice said, while in Wonderland, “curiouser and curiouser” …
It turned out that the problem wasn’t with the installation of Service Pack 1. The problem lay in the method being used by the application to check the OS and Service Pack version. The application was checking for the OS version in a registry value, specifically: HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\CSDVersion. On the x64 version of Windows Vista Service Pack 1, however this value does not exist. The correct value does show up under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\CSDVersion however. This highlights an inherent problem with relying on the registry method to capture this information. As operating systems evolve, there is no guarantee that registry information will persist between operating systems, or in some cases there may be changes between service packs for the same operating system.
When determining OS versions for application installs, a better method than reading the registry would be to either use a WMI query or to use an API. The GetVersionEx function is designed to retrieve this information and is not affected by change. One caveat though – if you are testing for whether a particular feature is installed, the GetVersionEx function would not be the best approach. With that in mind, below are some items returned by using this function that are specific to Service Packs:
And on that note, we’ve reached the end of this post. Thanks for dropping by!
- Scott McArthur
>> As operating systems evolve, there is no guarantee that registry information will persist between operating systems, or in some cases there may be changes between service packs for the same operating system. <<
True, but the issue you describe seems to be a case of a 32-bit installer running on an x64 version of Windows, and running into registry redirection, doesn't it? Or was the application coded to explicitly check for the value under Wow6432Node?
The issue is a 32-bit application running on an x64 version of Windows and checking for CSDVersion registry key... so you are right...
>> The application was checking for the OS version in a registry value, specifically: HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\CSDVersion.
I don't believe it was an 64-bit application trying to read this specific hive. Most probably it was an 32-bit application reading directly "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\CSDVersion", but Windows x64 did its virtualization magic and returned what 64-bit programs see as "HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\CSDVersion".
I can assure that reading this key ("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\CSDVersion") in Windows 2003 x64 (and Windows XP x64) from 32-bit apps works perfectly and returns the correct, expected, value (the same a x64 application will see).
So, in short, isn't there a bug in the virtualization of the registry done for 32-bit programs in Vista SP1?
Thanks for the post. I think this would be better served in a dev blog. I think the part that would be more useful to readers of this blog would be how you went about resolving this. I assume that once you saw this error you ran regmon and perhaps filemon to see what this app was accessing at the time and found that it hit this regkey and failed to retrieve it. After locating what regkey it was hitting i would imagine you could easily look up what it should contain, create it and insert the info the app was looking for in order to satisfy the apps system check.
There is a similar bug in the Windows Easy Transfer when migrating from x86 to x64 with Outlook as your default mail handler. It copies the handler to the 64-bit key instead of the Wow64 one, and so the Start Menu "Mail" entry ceases to work. Fun one to track down.
Won't the 'ver' command be useful in determining this? Can you not have a condition based upon that version information? Or would that not work?
I am using a AMD Athlon 64 A8N-VM CSM, what audio drivers should i download/use?
P.S. Another thing is, I would like to know how to check what service pack im using?
@Me: "Won't the 'ver' command be useful in determining this?"
Yes, but not very. It would be far preferable if Windows had an extended version of the 'ver' command that could return all sorts of versioning data. Like this: forum.sysinternals.com/extended-ver-command_topic23137.html I should probably add firmware related switches to that list, like ACPI version, which would be beneficial regarding some of the new power related functionality in Windows 8.
@Fawwaz: "...I would like to know how to check what service pack im using?"
Same point again.
Another easy way to check what service pack you have installed is to run the following from a command prompt:
wmic os get servicepackmajorversion