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?
When developing and deploying an application under Windows, the developer has the option to store locally the .pdb files that are generated by the compiler as part of each build, and have his program call MiniDumpWriteDump in response to a crash to generate a .dmp file that can later be sent back to the developer. Then the developer can match the received .dmp to the appropriate .pdb file and executable and use that to do post-mortem debugging of the crash (i.e. see a stack trace, etc).
It's a pain to set up and manage, but the advantage is that it allows the developer to strip all the debug information out of his released program and yet still be able to debug crashes that occur in the field. This allows the program's install size to be much smaller, and perhaps makes the program less susceptible to reverse-engineering.
My question is, does MacOS/X have any kind of mechanism like .pdb? The only options I have seen for MacOS/X are to either "strip" your executable file (resulting in a small executable, but very little debug info if it ever crashes), or don't (resulting in an executable that provides a very helpful Crash Report when it crashes, but is much larger than it needs to be otherwise).
I think dsymutil is what you are looking for. It creates a .dSYM folder named after the binary it runs on which includes debug information.
To be honest I have never actually used it. And I'm not sure what kind of stack trace you need from the remote computer.
Have you ever experienced a slow linking process in a C++ project compile (I'm using VS2013)? I get linking process taking 15 minutes after a 5 minutes Build. A Rebuild or Visual Studio restart does not fix the issue.
Task manager shows mspdbsrv.exe taking a full core (25% on a 4-core), and pdb file creation is very slow, Kb after Kb it reaches 50 Mb.
Additional info:
the same project on another computer build and link in acceptable time.
antivirus is disabled
I've tried changing the pdb file creation location: no success
I've set the linker output Verbose, but it stops at one debug row and then wait all the time there.
VS2013 is updated to SP4
Hard disk activity led on my laptop is mostly turned off, so there's no full activity on the disk.
I'm running Windows 7 Pro.
VS2013 is run with administrator rights
Thank you.
Fixed changing "Debug Information Format" from /ZI (Edit and Continue feature) to /Zi. I still have no clue why this cause a slow linking only on a specific computer and not for the others. Hope this could help people coming here for the same issue.
Is it using Link-Time Code Generation? On VS2010 that step was single threaded so it takes much longer than the apparent compile step. On later versions this step was improved to be multithreaded, according to blog posts. It also mentioned that PDB access is a bottleneck. So, maybe you have an old mspdbsrv.exe on that system? Look at the version info on the file, compared across machines. There might also be some option to control its locking and multi-use behavior, hidden away someplace.
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.
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.