KMODE_EXCEPTION_NOT_HANDLED

[ljCharlie]

Please help me. My computer come to the blue screen and stops there with this error:

Stop: 0X0000001E (0X000005, 0XEB8CIECA, 0X0000000....)

KMODE_EXCEPTION_NOT_HANDLED

I already took out all the hardware except the video card and the hard drive but still doesn't work. I also reset the CMOS but that doesn't change anything.

If anyone has idea regarding this problem, I'm greatly appreciated.

Many thanks in advance!

ljCharlie

 

[MountainNetworks]

There are a hundred different opinions. But most likely you have bad RAM. Below is a paste of a word document I downloaded from Microsloth a few years back. The insanity which held true then is still true today.... Here goes, hope it helps:

Troubleshooting Windows NT versions 3.x and 4.0



TechEd 1997 file name: ENT410ef.doc Last Updated: June 1997 While each problem in a device driver is different in the mechanism necessary to identify the exact problem, there are several initial debugging procedures that can be used to find a starting point in identifying the problem. These techniques include using system bug check information, obtaining stack trace information, and checking hang conditions.

Interpreting System Bug Check Information

When the Microsoft® Windows NT® operating system encounters a condition that compromises safe system operation, the system halts and displays a blue character-mode screen. This screen is commonly referred to as the blue screen or STOP screen. Windows NT attempts to display as much information as possible about the current state of the machine when it encountered the error. If crash dumps were enabled on the system, a crash dump file is created that can be used at a later time for more detailed debugging. If a debugger is attached and active, the system causes a breakpoint so the debugger can be used to investigate the crash. The following example of a STOP screen contains several sections of information that will be discussed in detail. The sections are the STOP information at the top of the screen, information about the loaded modules in the system, basic stack trace information, and information regarding the status of crash dumps and kernel debugger activity. *** STOP: 0x0000001E (0x80000003,0x80106fc0,0x8025ea21,0xfd6829e8) Unhandled Kernel exception c0000047 from fa8418b4 (8025ea21,fd6829e8) Dll Base Date Stamp - Name Dll Base Date Stamp - Name 80100000 2be154c9 - ntoskrnl.exe 80400000 2bc153b0 - hal.dll 80258000 2bd49628 - ncrc710.sys 8025c000 2bd49688 - SCSIPORT.SYS 80267000 2bd49683 - scsidisk.sys 802a6000 2bd496b9 - Fastfat.sys fa800000 2bd49666 - Floppy.SYS fa810000 2bd496db - Hpfs_Rec.SYS fa820000 2bd49676 - Null.SYS fa830000 2bd4965a - Beep.SYS fa840000 2bdaab00 - i8042prt.SYS fa850000 2bd5a020 - SERMOUSE.SYS fa860000 2bd4966f - kbdclass.SYS fa870000 2bd49671 - MOUCLASS.SYS fa880000 2bd9c0be - Videoprt.SYS fa890000 2bd49638 - NCR77C22.SYS fa8a0000 2bd4a4ce - Vga.SYS fa8b0000 2bd496d0 - Msfs.SYS fa8c0000 2bd496c3 - Npfs.SYS fa8e0000 2bd496c9 - Ntfs.SYS fa940000 2bd496df - NDIS.SYS fa930000 2bd49707 - wdlan.sys fa970000 2bd49712 - TDI.SYS fa950000 2bd5a7fb - nbf.sys fa980000 2bd72406 - streams.sys fa9b0000 2bd4975f - ubnb.sys fa9c0000 2bd5bfd7 - mcsxns.sys fa9d0000 2bd4971d - netbios.sys fa9e0000 2bd49678 - Parallel.sys fa9f0000 2bd4969f - serial.SYS faa00000 2bd49739 - mup.sys faa40000 2bd4971f - SMBTRSUP.SYS faa10000 2bd6f2a2 - srv.sys faa50000 2bd4971a - afd.sys faa60000 2bd6fd80 - rdr.sys faaa0000 2bd49735 - bowser.sys Address dword dump Dll Base - Name 801afc20 80106fc0 80106fc0 00000000 00000000 80149905 : fa840000 - i8042prt.SYS 801afc24 80149905 80149905 ff8e6b8c 80129c2c ff8e6b94 : 8025c000 - SCSIPORT.SYS 801afc2c 80129c2c 80129c2c ff8e6b94 00000000 ff8e6b94 : 80100000 - ntoskrnl.exe 801afc34 801240f2 80124f02 ff8e6df4 ff8e6f60 ff8e6c58 : 80100000 - ntoskrnl.exe 801afc54 80124f16 80124f16 ff8e6f60 ff8e6c3c 8015ac7e : 80100000 - ntoskrnl.exe 801afc64 8015ac7e 8015ac7e ff8e6df4 ff8e6f60 ff8e6c58 : 80100000 - ntoskrnl.exe 801afc70 80129bda 80129bda 00000000 80088000 80106fc0 : 80100000 - ntoskrnl.exe Kernel Debugger Using: COM2 (Port 0x2f8, Baud Rate 19200) Restart and set the recovery options in the system control panel or the /CRASHDEBUG system start option. If this message reappears, contact your system administrator or technical support group. There is a significant amount of information available for identifying the problem that caused the system to halt. This information can be used in conjunction with WinDbg to identify the problem. At the top of the screen is the bug check code labeled STOP. This code will vary depending on the individual problem that caused the system to halt. The most common bug check codes are:
Bug Check Code Definition
0x0000000A IRQL_NOT_LESS_OR_EQUAL
0x0000001E KMODE_EXCEPTION_NOT_HANDLED
0x0000007F UNEXPECTED_KERNEL_MODE_TRAP
A bug check code of IRQL_NOT_LESS_OR_EQUAL generally indicates a software failure by a driver or other system component. This code indicates that an attempt was made to execute an operation with an improper IRQL. This is generally caused by calling routines that are invalid at the IRQL of the caller, by using invalid addresses to system routines, or by attempting to touch pageable memory at raised IRQL. A bug check code of KMODE_EXECPTION_NOT_HANDLED indicates that an exception taken in kernel mode was not handled. This bug check can happen for any number of different exceptions that can occur. Some of the most common include 0xc0000005 (access violation) and 0x80000003 (a breakpoint was encountered without a kernel debugger being attached to the system). A bug check code of UNEXPECTED_KERNEL_MODE_TRAP indicates that a software condition too serious to continue has been encountered. Examples include divide by zero, a corrupt task state segment, or a fault occurring while processing a fault (known as a double fault condition). The four values following the STOP message are parameters to KeBugCheckEx, the support routine called when the system must halt. For each bug check code, the parameters will vary. The following is a description of what each parameter means for the most common bug check codes:
Code Parameter 1 Parameter 2 Parameter 3 Parameter 4
0x0000000A Memory referenced IRQL Value 0 - Read 1 - Write Address that referenced the memory.
0x0000001E Exception code Address where the exception occurred. Parameter 0 of the exception. Parameter 1 of the exception.
0x0000007F Trap code Not used Not used Not used
Following the bug check information is information about each loaded driver or base module in the system. This information consists of the base address where each module is loaded, a hexadecimal representation of the date stamp of the binary image, and the name of the driver or base component. The base address information can be interpreted to determine in what image an address is found. This information is useful in an attempt to determine which driver contains the address where, for example, a faulting instruction was executed. Following the list of loaded drivers in the system is a brief stack trace. This information indicates what drivers and routines were being executed when the system failed. However, it is important to note that the last calls are not necessarily the cause of the system failure. The last calls on the stack trace can be system routines attempting to handle or process the error condition. The final layer of information displayed is information regarding kernel debugger and crash dump status. This information indicates if the target side of kernel debugging is now active. If a crash dump file has been generated, that information will be displayed as well.

