I need to double check my understanding of DbgHelp and crash dumps.
To cope with some crashes my Windows application has encountered in the field, I've written an UnhandledExceptionFilter that uses the MiniDumpWriteDump function (from DbgHelp.dll) to write out a .DMP file. It seems to work well and it appears I can see the full crash info even if the client does not have the PDBs when the crash occcurs (as long as I have them when I open the dump file)
I am just hoping for a confirmation. Is there any need for me to distribute the PDBs? Is there some information that I might fail to get in the DMP file from a client crash if I were not to distribute them?
How do I access Heap Information from Minidump File Summary. I using Visual Studio 2013 and new to dump files, this file was produced by Windows Task Manager selecting the process and creating a dump file.
Screenshot below might explain better what I am trying to achieve.
You need to click the "Debug with Native Only" link on the right. After that, it'll fire up the debugger. You can look at local variables if it captured them. You can open the memory window to see heap info but probably need to know the general address range you're interested in.
In the past, I have heard references to parsing .dmp files using WinDbg (I think - I might be wrong).
I have also done fairly extensive debugging with the help of .map files, and I have done extensive debugging using standard logical heuristics and the Visual Studio debugger.
However, occasionally, the program I am developing crashes and creates a .dmp file. I have never been able to interpret the .dmp file. A while ago, I posted a SO question regarding how to interpret .dmp files ( How to view .dmp file on Windows 7? ), but after somewhat significant effort I was unable to figure out how to interpret .dmp files using the answer to that question.
Today, I was viewing an unrelated SO question ( C++ try/throw/catch => machine code ), and a useful comment underneath the accepted answer has, once again, made reference to WinDbg.
If you really want to find this out though, it's easy - just trace
through it in WinDbg
I would like to follow this advice. However, for me, it's not easy to "just trace through it in WinDbg". I've tried in the past and can't figure out what exactly this means or what to do!
So, I'm trying again. "For once and for all", I would like to have plain-and-simple instructions regarding:
What is WinDbg
Assuming WinDbg is related to .dmp files, what exactly is a dump file and how does it relate to WinDbg (and correct me if my assumption is wrong)
How do you create .dmp files and, correspondingly, how do you use WinDbg to analyze them (again, correct me if I'm wrong about the relationship between WinDbg and .dmp files).
If you could please answer this question from the "starting point" of a programmer who ONLY has Visual Studio installed and running.
Thanks!
WinDbg is a multipurpose debugger. It can debug a live process by attaching, set breakpoints, etc like you would with any other debugger. It can also analyze crash dump files as well, which are .dmp files. It functions by you giving it commands.
A .dmp file is a memory dump of something. What that something is depends on what the memory dump is for. It could be for a process, for example. It could also be for the kernel. What is in the memory dump depends, too. In your case, it's probably what your process looked like at the time of it crashing. What the memory dump contains can vary depending on the dump type.
There are various ways. On Windows Vista+, Server 2008+ - you can do it right from the task manager. Right click the process, and click "Create Memory Dump". WinDbg can make a memory dump from a live process too by using the .dump command. Other tools like adplus can be used to automatically create a memory dump on certain conditions, like when a process exceeds a memory or CPU threshold, or when it crashes.
WinDbg can open a Crash Dump easily enough. What is important is that you get your symbols loaded correctly, first. Usually in the form of .pdb files or from a symbol server (though not necessary, or always possible, it is greatly helpful).
Once you have WinDbg running, take a look at the list of commands available to poke around in your crash dump.
WinDbg is a Gui version of the command line debugger cdb.exe, both are user-process and kernel mode debuggers, it uses DbgHelp.dll to issue commands to your application or NT kernel (you can also do the same as it has an api).
.Dmp files are memory dumps of varying detail, some can have minimal detail enough for call stacks of all threads, whilst others will put the entire user-mode memory, handle information, thread information, memory information etc.. see this for more info. So dump files have nothing to do with WinDbg, other than it can open them, incidentally you can open .dmp files in Visual Studio
Like #vcsjones has already stated you can do this using task manager (at least you can from Vista onwards), you can use procdump, you can do this once WinDbg is attached, I usually do a full mini dump like this: .dump /ma c:\mem.dmp, you can also set Windows to do this when a crash happens using Dr. Watson
However, you must have the symbols for Windows and your application in order to be able to generate sensible call stacks, note that for obvious reasons you cannot step through or set breakpoints in a a memory dump, you can only do this for a live process. You can also have WinDbg attach non invasively, so Visual Studio could be attached and you can attach WinDbg non invasively and use the toolset in WinDbg to assist debugging.
For me the main advantage of WinDbg is its free, it is a small download and install, it is fast, it has a very rich toolset for diagnosing problems that are either difficult or impossible to do using visual studio.
I'm using windbg to analyze a memory dump on a separate computer from where the dump file originated. Inside the tool's commmand line, I typed in the following:
.loadby w3core w3core
Here's the error:
The call to LoadLibrary(c:\windows\system32\inetsrv\w3core.dll) failed, Win32 error 0n126 "The specified module could not be found." Please check your debugger configuration and/or network access
Update: The process which I create the dump file from is w3wp.exe. I think that is for IIS. It's the IIS Worker Process. So, w3core.dll must be related to the IIS Worker Process.
Just to review my steps, I used the Debug Diagnostic Tool to monitor a crash of a particular process on Computer A. (Computer A is running Windows Server 2003 Standard 32-bit, IIS 6; ASP.NET is NOT installed.) This crash created a memory dump file. I copied this dump file to Computer B, which has Debug Diagnostic Tool and windbg installed. On Computer B, I added the dump file in the Advanced Analysis tab of the Debug Diagnostic Tool and clicked the "Start Analysis" button. The analysis summary reported:
the module c:\WINDOWS\system32\inetsrv\32.core.dll has caused an access violation
exception(0xC0000005) when trying to read from memory location 0x53534553 on thread 4
I opened windbg and added the Symbol File Path
SRV*downstream_store*http://msdl.microsoft.com/download/symbols
Then, I opened the dump file and typed in the above command and it spit out the aforementioned error. I can assure that the file definitely exists.
What is the problem? Is it because I'm debugging on Computer B, when, in fact, the dump file came from Computer A? Beyond that, I'm not sure what I'm doing wrong.
Why can't I load this module? Thank you very much for any help.
Try loading w3core in depends (http://www.dependencywalker.com/) assuming you can find the dll (which if you can't would also explain it). If it is missing any dependent dlls it should show you there.
Hi all I am running Visual2005 and want to generate the MAP file to analyze the
crash situation.
I have enabled below settings.
Linker->Generate MAP - Yes (/DEBUG)
General Debugging Info - Yes (/MAP)
And making the application crash by writing it in the NULL location.
If I run the EXE With VS2005 it is generating the MAP file in the path of EXE.
If I run the EXE out side the VS2005 application is crashing but no MAP file generated.
Do I need to do any other setting to generate the MAP file.
Edit: I need to analyze the crashing occuring in client location we will give them a debugg version of EXE and when it crashes they will send us the DUMP which we can analyze.
AFAIK, MAP file is created by linker and not at runtime. Do you need map file or crash dump? These are two different things.
If you want to add crash dump capability to your program, you need MiniDumpWriteDump
function and global exception handler. Then you can make post-mortem debugging, using crash dump generated by the program. See details here: http://www.codeproject.com/KB/debug/postmortemdebug_standalone1.aspx
Regarding map file, you only need crash address, and then you can try to find source code line by this address and map file. This technique doesn't work in many cases, post-mortem debugging is much better.
Edit. Well, you need a crash dump, this is a good decision. Using map files is not reliable. By default, Windows user mode program does not create crash dump. This feature must be added manually. CodeProject article describes how to do this, and shows how to make post-mortem debugging.