Capturing Crash Dumps for Analysis
Sometimes, folks report crashes to the IE team that we are unable to reproduce internally. That’s usually because, as mentioned often, most crashes are caused by buggy browser add-ons.
In some cases, however, crashes occur even when running with browser add-ons off, and if we cannot reproduce the problem, the next best thing is a crash dump file from the affected machine.
Collecting crash dumps isn’t hard:
Install WinDBG from https://msdn.microsoft.com/en-us/windows/hardware/hh852365 (See the "Standalone Debugging Tools" section)
Configure WinDBG to run whenever a crash occurs: In an elevated command prompt, run WinDBG with the -I (case-sensitive) parameter. For instance:
C:\debuggers\windbg.exe –I
When the crash occurs, WinDBG opens. Type the following command to generate a .DMP file:
.dump /ma %USERPROFILE%\Desktop\IECrash.dmp
Dump files tend to be dozens to hundreds of megabytes in size, so they typically cannot be readily passed around via email (although they often compress well). If a DMP file is requested, the person asking for the file will typically tell you how to return the file to them.
If you allowed the "Watson" Windows Error Reporting system to upload a crash report, you can help us find "your" crash by letting us know the "bucket number." All Windows Error reporting logs are presented in the event viewer as Event ID 1001. After the crash report is sent, go into Computer Management and drill down to Event Viewer\Windows Logs\Applications, search for the Event ID 1001 that corresponds to the time the crash occured, open it up, the failure bucket id will be listed there.
Depending on the problem reported, we may also want to get a network traffic log or a Process Monitor log.
-Eric
Update: The Visual Studio team just posted a blog on capturing dumps with Visual Studio or Task Manager.