Guide to Fixing BSOD/STOP errors in Windows Vista

Background

This guide will show you how to use Free Windows Debugging tools to analyze the mini dumps which occur after a BSOD(Blue Screen of Death). Windows Debugging Tools include an application called WinDgb in which70% of the time will return the source of the bluescreen.A mini or kernel memory dump occurs when a windows Kernel level process makes an error causing the entire OS to issue a STOP command, hence the blue screen. Kernel level process's and different from user level process (applications like IE, Word etc.. are User level process's). Kernel level process run at the core of Windows appearing as device drivers and other very low level software used to communicate with raw hardware I/O, and system memory management. This is commonly why most people say you have a driver issue when your computer begins experiencing STOP errors i.e"Blue Screens".

95% of the time the OS is not a fault for a STOP error but a poorly written device driver. So don't blame Microsoft!

What happens when there is a STOP error?

When Vista encounters a STOP it will flash the common blue screen, dump the physical memory to the hard drive and restart. Now in past Windows Operating Systems you would need to change a system setting in order to stop the system from restarting in order to read the actual STOP error code on the blue screen. This can still be done under:Right Click My Computer > Properties > Advanced Properties (Left Pane) > Startup and Recovery Settings > uncheck the auto restart box. Most of the time this will not be necessary as the next time you log on after a blue screen restart Vista will prompt you with a little window describing the STOP error code and where the dump file can be found.

STOP Error options Windows:

NOTE: It is generally better to have a small memory dump then a kernel dump as more info is at hand for the debugger.

Windows Error Solution Window:

Locating the memory dump file

Looking at the photo above, the first file location listed will appear similiar to: 

C:\Windows\Minidump\MiniXXXXXX.dmp (XXX is a random identifier)

This is the location in which we will use later when using Window Debugger to search for the driver which caused this STOP error or "Blue Screen".



Using Windows Debugging Tools

To begin you must download the free tools from Microsoft here: (If you are unsure which version of Windows you have x86 or x64, most likely you have x86)

x86 Download:

http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx

x64 Download:

http://www.microsoft.com/whdc/devtools/debugging/install64bit.mspx



Download and start the Installation

Upon the completion of installation go to your start menu and locate "Debuggin Tools for Windows" and click on WinDBg.

Once loaded, click File > Symbol File Path and enter (without quotes)"SRV*DownstreamStore*http://msdl.microsoft.com/download/symbols"

Opening the Memory Dump:

Now Click File > Open Crash Dump and navigate to the location of the file we found earlier, and hit OK. You will be prompted to save workspace, and hit yes.

Now wait 10 seconds or so depending on how fast your PC is for the application to load up the memory dump. Don't be alarmed if you see messages at the end such as:

*** WARNING: Unable to verify timestamp for vmm.sys
*** ERROR: Module load completed but symbols could not be loaded for vmm.sys

This just means that the symbols file we loaded earlier could not locate information for this particular driver, most likely because it is 3rd party and not supported. This shouldn't be of any concern.

Begin the analyzing the memory dump!

This part is quite simple located the line which reads:

Use !analyze -v to get detailed debugging information.


Click the hyperlinked "!analyze -v" and it will begin to locate the source driver of the STOP error. You can also type this syntax into the textbox at the bottom of the screen.

Locate the PROCESS_NAME line for a listing of the process in which was involved in the STOP and scroll down to fine the IMAGE_NAME which will display the underlying driver at fault.

In my Case Virtual PC.exe was the process and the driver Vmm.sys. This in turn seemed to be quite accurate as I was using Virtual Pc at the time of crash.

Other Commands(Type into textbox at bottom of debugger:

• The !analyze -show command displays the Stop error code and its parameters. The Stop error code is also known as the bug check code.
• The !analyze -v command displays verbose output.
• The lm N T command lists the specified loaded modules. The output includes the status and the path of the module. 

So I know the problem driver/process...Now What!?

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 it’s an old driver that needs updating). Since you now know the driver name you can google and check the manufacturers site for an updated driver which Should fix the problem.

So Is that it...Am I Done?..Beware:

Using WinDBg is not an instant fix, it is not always correct and sometimes will not find a solution. If this is the case I suggest you run a memory test on your computer to make sure your memory is running correctly and not the source of the problem (Bad memory is a common cause for Blue Screens). Type "Memory" into your start menu and click the only option, this is the built in windows memory test which works very well for ruling out memory problems.

ENJOY PLEASE LEAVE COMMENT