SP4 onto Win2K SP2 machines?

[swright]

We have over 100 Win2K SP2 machines that were installed using an unattended steup. We now have a working SP4 slipstreamed setup for new PCs, but are trying to bring the existing machines up to SP4. We are seeing about 25% of them experiencing unexpected bluescreens after the reboot.

In some cases, swapping drive into a working SP4 PC and copying all DLLs from system32 solves the problem, but not always. In some cases, we don't get a bluescreen - jsut a reboot just before the login dialog appears.

Has anyone encountered this?

[diesel_98a]

let me get this right, after installing the win2k unattended, u then install the sp4 update? is that correct.

[gosh]

How about troubleshooting? Copying all the system32 dll's isn't really a good way to troubleshoot a problem. Boot into safe mode. If that works, use sigverif to isolate the faulty driver. Search support.microsoft.com on the blue screen error to see the common causes. Use xp's msconfig to do a clean boot. Basically, do the basics.

And you didn't say if all 100 pc's are using the SAME image. Usually when erratic problems happen, people are using different images. Make sure all the computers are using just one image.

Troubleshooting isn't finding a reghack or file to fix a problem. Troubleshooting involves isolating the problem, and attacking the problem in a linear fashion. Looking for a quick fix or reghack isn't troubleshooting.

-gosh

[techtype]

Yes, you could do all that gosh suggests (She's almost always on target). Or if you want to spend a few bucks and save some time go here:

Blue Screen Analysis

As always YMMV.

[swright]

Ok, a bit more details. My first post was deliberately brief, as I just found this board at the end of the day, and wrote in haste before leaving the office.

1. Machines are all win2k installed unattended from an SP2 slipstream load, most of them a year ago or more. Some were SP0 unattended, with SP2 added later. Most were SP2 unattended right from the start. In every case, groups of machines were from the SAME unattended load.

2. We then took groups of machines with identical hardware and software in a lab. As they are very secure, with no read/write access to users, we can be quite certain they are as close to identical as possible. Everything is scripted right down to the last common app we install.

3. We then install SP4 from a custom in-house maintenance service using switches -q -u -z only, and following with postSP4 hotfixes up to Jan04. The maintenance service runs in the context of a local admin, and allows us to schedule these updates after hours.

4. Some examples: a group of 21 Dell P4s, 5 of them blue screened, the rest were fine. As time was limited and we need to get the machines running, little time could be spent tracing the problem. Two different driver files (don't have the names handy, but they were stock MS drivers) were named, so we tried coping them off a known working machine and it worked.

5. Next group, tried several more one by one and thought we had it cured, by removing extra hotfixes and allowing the SP4 update to perform the reboot, using only -q -z options. Then tried a group of 20 Dell P3s in a lab, and had 4 that bluescreened. Different driver names again. Tried copying DLLs, and some worked, some didn't.

6. Two more smaller groups of machines done since then with similar 25% failure rate, but now were seeing plain reboots just before the login dialog appears, with no sign of blue screen. Copying files off identical machines that worked is again successful in half of the cases.

I know it would be nice to have the time to go about this in a more methodical manner, but the fact is this: we have only seen ONE failure during an interactive setup, and that was on a machine with a Dell OEM load, not one of ours. We CANNOT reproduce this at will, at least not without testing at least 4 machines, and even then, the dead machine provides us with little in the way of clues. We can't afford to have machines down for long, so when it does occur on live machines, we have to take the quickest route to a solution, which is often our slipstreamed SP4 load. I never thought NT/Win2K would reach this Win95 level of flakiness, but we seem to have induced it somehow. By flakiness, I mean this particular problem, not in general. We have very few problems with BSODs in general, probably one every few months on 200 machines, usually due to bad hardware.

[Miphnik]

This sounds very much like the Ordinal 175 error I have experienced under the same circumstances.

I use a 3rd party utility to push SP4 out to many computers. Pushing it out to 97 computers ended up with approximately 15 giving a error box with an "Ordinal 175" error. Rebooting the computer proved no adverse effects except for 2 machines. These 2 machines stayed in a reboot loop.

I did some research at the time and while I can't remember the exact files the meat of it was that somehow during the update one of the files didn't reflect the upgrade to SP4 from SPx. The fix for the reboot loop was to boot to DOS and navigate to the directory with the SP4 uninstall files and uninstall it, reboot back into Windows should have you back to the SP level previously. Reapply the SP4.

My apologies if this is vague. I haven't had to deal with the issue in many months and my notes on the subject are buried in my books at work.

Regards.

[swright]

Thanks for this info. We have seen the Ordinal 175 message also, but not as often. We have tried re-applying SP4 in safe mode, but did uninstall the SP4 first, so perhaps will try this method on the next one. As it happens, we are getting near the end of machines needing the SP.

I don't like the fact that we need to RELOAD nearly 25% of our machines just to apply a SP!