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.
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.
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.
I have a project in VC++ 6.0 where there is an exe and a InProc COM Dll. I want to be able to place a breakpoint somewhere in the InProc COM DLL, but VC++ won't allow me to set a breakpoint.
I have the source code for this DLL, however I cannot figure out how I can place a breakpoint in the code and the debug it?
Can someone help me.
It has been some time since I worked with COM but IIRIC, inside your COM project configure your executable as the launching application. It should work (sorry, I don't have VC++ 6.0 installed here anymore :().
If it doesn't work, you can try to attach the debugger to the running application.
In either cases make sure you have full debug information in your COM server.
Hope this helps.
Attach to the process
Open Project->Settings (Alt+F7)
Open Debug tab, category Additional DLLs
Add you in-proc server DLL
Save .opt file on closing the debugger
This way next time you attach to process or manually open the .opt file, your in-proc server DLL gets loaded, its PDB gets parsed, last open source files get loaded, breakpoints get loaded.
The reason why "additional dlls" setting is needed here is because you in-proc server doesn't get loaded until an instance of his is CoCreated. So the debugger doesn't load its PDB file and the source files are treated as unknown text files, so the breakpoints in them get inactive (white).
Two things you can look into
Uncheck Require source files to exactly match the original version in the Debugging options dialog
If that fails, compile the DLL again (preferably with optimizations disabled /Od) and use the new DLL with its PDB file.
Not sure if this will work in VC6 but you could try _asm int 3 where you want the code to break, this should cause a breakpoint in your code and allow you to debug it.
One of our users having an Exception on our product startup.
She has sent us the following error message from Windows:
Problem Event Name: APPCRASH
Application Name: program.exe
Application Version: 1.0.0.1
Application Timestamp: 4ba62004
Fault Module Name: agcutils.dll
Fault Module Version: 1.0.0.1
Fault Module Timestamp: 48dbd973
Exception Code: c0000005
Exception Offset: 000038d7
OS Version: 6.0.6002.2.2.0.768.2
Locale ID: 1033
Additional Information 1: 381d
Additional Information 2: fdf78cd6110fd6ff90e9fff3d6ab377d
Additional Information 3: b2df
Additional Information 4: a3da65b92a4f9b2faa205d199b0aa9ef
Is it possible to locate the exact place in the source code where the exception has occured having this information?
What is the common technique for C++ programmers on Windows to locate the place of an error that has occured on user computer?
Our project is compiled with Release configuration, PDB file is generated.
I hope my question is not too naive.
Yes, that's possible. Start debugging with the exact same binaries as ran by your user, make sure the DLL is loaded and you've got a matching PDB file for it. Look in Debug + Windows + Modules for the DLL base address. Add the offset. Debug + Windows + Disassembly and enter the calculated address in the Address field (prefix with 0x). That shows you the exact machine code instruction that caused the exception. Right-click + Go To Source code to see the matching source code line.
While that shows you the statement, this isn't typically good enough to diagnose the cause. The 0xc0000005 exception is an access violation, it has many possible causes. Often you don't even get any code, the program may have jumped into oblivion due to a corrupted stack. Or the real problem is located far away, some pointer manipulation that corrupted the heap. You also typically really need a stack trace that shows you how the program ended up at the statement that bombed.
What you need is a minidump. You can easily get one from your user if she runs Vista or Win7. Start TaskMgr.exe, Processes tab, select the bombed program while it is still displaying the crash dialog. Right-click it and Create Dump File.
To make this smooth, you really want to automate this procedure. You'll find hints in my answer in this thread.
If you have a minidump, open it in Visual Studio, set MODPATH to the appropriate folders with the original binaries and PDBs, and tell it to "run". You may also need to tell it to load symbols from the Microsoft symbol servers. It will display the call stack at the error location. If you try to look at the source code for a particular stack location, it may ask you where the source is; if so, select the appropriate source folder. MODPATH is set in the debug command-line properties for the "project" that has the name of the minidump file.
I know this thread is very old, but this was a top Google response, so I wanted to add my $.02.
Although a mini-dump is most helpful, as long as you have compiled your code with symbols enabled (just send the file without the .pdb, and keep the .pdb!) you can look up what line this was using the MSVC Debugger or Windows Debugger. MSN article on that:
http://blogs.msdn.com/b/danielvl/archive/2010/03/03/getting-the-line-number-for-a-faulting-application-error.aspx
Source code information isn't preserved in compiled C++ code, unlike in runtime-based metadata-aware languages (such as .NET or Java). The PDB file is a symbol index which can help a debugger map compiled code backwards to source, but it has to be done during program execution, not from a crash dump. Even with a PDB, Release-compiled code is subject to a number of optimizations that can prevent the debugger from identifying the source code.
Debugging problems which only manifest on end-user machines is usually a matter of careful state logging and a lot of detail-oriented time and effort combing over the source. Depending on your relationship with the user (for example, if you're internal corporate IT development), you may be able to make a virtual machine image of the user's machine and use it for debugging, which can help speed the process tremendously by precisely replicating the installed software and standard running processes on the user's workstation.
There are several ways to find the crash location after the fact.
Use a minidump. See the answers above.
Use the existing executable in a debugger. See the answers above.
If you have PDB files (Visual Studio, Visual Basic 6), use DbgHelpBrowser to load the PDB file and query it for the crash location.
If you have TDS files (separate TDS file, or embedded in the exe, Delphi, C++ Builder 32 bit), use TDS Browser to load the TDS/DLL/EXE file and query it for the crash location.
If you have DWARF symbols (embedded in the EXE, C++ Builder 64 bit, gcc, g++), use DWARF Browser to load the DLL/EXE and query it for the crash location.
If you have MAP files, use MAP File Browser to load the MAP file and query it for the crash location.
I wrote these tools for use in house. We've made them available for free.
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.