Debugging a System Bug Check

If a system has been bug checked, there are steps to obtain useful information for further debugging. These steps include obtaining the stack trace and getting trap frame information. When the debugger has connected and the system is accessible from the command window of the host machine, type kv. This command displays a verbose kernel trace from the target machine. The following is a sample trace: ChildEBP RetAddr Args to Child 8013ed5c 801263ba 00000000 00000000 e12ab000 NT!_DbgBreakPoint (FPO: [0,0,0]) 8013eecc 801389ee 0000000a 00000000 0000001c NT!_KeBugCheckEx+0x194 8013eecc 00000000 0000000a 00000000 0000001c NT!_KiTrap0E+0x256 (FPO: [0,0] TrapFrame @ 8013eee8) 8013ed5c 801263ba 00000000 00000000 e12ab000 8013ef64 00000246 fe551aa1 ff690268 00000002 NT!_KeBugCheckEx+0x194 The information from a kernel trace includes the list of calling routines, the parameters of each call, and, if a routine stored a trap frame, a trap frame address. If a trap frame was stored, the information that caused the trap can be retrieved by using the !trap command. In the preceding example a trap frame was stored by NT!_KiTrap0E (which is very common) at 8013eee8. When the trap frame has been retrieved, a !kb command will generate a stack trace for that trap frame. Taking a page fault at raised IRQL is a frequent cause of bug check conditions. There are many operations that can cause this to happen, including calling support routines at an IRQL level higher than permitted for that routine, using incorrect pointers, or touching pageable memory at a raised IRQL. A page fault condition generally creates a trap frame and a fault situation that will require additional investigation to find the cause of the problem. A bug check of 0x0000001E (KMODE_EXCEPTION_NOT_HANDLED) often does not display full stack information and, thus, requires additional investigation. See "Debugging Unhandled Exceptions."

