Slow Win2K Performance After the Crash

Performance dies on this unnamed admin's Dell server, so Bill helps him trace the problem to driver chaos.

Bill: A Windows 2000 domain controller crashed with a blue screen of death earlier in the week and since then, it's been really slow. No, I didn't write down the error code.

Yesterday, the server started beeping constantly and there was an error message on the screen about a failed drive in the RAID array. This is a Dell PowerEdge with mirrored drives for the operating system and data. The RAID controller is a standard Dell PERC controller.

I called Dell tech support and they determined that the drive was functioning normally. They walked me through regenerating the mirrored set. Right now, the boot-time PERC controller management console shows a correct drive configuration with no errors.

But when I restarted after regenerating the mirror, the system hung for nearly a half hour. I restarted in Safe Mode and as the list of drivers appeared on the screen, the system hung at the Mup.sys driver. It's done this consistently ever since.

What's wrong? Do I have a bad drive? What is Mup.sys and why is it hanging?
—Anon

Get Help from Bill

Got a Windows or Exchange question or need troubleshooting help? Or maybe you want a better explanation than provided in the manuals? Describe your dilemma in an e-mail to Bill at mailto:boswell@101com.com; the best questions get answered in this column.

When you send your questions, please include your full first and last name, location, certifications (if any) with your message. (If you prefer to remain anonymous, specify this in your message but submit the requested information for verification purposes.)

Readers: I called Anon and we spent quite a while troubleshooting this problem. Here's what we did:

First off, I didn't suspect any problem with Mup.sys. This is the driver for the Multiple UNC Provider, which determines which network client protocol to use when the target server is specified by a UNC path such as \\Server_Name. During safe mode boot, the system displays each driver as it is loaded, so the fact that Mup.sys was the last driver on the screen prior to the system hang indicated that the problem was with the next driver.

Ordinarily, you can see the drivers loaded during a Safe Mode boot by looking at a file called Ntbtlog.txt. Because the server was hanging during safe mode, we decided to boot to the Recovery Console using the Windows 2000 Setup CD. This would also help us determine if there were a problem with the file system or the mass storage device driver.

As part of the Recovery Console boot process, we loaded a current copy of the Dell PERC controller driver that we downloaded from Dell's Web site. We were able to get logged on in the Recovery Console once Anon figured out the local Administrator password. The Recovery Console uses the Administrator account from the local SAM, which on a domain controller is the same account used for Directory Services Restore Mode (DSRM).

In the Recovery Console, we were able to read from and write to the drive with no slowdown or glitches, so that part of the system seemed to be working fine. There was no Ntbtlog.txt file though, indicating that the system was hanging before the file could be written to disk.

At this point, because the PERC controller console showed no problems and we were able to mount the drive using the latest PERC driver, I wanted to replace the driver currently on the operating system drive with the latest driver that we had downloaded. Anon wanted to do some more research before making changes to the system.

So, we started scouring the Internet looking for other possible causes. We found quite a few instances of the "hung at Mup.sys" symptom, but with a variety of fixes. Several administrators solved the problem by replacing memory. Several others solved it by replacing drive controllers or by simply moving the controllers to a different slot. One administrator even replaced both processors.

Then we found a posting by Sean Branham at the Annoyances.org web site. See the full text of the thread at http://www.annoyances.org/exec/forum/
winxp/t1047532372
. Sean correctly determined that the cause of all these disparate "hung at Mup.sys" failures were actually caused by problem with the Extended System Configuration Data (ESCD) stored in the system BIOS.

The ESCD maintains a static list of Plug-and-Play resource allocations. This avoids recalculating all the allocations at each restart. If the ESCD gets corrupted, then the operating system cannot assign resources correctly. Windows makes this resource decision just after it loads the Mup.sys driver because that's when it loads the Advanced Configuration and Power Interface (ACPI) drivers.

You can download the (mercifully short) ESCD specification from http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/escd.rtf.

Once we knew that something in BIOS might be causing the problem, solving it was a snap. We downloaded the most current firmware revision from Dell's web site and flashed the BIOS and that was that. (Some motherboards come with an ESCD rebuild option in CMOS, so it would not be necessary to flash the BIOS.) The system booted without a hitch and performance was right back to where it had been before the problems started. If it hadn't been for Sean's insight, we would have spent time and money replacing the PERC controller, which unfortunately might well have solved the problem because replacing the board would have refreshed the ESCD.

