Debugging STOP errors is not for the faint of heart, or at least that is the impression most people have. In fact, it is not to difficult determine the cause with a little time, and a few free tools. Thelazyadmin.com Forum member WrldBFree, has written an excellent introduction to basic debugging using WinDBG.
Often times, your computer will generate STOP codes (aka the BSOD) which are caused by buggy device drivers, applications or filter drivers used by applications such as Anti Virus etc
Unfortunately the stop code rarely points you to the driver that is at fault for the crash. This is where WinDBG comes in! With WinDBG, debugging can get a lot more advanced and you coud even compare with the exact source code that is causing the crash to locate the problem within the driver. Since most of us don't have access to the source code we will have to leave that to the developers. That doesn't leave us you out in the cold. You can still use WinDBG to discover which driver or application is at fault for the blue screen and then we can go about updating that driver/application, or removing it. WinDBG is a free download from Microsoft and once you have installed it, the first step is to set the symbol path. Launch WinDBG and the choose File --> Symbol File Path.
Enter the path to Microsoft's public symbol repository and click OK.
Note: You can also download and install the Symbols package locally if you prefer.
To prevent you from having to set the symbol path each and every time you can save your workspace by clicking File --> Save Workspace. The next step is to open your dump file by clicking File --> Open Crash Dump.
The dump file will open up and a Bugcheck Analysis will run.
As you can see, by default, WinDBG already does a preliminary bugcheck analysis and tells you the most likely culprit of the crash (Ive been told this is correct about 75% of the time). In this case it says the culprit is i8042prt.sys which is a driver for ps/2 ports and in this case this is correct, because it was a manually initiated crash by me using the CrashOnCtrlScroll sequence. For those unfamiliar with CrashOnCtrlScroll, it is a way to force a BSOD which can be useful for testing purposes such as this.
The next command you want to issue for detailed information is
!analyze v
As you can see, !analyze v shows that this was a manually initiated crash and the arguments issued for the crash dump. It also shows you what was loaded into the stack at the time of crash under the Stack Text field and then gives you the faulting source code closer to the bottom pointing to the i8042prt.sys driver.
That one simple command often points you into the right direction as to what is causing the crash. Then you can go ahead and troubleshoot that specific driver or application and get the problem corrected. If you wanted more information on the driver that is causing the crash. You could issue the command lmv m drivername and it will give you info on that particular driver such as its location, its date (which can be helpful in determining if its an old driver that needs updating).
If you wanted to see all of the drivers loaded on the system at time of the crash. You could issue the command lmnt Finally, to save your debugging session to a log file for later use, or more indepth analysis you can run the command
.logopen [filepath]
to save the session.
For more information see:
Debugging Tools for Windows 32-bit Version
Debugging Tools for Windows 64-bit Version
Download Windows Symbol Packages