Debugging Unhandled Exceptions

A bug check condition of KMODE_EXCEPTION_NOT_HANDLED might require additional investigation if a full stack trace could not be obtained through normal stack trace operations. Use the following procedure to get the necessary information to identify the problem: · Look for the first parameter to NT!PspUnhandledExceptionInSystemThread. Use the kb command, which displays parameters in the stack trace to find this value. For optimized RISC machines which might not have the parameters on the stack, see "Manually Obtaining Call Stack Trace Information on RISC Machines" for more information on how to obtain this parameter. · The first parameter to NT!PspUnhandledExceptionInSystemThread is a pointer to a structure which contains pointers to an except. The Add command on that address will display the necessary data. · The first value retrieved is an exception record. The exception record can be displayed by using the !exr command. The second value retrieved is a context record that can be displayed by using the !cxr command. · After executing the !cxr command, the !kb command displays a stack trace based on the context record information. This indicates the calling stack when the unhandled exception occurred. The stack trace information returned from the exception record information displays a normal stack trace with parameters that can then be used to debug the problem and find the offending operation.

Manually Obtaining Call Stack Trace Information on RISC Machines

On an optimized version of Windows NT running on a RISC system, such as the free build of Windows NT, parameters might not be stored on the stack. Instead, they can be stored in registers for performance. Attempting to debug a problem on a RISC machine presents unique problems, as a !kb command might not reveal the correct parameters passed to each function. To unwind the stack to find where various parameters are stored, it is necessary to understand the assembly code for each platform. The movement of the parameters in and out of registers, as well as the values stored in the them, needs to be tracked. For more information on the assembly language for each platform and how that processor architecture handles call stacks and parameters, see the appropriate processor reference from the manufacturer. Parameters are stored, in first-to-last order, in registers a0 through a3 and, if necessary, registers t0 through t7 on MIPS machines. On Alpha machines, parameters are stored first-to-last in registers a0 to a5 and, if necessary, registers t0 through t7. On Power PC machines, parameters are stored in first-to-last order in registers r3 through r31. Unassemble the function to a point where the parameter values can be identified in memory or until a function call on the stack is made without the register being saved. This gives you an indication of where each parameter was stored and what its value was. Do this for each module as you trace downward in the system. Some of the parameters can have been stored on the stack before use, making retrieving their values relatively simple.

