How to read microsoft crash dump files

To proceed, try to inspect the objects that are referenced on the stack to see whether you can gather more information from this list. To display all managed objects that are found within the bounds of the current stack, run dso.

This isn't helpful. You should not see any System. HttpWebRequest instances. There are instances of the exception, and you've already inspected it. Therefore, this command didn't yield new information that's related to the cause.

All the managed objects are stored in a managed heap, and we can look at the managed heap by running dumpheap. Don't run dumpheap without any parameter because then the command will list all the objects inside the managed heap a large list. Instead, you can get the statistics of the heap by using the dumpheap -stat command.

You can use one more tactic to narrow down the statistics by running the command in the following format:. The following screenshot displays the statistics for the managed objects, which contain the string System. HttpWebRequest in their name. In the sample application, there is only one System. HttpWebRequest object on the managed heap. In the previous list, the address that's seen next to the HttpWebRequest entry isn't that object's address in memory.

Rather, it's the address that corresponds to the "method table" of objects of type System. To get the actual list of the objects, you can pass that method table MT address to the dumpheap command in the following manner:. Now, you're able to identify the address of the problematic object. In this example, it's fc You can investigate the object's properties by passing that address to the dumpobj command.

This will list the properties of that object. In this example, run dumpobj fc to examine the object's properties. You're investigating a System. This is an object of the System. Uri type. You want to determine the URI. Copy the address of the System. Uri object, and investigate it by using dumpobj again. Run dumpobj fbfbb8. The address of the object in the memory dump file that you generated will most certainly be different.

Yes No. Sorry this didn't help. Thanks for your feedback. I'm starting to suspect it might be related to overheating caused by my SSD installed several months ago, although that is purely a guess at this point. This thread is locked. You can follow the question or vote as helpful, but you cannot reply to this thread.

The settings for the dump files are configured using the System tool in Control Panel. Within this tool, select System Properties - on the Advanced tab there is a section for Startup and Recovery. Clicking on the Settings button brings up the dump file options as shown below. There are three different types of dump that can be captured when a system crashes:. Complete Memory Dump : This contains the entire contents of the physical memory at the time of the crash.

This type of dump will require that there is a page file at least the size of physical memory plus 1MB for the header. Because of the page file requirement, this is an uncommon setting especially for systems with large amounts of RAM.

Also, this is the default setting on Windows Server systems. Since this is a kernel-mode only dump, there are no pages belonging to user-mode processes. However, it is unlikely that the user-mode process pages would be required since a system crash bugcheck is usually caused by kernel-mode code. The list of running processes, state of the current thread and list of loaded drivers are stored in nonpaged memory that saves in a kernel memory dump.

The size of a kernel memory dump will vary based on the amount of kernel-mode memory allocated by the Operating System and the drivers that are present on the system. Small Memory Dump : A small memory aka Mini-dump is a 64KB dump KB on bit systems that contains the stop code, parameters, list of loaded device drivers, information about the current process and thread, and the kernel stack for the thread that caused the crash.

Something to note here - although the need for a complete memory dump is rare when dealing with bugchecks, a complete memory dump is almost always required for manually generated crash dumps used to diagnose soft hangs on a system for more information regarding the difference between a soft and hard hang, please see our Troubleshooting Server Hangs - Part One.

This is because when looking at soft hangs we will need to look at user-mode processes, deadlocks etc. If they are, see your product documentation to complete these steps. Click the Advanced tab, and then click Settings under Startup and Recovery. In the Write debugging information list, click Small memory dump 64k.

To change the folder location for the small memory dump files, type a new path in the Dump File box or in the Small dump directory box, depending on your version of Windows. Use the Dump Check Utility Dumpchk.

The Dump Check Utility does not require access to debugging symbols. Symbol files hold a variety of data which are not actually needed when running the binaries, but which could be very useful in the debugging process.

Or, you can use the Windows Debugger WinDbg. WinDbg and KD. Select the Typical installation. By default, the installer installs the debugging tools in the following folder:. This Web page also provides access to the downloadable symbol packages for Windows. For more information about dump file options in Windows, see Overview of memory dump file options for Windows.

Click Start , click Run , type cmd , and then click OK. Change to the Debugging Tools for Windows folder. You can use the following sample commands to open the dump file.