It's difficult to determine whether the system crash earlier in the week caused the ESCD problem or vice-versa, or if some other problem caused both. At this point, Anon is going to keep an eye on the system and hope for the best.

I'd like to thank Sean both for solving this tricky problem and for taking the time to post a detailed account. This was the first time I'd visited the Annoyances.org web site, and it looks like a great resource.

Hope this helps.

About the Author

Contributing Editor Bill Boswell, MCSE, is the principal of Bill Boswell Consulting, Inc. He's the author of Inside Windows Server 2003 and Learning Exchange Server 2003 both from Addison Wesley. Bill is also Redmond magazine's "Windows Insider" columnist and a speaker at MCP Magazine's TechMentor Conferences.

comments powered by Disqus

Reader Comments:

Wed, Feb 10, 2010 raggabones montreal

I had this problem before. i tried everything to save the information i didnt have backed up but finally i just gave up. I uninstalled and reinstalled windows. after that it worked fine!

Fri, Oct 16, 2009 CTerrian Atlanta Area

I had this mup.sys hang just recently. I figured it out myself, and download the updated bios from Dell. Many think it's the MUP.SYS file itself. It's really just where the computer hangs because of the ESCD.

Thu, Jan 15, 2009 Anonymous Anonymous

Good afternoon. Learning to live in the present moment is part of the path of joy.
I am from Ukraine and also now'm speaking English, tell me whether I wrote the following sentence:

Sat, Feb 9, 2008 Anonymous Anonymous

Excellent! This really helped where lots of other advice did not.

Fri, Nov 16, 2007 Jacob Anonymous

I have DEll Precision Workstation used as a server that just went down with this problem - solved it by going into BIOS and finding the function that resets BIOS to the way it was at factory. Most MBs should have this function.

Hoe this helps - it's certainly an easy fix if it works for you.

Wed, Dec 13, 2006 Neil Toronto, Ontario, Canada

This was a big help for me! Thank you very much!!

Tue, Aug 8, 2006 peter balazsy haledon nj

Dear Bill:
I was facing the miserable hang up in safe mode at mup.sys...etc too.
But though I appreciate your comments about ESCD and bios... I don't believe its exactly that.
I too read all those comments in the threads you mention at annoyances.org and gave it a long hard think.
I had a spare hard drive clone in my desk drawer that when I swapped it with the one hanging at safemode ... the clone ( from months earlier) booted just fine.
Yet the main "current" hard drive just hung there showing constant disk accesses... blinking on forever.
I felt it had to be a cruppeted file or registry problem

Sure enough when I ran Registry Mechanic 5.0.... and let it fix all errors... I was THEN able to boot in safe mode just fine.

Why( we all wonder)... did Microsoft build and sell an OS that has a registry... that is vulnerable to such failures??? and why doesn't Microsoft FIX it and make it bullet proof.
General motors and the like don't sell you a car and expect that you must carry a tool box in the trunk to get to work safely daily... so why do we live with this ?

Thu, Nov 10, 2005 Teitur Iceland

Thank you. Excelent article, well done and explained!

Sun, Aug 14, 2005 Ananth Tokyo

Been having the AGP440.sys & MUP.sys hang-ups on my desktop recently. Updating ESCD simply hasn't worked. My system hangs soon after POST and cannot boot into XP normally. Safe mode hangs at MUP.sys or AGP440.sys. System does not let me run recovery console or let me boot through a Floppy or CD. Booting from Knoppix has also led to system freezes after the KDE desktop loads.

Have tried various solutions from different sites with no luck. Pending options are changing Motherboard, Processor, and HDD. Frustrated with XP!

Thu, Jun 9, 2005 Eric Virginia, USA

I have the infamous "mup.sys" problem, but resetting the ESCD didn't do anything. In fact, I have replaced the mobo altogether (for different reasons) so the ESCD had to be reset--it was brand new! Still... this particular PC continues to cycle endlessly. So, sorry. You're "awesome" solutions is not universal.

Fri, Apr 8, 2005 Anonymous Anonymous

