I recently had a Windows server which was crashing constantly. After much research I found a couple of websites refering to the use of windbg (Debugging Tools for Windows.) After using this program I was able to pinpoint the problem as a microsoft bug with the win32k.sys file. It should be noted that you do need some pretty strong programming or system administration knowledge to really be able to use this program properly, however, if you use it in conjunction with some of the forum availible on the internet you can usually troubleshoot and resolve the issue without too much fuss.
First you will need to download a copy of Windows Debugging tools (Windbg). This is used to load and analyze the Dump Files. This can be used on mini dump files; however, you will not get as good of results as you will with the Full Kernel Dump file.
The next step obviously is to obtain the dump file; you can analyze the dump file on the system in question or via another system, just copy the dump file on the same system so you don’t tie up your network.
Now open Windbg and follow the below steps to diagnose the dump logs.
1) Go to File| Symbol File Path
a. Here you will select where the symbol files are. These tell Windbg about the files running and what they should be doing in RAM. There are custom files available for some applications, however, the ones I will provide are for Microsoft Windows files and will not help troubleshoot specific software issues.
2) Enter the below into the search path (note that you will need a local temp directory.)
a. SRV*c:\temp *http://msdl.microsoft.com/download/symbols
i. You can also download the symbols from Microsoft if you want a local copy. Note it is 100+ Megs.
3) Next you need to load the Crash/Dump file.
a. Go to File| Open Crash Dump
i. Enter the location of the dump file.
b. The file will be loaded and you will get some msgs about the file and symbol files that could not be found (normally related to files which Microsoft’s Symbol files do not recognize.) It will also give you a preliminary result (Possibly caused by: xxxx)
c. Next you will want to further analyze the dump file to determine more about the possible cause.
i. Enter at the bottom of the window “!analyze –v”
d. This will provide further information as well as specific memory addresses. If you’re a programmer this will probably make sense, for the rest of us it should point you in the right direction. You’ll just have to sort through the memory addresses.
e. You can also further diagnose the error by using lmv
i. This will provide information on the loaded modules when the system crashed.
4) If you were unable to determine the exact error by using the above steps, copy and paste the error data, specifically the DEFAULT_BUCKET_ID or FAILURE_BUCKET_ID into an internet search engine. There are a lot of Forums and web sites designed specifically for dump file diagnostics.