Windows XP Service Pack 3 – Part 2
Why was SP3 taking 12 minutes to shutdown:
As mentioned in Part 1, only a few small applications were installed on an otherwise clean machine. Below are the trouble shooting steps I took and the results which are somewhat surprising and puzzling.
1) Checked the Event log for any indications of a shutdown problem. None found but it was obvious from the time stamps on the log entries that there was a 12 minute delay between that last entry when shutting down and the next entry in the log created when Windows restarted.
2) Using ‘Task Manager’ I shutdown processes that I though might be cause of the problem. No luck as the shutdown still took nearly 12 minutes.
3) Using msconfig’s ‘Startup’ tab I unchecked all the items listed, exited msconfig, did a warm reboot/restart of the PC, waited the usual 12 minutes for the reboot to take effect, logged on, waited a few seconds and the once again shutdown the PC. Again no luck, even with nothing checked in the ‘Startup’ tab it still took 12 minutes to shutdown.
4) Tried booting to ‘Safe Mode’ and then shutting down, once again the PC took 12 minutes before powering off.
5) Last resort, Microsoft’s free SP3 technical phone support. Told the technician all the steps I had taken prior to calling including the applications I installed. He took msconfig one step further, in that he had me use ‘Selective’ startup and removing the check marks for: ‘Process SYSTEM.INI File’, ‘Process WIN.INI File’, ‘Load System Services’ and ‘Load Startup Items’. Then in the ‘Services’ Tab placing a checkmark in the ‘Hide All Microsoft Services’ box, and then clicking the ‘Disable All’ button (which effectively stops any non Microsoft services and ‘startup items’ from loading or starting the next time I booted the PC). This means the next time I booted the PC it would be as close to a bare bones OS as possible. So with tech support still on the phone, I shutdown the PC, rebooted and again shutdown the PC, once again there was a 12 minute wait for the PC to shutdown.
6) Technical support then suggested that I remove Norton Ghost and Zone Alarm. Since this would take time as I wanted to remove one application at a time, in order to determine which of the two applications may be causing the problem, I told the technician there was no need to wait on the phone and that I would call back using the same case number to report what I found.
7) Since I had no reason to believe that Norton Ghost was the cause, I decided to uninstall Zone Alarm (ZA), which was the latest free version (7.0.483.000) and reportedly fixed an earlier problem with Zone Alarm and SP3 where ZA blocked all access to the Internet and version 7.0.483.000 was released to fix that problem. After uninstalling ZA the shutdown problem was gone, it now took only a few seconds for Windows to shutdown. Note: I tried booting and shutting down several times just to be sure the problem was gone for good.
8) I was now curious as to what part of Zone Alarm caused the slow shutdown, so I reinstalled ZA but even though Zone Alarm was installed and working the shutdown problem was gone. Still determined to find the problem with ZA I used Ghost to restore and image backup I made after installing SP3 fully expecting that since the problem was present when I created the image backup it would now be back when I used Ghost’s restore CD the restore the image. No such luck, the restore worked but the ZA slow shutdown problem was gone. How could this be, did Ghost only restore any missing or changed files, an image restore is expected to replace everything on the drive (Windows partition) with what is contained in the image file. So I went one step further by using the Windows Install CD to delete the C: partition, create a new partition and perform a “Full Format”. Now there was nothing on the partition for Ghost to reuse (if it ever did) so I performed another restore using the same image file as before. Windows booted just fine and once again there was no delay in shutting down the PC. So I decided to put this issue aside for the moment and continue with my original goal of installing Windows XP SP3 using method #2.
Installing SP3 (Method #2)
Brief review of method #2:
1) Perform a “Clean Install” of Windows SP2.
2) Activate Windows
3) Skip the installation of any SP2 Updates available on the Windows Update web site. This means that SP3 will for all practical purposes be immediately installed on top of a clean install of Windows SP2.
4) Install Windows Service Pack 3 using the SP3 download .exe file.
5) Create and image backup which will be used for comparing the results of the two methods of installing SP3.
The installation of SP3 again took about 20 minutes. When the SP3 progress bar reached completion I was once again prompted to restart the PC to finish the installation. This time it took a relatively short time for the PC to reboot and was again prompting me to make the choice to turn Automatic Updates on or off, I again choose “Off” and then logged on. Once again I checked Device Manager, all devices functioning properly. Was curious to see if the long shutdown problem would reoccur, it did not as the PC shutdown in a few seconds. So was the Zone Alarm problem just a freak quirk???
The next step was to compare the files installed on the PC using Method 1 against the files installed using Method 2 and see if the results of the two ways to get to Windows XP Service Pack 3 were identical. As mentioned before for this task I would use a utility named Beyond Compare.
First I extracted the Windows folder from the each of the two image backups (As mentioned earlier the backups were created after the completion of each method of installing SP3) to their own unique folder located on the hard drive’s second and third partitions.
Comparing the results of the two installation methods:
Next I configured the rich and somewhat time consuming options in Beyond Compare to display the file differences between the two methods. It should be noted that Beyond Compare has both CRC and Binary methods to compare two files of the same name and I tried both methods individually in addition to checking file sizes and versions.
What was surprising (after excluding files that obviously would not be the same size as in .log and event files) is the fact that while all but a very few files of significance were different there were a large number of files (most located in the Windows\System32 folder) that were the same file size, same date and timestamp and had the version numbers matched but the CRC values did not match.
Also a significant number of the Method #1 files did not have any version number but the file size was the same as the Method #2 files which did have a version number but not always a matching CRC value. A large number of these files were located in the C:\WINDOWS\System32 folder. Of note is the fact with Method #1, that 9 of the files located in the C:\WINDOWS\system32\Drivers folder had no version number, but with Method #2 they had version numbers, and a total of 51 files in this folder did not match for one reason or another.
If you used the CRC values then most files matched. There were a few Method#1 and Method #2 files that were the same version, same file size, same date and time stamp but the CRC did not match. When using a Hex file viewer you could see there were differences.
If you only used the version number as a means of comparison, (when a version number was available for both files of the same name) then nearly all the files matched.
It was not uncommon to see results where both files had the same version number, the same file size but not the same CRC value.
Finally, if you based your results solely on matching file sizes, then only three files did not match, which I will identify below.
1) CAPICOM.DLL – A newer version (2.1.0.3) was installed using method #2. Platform SDK Redistributable: “CAPICOM can be used to digitally sign data, sign code, verify digital signatures, envelop data for privacy, hash data, encrypt/decrypt data and more.”
http://www.microsoft.com/downloads/details.aspx?FamilyId=860EE43A-A843-462F-ABB5-FF88EA5896F6&displaylang=en
2) COMCTL32.DLL – Method #1 had no version number when using Beyond Compare or simply selecting the file and viewing the properties. Method #2 had a version 5.82.2900.5512
3) DSNAPI.DLL – Method #1 had a version 5.1.2600.3316 and Method #2 5.1.2600.2180
Note that Explorer.exe also had differences – 6.0.2900.3156 (General Distribution Release) versus Method#2’s 6.0.2900.2180 (Release To Manufacturing) version.
Conclusion:
Although every attempt was made to insure that the results of using the two methods of installing Windows Service Pack 3 would be identical, they were not. Most puzzling was that fact that a significant number of files did not have version numbers when checking the files properties. So how SP3 knew which files to update and those to leave “as is” remains a big question mark.
Would a typical user’s PC which had SP2 installed and the large number of Windows updates that were downloaded and applied over time end up with a PC that fell short of containing all the proper files after upgrading to SP3? Remember as mentioned earlier a significant number of the Method #1 files after applying SP3 did not have any version number and Method #1 was designed to simulate a typical user’s PC after a clean install of Windows XP SP2 and using Windows Update.
|