This can be accomplished with 7 easy steps:
Step 1. Obtain and install the debugging tools.
All you need to install is the “Install Debugging Tools for Windows as a Standalone Component (from Windows SDK)” and during the install only select “Debugging Tools for Windows”. Everything else is used for more advanced troubleshooting or development, and isn’t needed here. Today I followed the link to “Install Debugging Tools for Windows as a Standalone Component (from Windows SDK)” although for a different OS you may need to follow a different link.
Step 2. From an elevated command prompt navigate to the debugging folder. For me with the latest tools on Windows Server 2012 it was at C:\Program Files (x86)\Windows Kits\8.1\Debuggers\x64\. You can specify the path during the install.
Step 3. Type the following:
kd –z C:\Windows\memory.dmp (or the path to your .dmp file)
Step 4. Type the following:
.logopen c:\debuglog.txt
Step 5. Type the following:
.sympath srv*c:\symbols*http://msdl.microsoft.com/download/symbols
If you computer can’t connect to internet, you can download the symbols from below link:
https://developer.microsoft.com/en-us/windows/hardware/download-symbols
Step 6. Type the following:
.reload;!analyze -v;r;kv;lmnt;.logclose;q
Step 7. Review the results by opening c:\debuglog.txt in your favorite text editor. Searching for PROCESS_NAME: will show which process had the fault. You can use the process name and other information from the dump to find clues and find answers in a web search. Usually the fault is with a hardware drivers of some sort, but there are many things that can cause crashes so the actual analyzing of the dump may take some research.
Often times a driver update will fix the issue. If the summary information doesn’t offer enough information then you’ll need to dig further into the debugging tools or open a CSS case with Microsoft. The steps above will provide you with a summary mostly-human-readable report from the dump. There is much more information available in the memory dump although it gets exponentially more difficult to track down the details the further you get into windows debugging.
Hopefully these quick steps are helpful for you as you troubleshoot the unwelcome BSOD.