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!

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.

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?