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.


Comments (9)

  1. Anonymous says:

    SFP is a good idea with one major caveat: if you need to kill a certain subset of files, such as microsoft messenger, outlook express, or some odbc files, you only have two choices. You can file-by-file remove each file from the dllcache folder, or after a couple of times of doing this, wipe the entire folder and make your changes freely. If it was organized in a tree mirroring the system files it protected, it would be much easier to surgically remove components. (Aside from the system32 mess.)

    It also annoyed me that neither XP+SP2 slipstream nor .Net framework 1.1 installed the msvcr7x.dll and msvcp7x.dll files, forcing me to hunt them down online. o.O

    Random rant, not directed at you or anyone in particular.

  2. Anonymous says:

    One thing that I always wondered is why SFP wasn’t implemented at the VFS layer. Having two copies of every DLL seems like a remarkably ugly hack – would it not have been better to have the kernel simply silently drop the file operation and return STATUS_SUCCESS when attempting to overwrite such things (with some kind of back door so correctly signed MS updates could overwrite it).

    SFP as it stands is rather racy and inefficient.

  3. Anonymous says:

    Mike, I don’t know the answer, I didn’t do SFP.

    I suspect a lot of the reason is that we didn’t want to prompt the user for their XP CD whenever we found a system file had gone missing.

  4. Anonymous says:


    What does audio service is for anyway. Windows NT/XP has tones of services with very poorly documented (if any) features descriptions. I usually try to disable services until I run into trouble, and then I enable them back ;).

    But seriously, a service comes with the description “if you disable this service you audio/video/entire system will not run”, and when I disable this service everything continues to run. I understand that some functionality is gone now, but apparently, I never needed it. Would MSFT provide a better description?

  5. Anonymous says:

    A REALLY good question Dmitriy. That’ll be todays post 🙂

  6. Anonymous says:

    8/18/2004 2:57 AM Mike

    > would it not have been better to have the

    > kernel simply silently drop the file

    > operation and return STATUS_SUCCESS

    Would it not have been better to have the kernel noisily drop the file operation and return a status saying permission denied? This kind of protection is just about the entire purpose of error returns and the entire purpose of file permissions, is it not?

  7. Anonymous says:

    SFP doesn’t work at the filesystem layer because it would slow down every file operation while the code checked to see if the file being opened is one of the protected files.

    So the 99% case would be slowed down for the 1% case.

  8. Anonymous says:

    SFP is done in a simple way. There are a few threads in Winlogon that watch for directory change notifications. The purpose of dllcache is quick file restoration rather than validation. It just attempts to do the restoration in a silent way (not asking the user to insert the cd).

    There’s also a size limiation on dllcache, so not all files have a dllcache copy. The cache can be managed by "sfc /purgecache" and "sfc /cachesize=x".

    IMHO SFP is too silent. Sometimes it just restores files to some old (inconsistent) versions without notifying the user, and this may cause other strange problems that are hard to troubleshoot.

Skip to main content