I was wonder if any knows how to open up a windows *.dmp file after a application crash written C/C++.
Using Visual Studio's File>Open Project or the free WinDbg's (part of Debugging Tools for Windows) File>Open Crash Dump select the dmp file.
Make sure to configure the tools to include a path to the location of the PDB debugging symbols for that application (you do have symbols right?). Either tool has a thread and call stack window that should give you a good idea where the crash occurred. Including paths to the source code will help as well.
Symbol and Source paths can be set in WinDbg under the File menu. It's buried in Visual Studio under Tools>Options>Debugging>Symbols and Tools>Options>Project and Solutions>VC++ Directores
Here's a link to an article from Microsoft on reading the small memory dump files that Windows creates for debugging
When using Debugging Tools for Windows be sure to setup symbols. For Microsoft symbols use: SRV*DownstreamStore*http://msdl.microsoft.com/download/symbols
For example: SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols
Take a look at these blogs for more on debugging:
http://blogs.msdn.com/tom
http://blogs.msdn.com/ntdebugging
http://blogs.msdn.com/tess
If you mean a dump file created by windows (either small memory dump, kernel memory dump or full memory dump) that is created after a system crash then you need WinDBG
You should be able to just double click the .dmp file to automatically open it in Visual Studio. If the .pdb file that was generated when the program was compiled is still around, Visual Studio should be able to automatically load the symbols from that. From then on, you can just hit Run/Debug (F5) to start peeking into the .dmp file.
Related
I'm trying to profile a Win32 native application which also makes use of some external DLL's which are same Win32 native build.
When I stop data collection at some point, the profiler starts generating an overview how much process time and data are collected where - but whatever it is, it always shows me "External code" in this tree.
To clarify my problem: this happens for all positions in my application, means where sources are available and which are built with debug symbols!
Any ideas what could cause this? Thanks!
if you want show source code at debug or profiler mode, you must got pdb file for bins(include exe and dlls).
for "some external DLL's", may you can't get a match pdb.
for you win32 exe, you must generate pdb file for debug, you can google it.
I'm currently working on a tool that allows me to change C++-code on the fly. Changed files are compiled in the background, loaded from the .obj, relocated & linked, and patched into the running process.
This works fine so far.
However, I have been unable to load symbols for the new functions so that they are visible by the debugger. I have tried creating a virtual module using SymLoadModuleEx and adding symbols via SymAddSymbol, but that didn't work.
Ultimately, I would like to be able to add symbols and line information for the new functions. I could do that from either a .pdb file or the COFF info stored in the .obj (I have both), but I seem to be missing the crucial part that informs the debugger.
Is there a function for this that I simply missed? Or an undocumented code for RaiseException that is understood by the debugger (similar to naming a thread)?
I use Visual Studio, but any help in getting this to work in either the VS debugger or WinDBG is greatly appreciated.
I have built a particular dll with debug information (compiler option /Zi and linker option /DEBUG). Through an interrupt statement in the main program, I launched the Visual Studio for debugging. In the list of modules shown as seen from Debug->Windows menu, I could see that the symbols have been loaded for the dll interested in. However when I open a C++ file from that dll and try to set a breakpoint, it says debug symbols are not available for the document. There is no question that this C++ file was compiled into that dll, and that it is the same source used to build the dll (I only did it). Why does this happen? Please help, before I shoot myself.
I don't have a definitive answer, only a few suggestions.
Sometimes mdm.exe (Machine Debug Manager) stops to work properly. Terminating the process and re-starting Visual Studio helps. If the problem persists between reboots however that probably isn't the cause.
Source-file-times (last modified) that are in the future can cause all kind of weird problems. To check file times, you can do a search for nothing (Windows XP) or "*" (Windows 7). That will list all files in the selected folder. Then sort the result by date to see the max/min file time. I have no idea where the incorrect file-times come from - I just know that it happens from time to time. Might be Visual Studio itself, might be some other tool I'm using.
You could try to start the application that uses your DLL from Visual Studio, with your DLL project already open. To do that, open the "Configuration Properties", select the "Debugging" page, and enter the .exe that should be started (+ arguments if you need any). Then start the debug session as you would for a .exe project.
A cure for many problems with Visual Studio is to "clean" the project manually, and do a full re-compile. Delete all files that are generated during a build process or that store solution or project "options". i.e. all .suo .ncb .user files plus everything in the "intermediate" and "output" folders. If you're using source control, just retrieve the whole project from your source control system into a clean directory, and re-build from scratch. (Getting everything "fresh" from source control also takes care of any potential file-time problems - at least with source control systems that don't preserve file-times)
Another possible reason would be, that VS loads the wrong .pdb file. A .pdb file with a matching name could be found in a symbol server/symbol directory configured for VS (or system wide through the _NT_SYMBOL_PATH variable), or in the VS symbol cache directory. How a .pdb file with a matching name came to be in such a place is a different story, but one can easily check if the wrong .pdb file is loaded: delete the .pdb file generated by the build, and start a debug session. If VS traces "symbols loaded" for the .exe/.dll in question, it must have found a .pdb file in some other location.
Sometimes VS seems to mess up breakpoint locations in some way. I don't exactly know when or how this happens, but one of the symptoms is, that if one deletes some breakpoints, they magically reappear when starting the next debug-session. I found that setting a new breakpoint, then deleting all break points by Debug/Delete All Breakpoints, and the re-setting the required ones helps.
1) Are you not able to hit the breakpoint at all ? Generally, it gets resolved once the code in the module or stack frame needs to be hit.
2) Check if your pdb is not source information stripped
Do a Build->Clean Solution, close visual studio and then restart it and do a fresh build. This happened to me once before, and that seemed to fix it, just some outdated pdb information, I suppose.
In my case, I had renamed the C++ project. The compiler was outputting newName.lib while my other projects were still referencing oldName.lib which of course would not be removed by a Build->Clean.
I found this out by following the advice to manually clean the build directory. The subsequent linker unresolved external reference gave away the situation.
how can I create dmp files when a program crash in release build? I think I should trigger the exceptions but I don't know how
On Windows you can use the Debug Helper API to write a minidump file to any location you choose. This file does not need to be sent to Microsoft.
http://msdn.microsoft.com/en-us/library/ms680369(v=vs.85).aspx
As others have mentioned, the dump file will be useless without PDB files from the correct build. You may want to consider using Microsoft's symbol server to index and manage the PDB files.
You may also want to use Breakpad to report client errors directly to you:
http://code.google.com/p/google-breakpad/
Windows automatically generates a minidump whenever a program throws an unhandled exception (i.e. exception for which you do not have catch block).
Be sure to build pdb files (assuming you use Visual Studio) so you could debug the dmp files.
Got this callstack when I open a Windows crash dump in Visual Studio 2005:
> myprog.exe!app_crash::CommonUnhandledExceptionFilter(_EXCEPTION_POINTERS * pExceptionInfo=0x0ef4f318) Line 41 C++
pdm.dll!513fb8e2()
[Frames below may be incorrect and/or missing, no symbols loaded for pdm.dll]
kernel32.dll!_UnhandledExceptionFilter#4() + 0x1c7 bytes
...
Looking at the module load info:
...
'DumpFM-V235_76_1_0-20110412-153403-3612-484.dmp': Loaded '*C:\Program Files\Common Files\Microsoft Shared\VS7Debug\pdm.dll', No matching binary found.
...
We see that this binary was not even loaded, because the machine used to analyze the dump is a different machine than the machine that produced the dump.
I don't have access to this other machine at the moment -- can I somehow get this stack fixed, or will I always need the exact binary at this exact path location?
If you absolutely want to debug this dump in Visual Studio, then you can get away with copying the system DLLs from the machine that produced the dump to the same folder where your .dmp file is. That way, it will load those binaries instead of trying to find them in the same path on the debugging system as they were on the original system (which probably will contain different versions of the same modules).
As Naveen pointer out though, you won't have this problem when loading the dump in WinDBG (for reasons I have yet to understand). That is why when I get a dump from clients, I always analyze them in WinDBG.
If you need help on using WinDBG for crash dump analysis, the following Web site is full of info on the subject: http://www.dumpanalysis.org/.
Another option is to use the ModuleRescue tool from the folks at DebugInfo.com. This will scan a dump file, allow you to choose the module that isn't loading symbols, and then it generates a fake module that has just enough info in it for the debugger to load the symbols from the symbol server.
When Visual Studio can't load the symbols for this module and opens a dialog asking you to find the symbols, just point your debugger at that fake module and it will load correctly.
This tool basically does the same thing that WinDbg does, albeit with a different workflow.