Why didn't XP SP2 install copy the right SP2 DLL when there was a DLL with a higher version number on the machine?

In yesterday’s post, I mentioned that SP2’s installation didn’t update a Longhorn version of the Windows Audio service, and that caused customer difficulties.

I left unanswered the basic question: Why on earth didn’t the SP2 upgrade modify the existing version?  My answer in the post was that since the version number of the file on the disk was higher than the SP2 version, it didn’t update it.   And that’s the case.  But the date on the file on the disk was back in October of 2003, while the SP2 version was August of 2004.  Why on earth did the XP SP2 setup take an older file instead of the newer one?

Well, it’s because the version number trumps file times.  This is actually a GOOD thing.  Microsoft often provides hotfixes to components and it uses the version number of the file to determine if the file on the local machine is “newer” than the one being installed.  If the service pack installation didn’t check for the version number, then it could potentially break something (service packs don’t always include all the updates for components).

It turns out that if you do a full OS install using a slipstream version of XP (a full install version of Windows XP with SP2 installed), then the full install WILL blast all the files, regardless of version, this is because a full OS reinstall is considered a “repair” install, and in that case, the user NEEDS to ensure that his OS is as close to the RTM bits as possible.

The better news is that this kind of a problem almost never hits real customers, since they don’t typically have access to incorrectly versioned versions of Microsoft DLL’s – our release team is quite good about ensuring that mistakes like that don’t happen.

And even if they do, it’s highly unlikely that they can get a bad version of the binary to stay on their machine due to system file protection (unless they’ve done things to their system that would cause SFP to be bypassed, which was effectively the case here (it’s too complicated to explain, but it’s related to the test root certificate)).  Btw, Raymond mentioned how to verify the signatures of your system DLLs here.