I hate blue screens. They usually are caused by bad drivers trying to access a memory block that's being used. Here's a nice tutorial on how to debug these little buggers. Hopefully you can narrow it down.
Debugging Kernel Mode Blue Screens
All Articles > Computer Repair
Article ID: 16
Published To: Internal Users Only
Debugging Kernel Mode Blue Screens
All blue screen crash minidumps are stored in C:\WINDOWS\Minidump directory. For full dumps, find the Memory.dmp file in the C:\Windows\ directory.
First you must install the debugger and the symbols. You CAN debug a 64 bit memory dump on a 32 bit system, and vice versa.
For 32 bit Debugging:http://www.microsoft.com/whdc/devtools/ ... x86.mspx#a
For 64 bit Debugging:http://www.microsoft.com/whdc/devtools/ ... 64bit.mspx
Install the debugger and run it (WinDbg).
In the GUI, open the memory.dmp file you want to analyze.
You will then get an error saying something about symbols. To find symbols, go to the bottom and run the command:
Most commands start with a !
This command will connect the debugger to Microsoft's public symbols library on the Internet.
Next, you must save your workspace with
Then close WinDbg and reopen it. Then reopen your workspace file, then reopen your memory dump.
Now you should not receive the symbols errors.
You should see some kind of Stop Code being debugged. Something like
To view more information on the stop error its self you can open the File>Help menu, click on
Debugging Techniques>Bug Checks (Blue Screens)>Bug Check Code Reference
to view stop errors and their meanings.
You may now get a clue as to what is causing the problem. The debugger may show:
Probably caused by :
This will identify what file caused the blue screen. Most all blue screens are caused by a bad driver. If you want to analyze further, which you should, run the command:
Under the parameter Module_Name:
you may see a driver name that will be a blue link. This is the problem driver. Click it and you should get more details on the driver its self.
In the stack text, you may also get some clues as to what caused the blue screen.
When the system encounters a hardware problem, data inconsistency, or similar error, it may display a blue screen containing information that can be used to determine the cause of the error. This information includes the STOP code and whether a crash dump file was created. It may also include a list of loaded drivers and a stack trace.
Crash dump file
You can configure the system to write information to a crash dump file on your hard disk whenever a STOP code is generated. The file (memory.dmp) contains information the debugger can use to analyze the error. This file can be as big as the physical memory contained in the computer. By default, it's located in the Windows folder, and you CAN call them "memory dumps" without fear of offending anyone.
A program designed to help detect, locate, and correct errors in another program. It allows the user to step through the execution of the process and its threads, monitoring memory, variables, and other elements of process and thread context.
The processor mode in which system services and device drivers run. All interfaces and CPU instructions are available, and all memory is accessible.
A minidump is a smaller version of a complete, or kernel memory dump. Usually Microsoft will want a kernel memory dump. But the debugger will analyze a mini-dump and quite possibly give information needed to resolve. If it's all you have, then debug it, rather than waiting for the machine to crash again. Open the file in the debugger (see below) just as opening memory.dmp in the demonstration.
The error code that identifies the error that stopped the system kernel from continuing to run. It is the first set of hexadecimal values displayed on the blue screen. At a minimum, frontline Admins should be required to note this code, and the four other codes displayed in parenthesis, and any drivers identified on the screen. Often, this is all you really need!
All system applications, drivers, and DLLs are built such that their debugging information resides in separate files known as symbol files. Therefore, the system is smaller and faster, yet it can still be debugged if the symbol files are available. You don't need the Symbol files to debug - the debugger will automatically access the ones it needs from Microsoft's public site.