i just changed to a completely new motherboard, and still have the same problem hanging at mup.sys.
... explain that...

Sun, Mar 13, 2005 v Anonymous

will doing a hardware reset, ie changing the CMOS jumper settings to clear the CMOS do the same trick ? or is flashing the BIOS the best technique ?

Thu, Feb 3, 2005 Anonymous Anonymous

nice doc

Fri, Jan 28, 2005 Jim Chicago

Enormously helpful writeful. Thank you.

Thu, Jun 24, 2004 Peter Anaheim

Over 8 years of installing & maintaining Windows NT, 2000, XP, & 2003, Annoyances.org is one of the BEST sources for troubleshooting unusual Windows problems

Thu, Jun 24, 2004 Renzo California

Very insightful. Thanks for the great article.

Thu, Jun 24, 2004 Anonymous Anonymous

Excellent article Bill, as always!

Thu, Jun 24, 2004 BarefootBoy Anonymous

Awesome article!

I have a HP Pavilion 8670C w 384MB and Win2K SP4 which goes into rapid-fire crash/reboot cycles if I attempt to restart with a USB 2.0 40GB external hard drive attached (connected to USB 2.0 add-in card).

All I have to do to 'fix' the problem is disconnect the cable. The drive works perfectly (and is a fast backup solution) as long as I connect and dis-connect the drive while Win2K is running.

I can't wait to try this fix at home!

Thanks again!

JAy

Wed, Jun 23, 2004 GIJoey Sunshine State

Bill, I have seen many sites for t.s self-help, but yours is the best in laying each case in logical user-friendly manner. And today particularly, this article helps refresh my t.s technique&approach. I'll be busy resetting ESCD on a few of my servers which has been running very slowly. Thanks again.

Wed, Jun 23, 2004 Joel Washington D.C.

When a system hangs on MUP.SYS it is typically related to the ACPI settings. Many Default BIOS settings do not have ACPI enabled. If it is enabled after the operating system is installed then the system will hang at MUP.SYS. The only choice you have is to either turn it off, or reinstall the Operating System with it enabled. BTW in the past a change from single to multi processor required a reinstall (unless you knew how to change the HAL.DLL.) But with Windows XP, one of the only documented changes to a system which requires a complete reinstall, is the enabling or disabling of ACPI.

Wed, Jun 23, 2004 Anonymous Anonymous

I almost hate to say it, but "DUH..."...resetting the ESCD is ALWAYS a good first step in diagnosis...we have solved many many a problem just by doing this one step. Infact is standard procedure to do such a reset after any major operating system change such as Version Upgrade (2000 to 2003), Service Pack, Feature Pack, Security Roll-up, ETC as all of these might change how the system detects hardware....
As for the other fixes noted, notice they are all changes in hardware, which will typically cause the ESCD to reset itself as well, although we have seen this not be strictly true in the past, and have had to force the reset.

Wed, Jun 23, 2004 Anonymous Chicago

Great troubleshooting example. It's great to see people use their knowledge of systems to fix an issue instead of money to purchase a new hardware solution!!

Tue, Jun 22, 2004 Anonymous Anonymous

I have been seeing several Win2k machines preform slowly after crashing lately. What has been working for me is to go into the Safe Mode, change the Windows Installer Service to Automatic start, and then reboot the system. After the system has come up, return the Windows Installer service to manual and reboot the system once more. I have been having luck with this. This appears to happen frequently after Windows Updates and users installing software that the problem of the system hanging or crashing happens.

Tue, Jun 22, 2004 Anonymous Anonymous

Excellent real life trouble shooting example!

Tue, Jun 22, 2004 eman Orange County Ca

Awesome trouble shooting example. I'm a software developer, but appreciate the steps to resolve the challenge of hardware problems. Thanks for documenting the process, eman

Tue, Jun 22, 2004 Bob F Arizona

Awesome! ESCD has been a problem for me in the past as well, fortunately never on a server. Ever had a WinXP install fail because of an inability to read a particular file of the CD Install media? Give this ESCD reset trick a shot, and if that doesn't do it, try swapping the RAM.

Add Your Comment Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Comment:
Please type the letters/numbers you see above

Redmond Tech Watch

Sign up for our newsletter.

I agree to this site's Privacy Policy.