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.
Related
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.
I know that with windows you can generate a dump file by going to task manager->processes-> right clicking on the process.
what is a dump file ?
what can i do with .dmp file?
A .dmp file is a Minidump, a snapshot of a live process containing information about its current state (including memory, stack traces, thread information, module information, exception context information). This information allows you to inspect a snapshot of a process. It is often generated when a process is about to crash due to an unhandled exception, but can be taken at any point.
It can be created using the MiniDumpWriteDump API, and opened with any Windows Debugger (like Visual Studio1) or WinDbg, KD, CDB, NTSD). See Crash Dump Analysis for additional information.
1) Depending on the information present in the Minidump file, Visual Studio may not be able to open a specific .dmp file. The other debuggers do not impose any restrictions, as far as I know.
As per https://msdn.microsoft.com/en-gb/library/d5zhxt22.aspx a dump file is a snapshot of the application at that moment in time.
Dump files are used to aid debugging applications when they go wrong.
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 have a customer who is getting a 100% reproduceable crash that I can't replicate in my program compiled in Visual Studio 2005. I sent them a debug build of my program and kept all the PDB and DLL files handy. They sent me the minidump file, but when I open it I get:
"Unhandled exception at 0x00000000 in MiniDump.dmp: 0xC0000005: Access violation reading location 0x00000000."
Then the call stack shows only "0x00000000()" and the disassembly shows me a dump of the memory at 0x0. I've set up the symbol server, loaded my PDB symbols, etc. But I can't see any way of knowing which of the many DLLs actually caused the jump to null. This is a large project with many dependencies, and some of them are binaries that I don't have the source or PDBs for, as I am using an API as a 3rd party.
So how on earth is this minidump useful? How do I see which DLL caused the crash? I've never really used minidumps for debugging before, but all the tutorials I have read seem to at least display a function name or something else that gives you a clue in the call stack. I just get the one line pointing to null.
I also tried using "Depends" to see if there was some DLL dependency that was unresolved; however on my three test machines with various Windows OS's, I seem to get three different sets of OS DLL dependencies (and yet can't replicate the crash); so this doesn't seem a particularly reliable method either to diagnose the problem.
What other methods are available to determine the cause of this problem? Is there some way to step back one instruction to see which DLL jumped to null?
Well it looks like the answer in this instance was "Use WinDbg instead of Visual Studio for debugging minidumps". I couldn't get any useful info out of VS, but WinDbg gave me a wealth of info on the chain of function calls that led to the crash.
In this instance it still didn't help solve my problem, as all of the functions were in the 3rd party library I am using, so it looks like the only definitive answer to my specific problem is to use log files to trace the state of my application that leads to the crash.
I guess if anyone else sees a similar problem with an unhelpful call stack when debugging a minidump, the best practice is to open it with WinDgb rather than Visual Studio. Seems odd that the best tool for the job is the free Microsoft product, not the commerical one.
The other lesson here is probably "any program that uses a third party library needs to write a log file".
The whole idea behind all 'simple' ways of post mortem debugging is the capture of a stack trace. If your application overwrites the stack there is no way for such analysis. Only very sophisticated methods, that record the whole program execution in dedicated hardware could help.
The way to go in such a case are log files. Spread some log statements very wide around the area where the fault occurs and transmit that version to the customer. After the crash you'll see the last log statement in your log file. Add more log statements between that point and the next log statement that has not been recorded in the log file, ship that version again. Repeat until you found the line causing the problem.
I wrote a two part article about this at ddj.com:
About Log Files Part 1
About Log Files Part 2
Just an observation, but the the stack is getting truncated or over-written, might this be a simple case of using an uninitialised field, or perhaps a buffer overrun ?
That might be fairly easy to locate.
Have you tried to set WinDbg on a customer's computer and use it as a default debugger for any application that causes a crash? You just need to add pdb files to the folder where your application resides. When a crush happens WinDbg starts and you can try to get call stack.
Possibly you already know this, but here are some points about minidump debugging:
1. You need to have exactly the same executables and PDB files, as on the client computer where minidump was created, and they should be placed exactly in the same directories. Just rebuilding the same version doesn't help.
2. Debugger must be connected to MS Symbols server.
3. When debugger starts, it prints process loading log in the Output window. Generally, all libraries should be successfully loaded with debug information. Libraries without debug information are loaded as well, but "no debug info" is printed. Learn this log - it can give you some information.
If executable stack contains frames from a library without debug information, it may be not shown. This happens, for example, if your code is running as third-party library callback.
Try to create minidump on your own computer, by adding some code which creates unhandled exception, and debug it immediately. Does this work? Compare loading log in successful and unsuccessful debugging sessions.
You may have called null function pointer. Current executing function information is needed to show call stack information. Force set instruction pointer to start of any simple function, then you'll see call stack information again.
void SimpleFunc()
{ // <- set next statement here
}