M55e fails to access safe mode: your view requested
Posted: Sat Jul 21, 2007 2:52 am
My M55e ceased to operate in safe mode. Whenever I try, the system fails following the sucessful run of Mup.sys, and the pc reboots. I tried all kinds of solutions, none worked. Both MS and IBM support suggest reinstallation of winxp pro (sp2). I keep resisting, since the reinstallation of the os will require many more software installations.
Yesterday, I got the following suggestion from a source I deem reliable (http://radified.com/cgi-bin/yabb2/YaBB. ... 84927711/0).
The suggestion is as follows:
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/ ... 23143f3456 c/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.
1. Does this solution (corrupted ESCD) sound sensible?
2. If so, how to I replace my ESCD?
Ran
p.s. Please be aware of the fact that my problem isn't identical to the one reported. While my system fails to continue its preset route and opts for a reboot, the reported solution deals with a situation in which the system reached exactly the same point, but the system froze.[/url]
Yesterday, I got the following suggestion from a source I deem reliable (http://radified.com/cgi-bin/yabb2/YaBB. ... 84927711/0).
The suggestion is as follows:
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/ ... 23143f3456 c/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.
1. Does this solution (corrupted ESCD) sound sensible?
2. If so, how to I replace my ESCD?
Ran
p.s. Please be aware of the fact that my problem isn't identical to the one reported. While my system fails to continue its preset route and opts for a reboot, the reported solution deals with a situation in which the system reached exactly the same point, but the system froze.[/url]