Checking Hang Conditions

Sometimes a system can hang without breaking into the debugger. The symptoms can vary from no mouse or keyboard response to the video update and no input/output (I/O) response. The following is a starting point for debugging a hang condition: · Break into the target system by pressing CTRL+C on the host debugger. This causes the target system to halt as if it had encountered a breakpoint. Use !process to identify the currently running process. · The most useful information is the time values, the handle count, and the thread status information. A high time value can indicate that this is a suspect process. If the current process is idle, it indicates that the machine is either truly idle or in an indeterminate state. If this process does not seem to be the problem, try using !process with its other options to get more information on other processes in the system or with more detail. · After a suspect process has been identified, use !process <process> 7 to show the kernel stacks for each thread in the process. This can indicate what the problem could be in kernel mode and what the suspect process is calling. To identify other information about a possible hang condition, the following table contains some additional useful commands:
Command Usage in debugging hang conditions
!ready Identifies threads in a ready condition in order of priority.
!locks Identifies any resource locks.
!vm Displays virtual memory usage.
!poolused Checks pool allocation. On a checked build with pool tags this can identify excessive allocations.
!memusage Checks physical memory status.
!heap Checks the validity of the heap.
!irpfind Displays any information about pending IRP requests.
To determine if a single process is causing the machine to hang, set a breakpoint at KiSwapContext. If this breakpoint is hit, then the system is scheduling other processes. If the breakpoint is not hit, then a single process is causing the hang. © 1997 Microsoft Corporation. All rights reserved. The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY. Microsoft and Windows NT are registered trademarks of Microsoft Corporation. Other product or company names mentioned herein may be the trademarks of their respective owners.

 

[ljCharlie]

Thank you for the help. The error I have is on my Windows 2000 Professional version. At first I thought it was a driver problem but I did put in a new hard drive and I still receive the same error. So I think it has to do with some hard ware problem but I'm not quite sure what it is. If it is a RAM problem, would the computer not display the faulty RAM when the computer loads and check the memory? On my computer, the computer still checks the memory fine and shown the amount of RAM correctly. So if it is faulty or not working, should this number be incorrect?

ljCharlie

 

[MountainNetworks]

If you can get a microsoft operating system to accurately display anything, and put them in terms a human being can understand, write a book and spend the rest of your life in Hawaii

But here in the real world, if it is bad RAM, it won't tell you. But troubleshooting it should be easy. How is your RAM set up...that is to ask, how many modules? Do you have two 128M modules for a total of 256? Take one module out and boot. If it still blue sceens, then take the other one out and boot. If it still blue screens after that, you know it's not RAM.

The second question to ask...what was the last thing you did when the system WAS working? Did you install or uninstall anything? Did you change your display settings, your refresh rate or your screen resolution? Can you boot into &quot;safe&quot; mode? To boot into &quot;safe mode&quot; holding down the F8 key will give you the safe mode menu in most cases.

As a matter of general troubleshooting, clearing the CMOS probably wasn't necessary because that loads before the OS even begins it's boot process. Just an FYI to save you some time in the future. Although, if there is an updated version of your BIOS, it never hurts to load it.

 

[MountainNetworks]

You said: &quot;but I did put in a new hard drive and I still receive the same error.&quot;

Please clarify this.

 

[ljCharlie]

I have three modules with each 256MB. I did take out the module one by one and still receiving the same blue screen. Now, I haven't tried taking out the last module and put in a different module to test that last module. I guess I'll test that tonight.

