topic Re: Bug Check 0x8E: in Windows Server 2003

Bug Check 0x8E:

Francesco_62 — Mon, 06 Dec 2004 08:38:57 GMT

ProLiant ML530 G2, win2300 with 3 HD 72.8GB in Raid5 with SO.
Other 2 Hd 72.8 gb in Raid 1.
Smart array 640 192mb.
Problem:
During normal operation , this crash with Bug Check 0x8E: KERNEL_MODE_EXCEPTION_NOT_HANDLED.
We have replaced:support memory Card ,Main Bord,Smar Array with cache.

Re: Bug Check 0x8E:

Chris Ciapala — Mon, 06 Dec 2004 08:50:34 GMT

Its impossible to say for 100% what caused this. Most propably faulty driver. I'd say - upgrade firmware for everything you can find, same for drivers and run diagnostics from SmartStart CD.

Re: Bug Check 0x8E:

Roger Faucher — Mon, 06 Dec 2004 22:30:51 GMT

FrancescoL

Krzysztof has the right idea. Install newer items from here:

http://h18023.www1.hp.com/support/files/server/us/locate/69_3991.html

Start with BIOS and firmware (read directions carefully!), the PSP (Proliant Service Pack), drivers, etc.

Make a great day!

Roger

Re: Bug Check 0x8E:

Francesco_62 — Tue, 07 Dec 2004 06:22:22 GMT

The last softpack,bios and smart array firmware is already installed .(see attachment)
Have you another good idea ?

Re: Bug Check 0x8E:

Chris Ciapala — Tue, 07 Dec 2004 06:26:48 GMT

Still it looks for me like driver running in kernel mode. How about antivirus/backup/imaging software? Are you using something like this? Can you possibly make a photo of BSOD screen? Often there are references to driver file what can give you an idea what caused BSOD.

Re: Bug Check 0x8E:

Ron Kinner — Tue, 07 Dec 2004 09:50:31 GMT

If I read the BugCheck page correctly you have encountered a hard coded break point. This tells me you have some software where a developer forgot to remove a break point so I am not surprised that replacing the hardware had no effect.

Go into the Control Panel and select the System Icon then Advanced then Startup and Recovery. make sure Write an Event to the System Log is checked and change the box under Write Debugging Information to Small Memory Dump (64K) then OK.

This should cause it to write the BSOD message to the System Log and also to create a minidump file in the Minidump folder under Winnt. If you right click on My Computer and select Manage a new screen will appear. Select Event Viewer then System and you will find a list of system events. Look for those with a red mark and double click on them to open them. If you find the one that talks about the crash then you can copy it to the clipboard by pressing the bottom of the three buttons and then reply to this thread and use Ctrl + v to paste it into the reply. Post one of the minidump files here as an attachment and I will try to read it or you can follow the instructions at:

http://support.microsoft.com/default.aspx?scid=kb;en-us;q315263

Ron

Re: Bug Check 0x8E:

Rune J. Winje — Fri, 10 Dec 2004 04:14:07 GMT

Doing a crash-dump analysis on the affected server (assuming it is takes some time before it bluescreens) is the preferred method.

DIY-crashdump
-------------
(also described in the doc Ron linked)

1) Download and install latest Windbg
http://www.microsoft.com/whdc/ddk/debugging/default.mspx

2) Make a catalog C:\DEBUG

3) Start Windbg and write the path from step 2 (File - Symbol File Path..):
SRV*c:\debug*http://msdl.microsoft.com/download/symbols
(Internet access is needed so symbol files can be downloaded as needed)

4) Open a crash-dump file(either MEMORY.DMP or a minidump WINDOWS\MINIDUMP\*.DMP

After downloading MS symbols and chewing through the crash dump you will get a line with "Probably caused by "

5) If you want to analyse more than one minidump for example I've found it necessary to exit the program completely and then go directly to step 4 (symbol file path is saved)

This analysis is not 100% reliable since Microsoft does not have symbol files for 3.rd party software/drivers - but often it can give a good indication. Usually if it suggests a 3.rd party driver it is correct. If it indicates NTOSKRNL or similar os-files it can still be a 3.rd party driver that calls kernel functions - but that does of course make it more difficult to identify the offending driver.

The reason for running the analysis on the machine with the problem is that it then is 100% identical to the machine having problems. Running the crash dump analysis on another machine is possible but generally lowers the reliability of the result since any difference in installed software/hardware makes the memory addresses in the crash-dump not match.

Cheers,
Rune

Re: Bug Check 0x8E:

Francesco_62 — Fri, 10 Dec 2004 08:50:26 GMT

The problem is a bad cpu . Processor xeon 3g is damaged.
Tank's for your attention bat the case is close.