Incorrect system file replacement

[Terry Rasmussen]

I just experienced a problem with Setup Factory 6.0.1.2 that has me very concerned.

I am distributing an application that includes MSVCRT.DLL (version 6.1.9359.0, dated Oct 30, 2001). A user installed this application on his XP service pack 1 machine and rebooted. Upon restarting, Windows reported a problem (could not locate dll entry point in msvcrt.dll) in "lsass.exe" and "services.exe". After that, Windows would not continue to load.

I tracked the problem down to this: The version of MSVCRT.DLL that was on his machine (version 7.0.2600.1106, dated Sept. 18, 2002) was over-written with the earlier version of the MSVCRT.DLL that I was distributing. (Thankfully I was able to restore to the newer version of the DLL to get him back up and running.)

I have verified that the MSVCRT.DLL I am distributing has the "Overwrite if existing file is same or older" destination property in Setup Factory; therefore the existing MSVCRT.DLL should not have been overwritten.

Admittedly, this same application/setup has been used hundreds (perhaps thousands) of times previously by other users without this problem occurring; but it is very disconcerting. Even if this problem occurrs only a fraction of the time, it could still render several user machines impotent.

Does anyone have a clue as to why this could happen?

Thanks!

[Darryl]

I looked into the situation and have figured out why this is happening for this file.

I'll first explain what steps are taken when determining whether or not a file should be replaced.

The first comparison is between Product Versions in the file's resources. If product versions are the same, then a comparison is done on the File Version. If no version information is found, then the date information is compared.

On Windows XP SP1, the file version is 7.0.2600.1106 however the product version is 6.1.8638.1106 in the file's resources. I'm not sure what the product version is for that particular version of MSVCRT.DLL that you are distributing, but the XP one is likely earlier for what ever reason.

So that is what I believe is happening in this case and how the comparisons work currently. I've logged a report for our developers to investigate further as far as file comparisons are handled.

[Darryl]

I also wanted to make another note. If I'm not mistaken, the file MSVCRT.DLL is considered on Windows ME, 2000 and XP to be a core system file that is distributed by the OS and therefore protected by the Windows File Protection. I believe that file in particular can only be updated through Service Packs or other MS updates, and shouldn't be distributed in general to those OS's.

It does surprise me that the OS allowed that file to be replaced and wasn't automatically replaced by the cached copy, which should normally be the case.

[Terry Rasmussen]

Thank for the information Darryl - it was most helpful.

FYI, both the product and file versions for the MSVCRT.DLL that I am distributing is 6.10.9359.0 (although the Windows XP Properties window lists it as 6.1.9359.0). Since the product version on my distributed DLL is higher than the XP DLL, perhaps this is where the problem is coming in. (I would be most interested in hearing why Microsoft branded these product versions as they did!)

(I quickly looked at my XP SP1 version of the MSVCRT.DLL file I have on my machine and the file version is listed as "7.0.2600.1106 (xpsp1.020828-1920)" and the product version is listed as "7.0.2600.1106". I assume you are determining these versions in a different way? I am simply using Windows Explorer and the Properties window.)

Thank you for the protected file advice as well - I'll be sure not to distribute this file on ME, 2000 and XP machines.

I, too, am curious why Windows allowed this file to be over-written; at this point I'm going to assume Windows experienced some sort of problem on the affected machine, because I have had plenty of other XP machines that have installed the app just fine.

Please keep me posted on anything your developers have to say about the situation. Thanks again!

[Darryl]

You may want to double check the information I provided about the file being a core system file that is protected on those OS's, but I believe this is true.

As for the product version, yes I did notice that if you just go to the properties of the file through Explorer, it doesn't display that version information, so I'm not quite sure where that information that is displayed there is taken from.

We definitely look directly at the files resources programmatically and besides the information displayed in Setup Factory, I used the Dependency Walker (Depends.exe) which is available in Visual C++ of Visual Studio to look at the the version information and it did display the same as Setup Factory, so that is how I came to that conclusion.

It's definitely something that will be looked at by our developers to see if what is being checked should be changed. I'm a little hesitant to suggest a change in a subrelease due to the way this will affect installs that people have created already. If a change is warranted, it may be better to do so in a major release, however I'll let the big boys make that decision.