At first I was able to go into safe mode but later on I can't anymore. It looks like the computer stops loading at the amd75.sys when I tried to go into safe mode. The last thing I tried before the computer crash is going into Nero. I clicked on the Nero icon on my quick launch and instead of loading the Nero program, my computer automatically restart. I clicked on the Nero four times and the computer restart four times when at last the computer only come into the blue screen. This is when I can't go into Windows anymore.

I thought it was my hard drive problem and so I swap another working hard drive from my other computer into the one I'm having problem with and still the computer display the blue screen but with a different message.

ljCharlie

 

[MountainNetworks]

Hi:

First of all, in most cases you can't just swap a hard drive from a working system and expect it to boot, unless the hard drive came from a computer with an *identical* hardware configuration.

amd.sys sounds like a RAM error. Try booting with just one 256 module. If that doesn't work, try taking out the CD Burner and removing that from the BIOS. If it still blue screens, put everything back the way it was, then boot from the windows 2000 CD. Follow the instructions for a Repair. The following URL comes from gateway, but the instructions are the same regardless of the type of computer.

Please see

http://support.gateway.com/s/SOFTWARE/MICROSOF/7508277/750827758.shtml

 

[ljCharlie]

I have tried putting only one module of RAM and still receiving the same problem. Because I have three memory modules, I have tried putting in one working RAM module in different location but doesn't work. I have taken every hardware in the computer out. I even swapped a video card that's working in another similar computer and still receiving the same blue screen. However, this time I was able to get into the safe mode; however, I wasn't able to do much because I still don't know what's wrong. I still get the same blue screen if I tried to boot normally.

ljCharlie

 

[MountainNetworks]

Before you go any further, follow these instructions:

http://support.gateway.com/s/SOFTWARE/MICROSOF/7508277/750827758.shtml

If you still have problems after that, and you can get into safe mode, then look in the event viewer. What errors are there?

 

[MountainNetworks]

Almost forgot...

If the &quot;repair&quot; instructions don't work, then when you're in safe mode, uninstall Nero and see if that helps.

 

[Toonah]

I just got the same error message when I try to use my TDK cd burner with Nero Express. If I try to run it my machine reboots. Downloaded the newest upgrades, the aspi upgrade, and prior to that I unin/reinstalled the software. The only thing I installed since it did work fine, is a Sandisc CF card reader. TDK thinks it is a driver conflict but how does that show up on 2K Pro? Any ideas??

 

[ljCharlie]

I have tried fast repaire and also full repaire but it doesn't work. I also uninstall Nero when I was in Safe Mode but still the same problem. I have practically change every hard ware in the system except the mother board and the power supply and it's the same problem.

ljCharlie

 

[MountainNetworks]

From the safe mode, is there anyway you can export your event logs to this forum?

 

[ljCharlie]

I have just purchased a new motherboard and it's working now. I guess if I really want to find out what's wrong, I will swap this motherboard with another computer that's working to see if it will generate the same error. If it is then the problem is the motherboard.

ljCharlie

 

[dementg]

I've experienced a similar, but not identical problem on an old system. Once the problem occured, Windows was corrupted so the BSOD would appear no matter what. It had to be reinstalled. I used a memory testing program called &quot;MemTest86&quot;. I found I did have a memory problem, eventually worked it out, but still had to reinstall Windows. After fixing the memory problem, AND reinstalling windows, the problem hasn't recurred after several months.

The memory problem can be tricky to completely fix. In my case, I had to leave one empty socket and also reduce the FSB speed before I could get through the toughest tests repeatedly without ever failing. It was a cheap and/or dying motherboard, apparently.

 

[srimurali]

Do this.Hope it will work.

-Just remove the HardDisk.
-put this harddisk to another machine
(Disconnect the old one)
-start the system and configure ur system with new hardwares found (like mouse,video card,sound card,....)
-Restart untill all the hardwares configured.

-then remove the harddisk and put it back to the old one.
-configure to new hardwares found (if needed)

Hope this will help.

 

[ljCharlie]

Many thanks for your support. It's been so long. I already replace the motherboard and it worked.

ljCharlie