Click here to Skip to main content
Click here to Skip to main content
Search within:



 
Comments & Discussions (172)

Post-Mortem Debugging Your Application with Minidumps and Visual Studio .NET

By , 6 Mar 2002
 

Summary: If your application crashes at a customer site, you can now debug it after the fact using minidumps and the Microsoft® Visual Studio® NET debugger. This article describes how minidumps work, how to make your application create them when it crashes, and how to read them back with Visual Studio .NET. Minidumps are key to the Microsoft error reporting program to improve the reliability of the Windows operating system and applications such as Visual Studio .NET. This article also describes how to use the Microsoft symbol server to automatically find symbols for system components. This article assumes that you are familiar with Win32 and C++ programming.

Contents

What Is a Minidump?
Creating a Minidump
Build Issues
Writing a Minidump with MiniDumpWriteDump
Reading a Minidump with Visual Studio .NET
How Microsoft Uses Minidumps
Further Improvements
Conclusion

What Is a Minidump?

A minidump is a file containing the most important parts of a crashed application. It is written on the user’s machine and then the customer can submit it to the developer. The developer can load the dump to help determine the cause of the crash and develop a fix.

Since the early days of Windows NT, the Dr. Watson program has been able to generate crash dump files, denoted with the .dmp extension. However, they were not as useful as they should have been because of two problems:

  1. They were huge. The dump of an application included every byte of the entire process space, so a crash in something simple like Notepad would be several megabytes in size, and a crash in something like Word can be many hundreds of megabytes. The files were just too big to send by e-mail or FTP.
  2. Their content was not necessarily useful. Dr. Watson was, in fact, a just-in-time (JIT) debugger, and it is difficult for a debugger to get the full path to a loaded module. Full debuggers such as the Visual Studio debugger complete a number of steps to get the paths, but Dr. Watson did not. This usually resulted in unhelpful module names such as MOD0000 and so on.

Minidumps were designed to fix these problems in a number of ways:

  • Instead of saving the entire process space, only certain sections are saved. There is no point in saving copies of modules such as Kernel32.dll; if the version number is included, it is easy to get a copy from a Windows CD. The actual memory heap of the application is by default not saved in a minidump; it is not required to debug a surprisingly high percentage of crashes. You can save the heap if you need to, however.
  • The minidump save code works to get accurate and full information for modules, including their names, paths, version information, and internal timestamps.
  • The minidump save code also gets the list of threads, their contexts (that is, register sets), and the memory behind their stacks.
  • The whole file is compressed, further reducing its size. A minidump for Notepad is around 6K on Windows XP, almost 300 times smaller than the previous crash dump of the same process.

Note   Kernel-mode minidumps, which are generated by Windows XP after a computer stops responding, also exist, but this article discusses more common user-mode minidumps.

Creating a Minidump

There are three ways to create a minidump:

  • Add code to your own application to write a minidump if the application has an unhandled exception.
  • In the integrated development environment of Visual Studio .NET, click Save Dump on the Debug menu when debugging the application.
  • Do nothing.

The first option is discussed in more detail in the following sections.

The second option works only on a workstation with the debugger already configured, which is likely useful only within an organization (for example, with another developer or tester). If you debug a crash with Visual Studio .NET, you can then click Save Dump As on the Debug menu. You can save as a Minidump or Minidump With Heap. You do not need any symbols or PDBs configured to save a dump file; you will need them later, however, to read it back.

The third option works only in Windows XP, which automatically creates a minidump if an application has an unhandled exception and no JIT debugger has been set up. Also, the minidump is submitted directly to Microsoft, so you will not have the opportunity to determine why.

Build Issues

To configure your application to create dumps when it stops responding, you must configure your builds to generate full debugging information, especially for retail builds. After generating a PDB, you also must archive every binary that ships to customers and its matching PDB; you will need the PDB later to debug any minidumps that your customers submit.

Also, ensure that you set the version information correctly on your binaries. Every release of every component that you ship should have a different version, so you can match them to the minidump. The version field assists you in matching the bits. The debugger itself does not use the version information, however; it matches binaries based on the internal timestamp in the PE header.

In terms of output, generating debug information for release builds has a small effect. A PDB, taking up some space on a build machine, is generated, and the binary will be a few hundred bytes larger, to record the name of the PDB in the debug directory within the PE file. You should not provide customers with the PDB; this could allow customers to more easily reverse-engineer your application.

Writing a Minidump with MiniDumpWriteDump

The key API to saving a minidump is MiniDumpWriteDump, which is exported from Dbghelp.dll, a redistributable DLL that comes with the Platform SDK. Make sure that you are using the Windows XP version 5.1.2600; earlier beta and release candidate versions had problems with the API, and versions 5.0.x are from Windows 2000 and do not export the function. If you have a version earlier than 5.0, then it comes from the Systems Debugger package (including WinDbg and so on) and is not redistributable.

To call the API, you need to catch the crash by setting an unhandled exception handler with the SetUnhandledExceptionFilter API. This allows the filter function to be called at almost any time an unhandled exception occurs in an application. In certain unhandled exceptions, such as a double stack fault, the operating system will immediately terminate the application without calling the filter or a JIT debugger.

In your filter function, you must load Dbghelp.dll. This is not as simple as calling LoadLibrary; as with Windows 2000, you will access the one from the System32 directory, which does not have the right export. The sample code in the attached file tries to load from the same location as the EXE. Install the correct version of Dbghelp.dll into the same directory as the EXE; if this does not work, then the code reverts to a plain LoadLibrary, which will only work if the application is running on Windows XP.

After loading the DLL, it then checks for the named export; if correct, it then creates a file with an appropriate name, such as saving to the Temp directory and using the application name with the .dmp extension. This handle is then passed to the API itself, with some additional information such as the process ID and the type of dump file. The sample uses MiniDumpNormal. You may want to or-in the flag value of MiniDumpWithDataSegs, which is the equivalent to the Minidump With Heap option in the Visual Studio debugger. This does result in substantially larger dump files.

Once the .dmp file is created, the application informs the user where it is stored. The user can then e-mail it or use FTP to get you the file to investigate.

To use the sample code provided, add the mdump.h file and declare one MiniDumper object at global scope. Its constructor takes an argument, which should be the basename of the minidump file. Add mdump.cpp to your project. You need to have the correct Dbghelp.dll file in the same directory as the EXE to run successfully.

You cannot debug the code that writes the minidump with a debugger (in the sample code, Minidumper::TopLevelFilter). If a debugger is attached to a process, then the unhandled exception filter will never be called. If you encounter problems, you will need to use MessageBox debugging.

Reading a Minidump with Visual Studio .NET

This section uses an example of a manually created minidump from Notepad in Windows 2000 and debugging in Windows XP.

Start Visual Studio .NET and, on the File menu, click Open Solution. Change the Files of type drop-down menu to Dump Files (*.dmp; *.mdmp), navigate to the minidump, and create a default project by clicking Open.

To launch the dump with the debugger, press F5. This will provide you with information to get started. The debugger creates a fake process; in the Output window, various module load messages are displayed. The debugger is recreated the crashed processes state only. After displaying a warning that the EXE contains no debug information, the debugger stops with the user's crash, such as an access violation. If you then examine the Call Stack window, you will notice the lack of symbols and a lack of useful information.

Figure 1. Initial Stack with No Symbols

To read a minidump, you typically need copies of the binaries involved. To find the right binaries, open the Modules window.

Figure 2. Initial Modules with No Binaries

Figure 2 shows the Notepad example and demonstrates two things. First, the paths to the binaries are marked with asterisks, which denotes the path on the user's workstation but the binary could not be found at that location on your machine. Second, the messages read “No matching binary found” in the Information field. The key to finding matching binaries is to look at the Version field and the file name. In this example, the version of most system files is 2195, which indicates Windows 2000. It does not immediately indicate the exact service pack (SP) or quality fix engineering (QFE), however. For more information, see the DLL Help database at http://support.microsoft.com/servicedesks/fileversion/dllinfo.asp.

At this point, you will need to find a Windows operating system CD or a user's workstation with the correct versions and copy the correct versions into a directory. It is not normally necessary to find every binary that was in the process, but it is important to find each binary that features on every relevant call stack. This will often involve both operating system binaries (such as Kernel32.dll) and your application binaries (in this example, Notepad.exe).

When you have found the bits and copied them to a local directory, on the Debug menu, click Stop Debugging. In Solution Explorer, right-click the project icon and click Properties on the shortcut menu. This will take you to the Debugging page. Fill in the Command Arguments to be MODPATH, followed by an equal sign, and followed by a semicolon-delimited list of places to look for binaries. In this example, it is:

MODPATH=m:\sysbits

After setting the path, press F5 to reload the minidump. MODPATH reuses the command argument to get the value to the debugger; a future version of Visual Studio .NET may have a better way of setting this, perhaps as an option in the Properties dialog box.

Although finding the binaries is unlikely to improve the call stack, it should resolve some issues in the Modules window, as shown in Figure 3.

Figure 3. Modules with Binaries

Instead of saying “No matching binary found”, it now says a combination of “Cannot find or open a required DBG file” or “No symbols loaded”. The first message occurs with system DLLs that use DBGs for their debugging information. The second message occurs for DLLs that use PDBs. Getting matching binaries will not necessarily improve your call stack; you also need debug information that matches them.

Method A: Symbols the Hard Way

To completely analyze a minidump, you should find debug information for everything, but to save time, you can find only the information you need. The example stack lists User32.dll and Kernel32.dll, so they need matching debug information.

Matching Debug Information

Operating system

Files required

Windows NT 4

DBGs

Windows 2000

DBGs, PDBs

Windows XP

PDBs

The best place to locate system symbols is at http://www.microsoft.com/ddk/debugging. You can also locate system symbols on the Support compact disc that ships with Windows NT Server and Windows 2000 Server operating systems. In this example, they were copied to the location of the binaries. In real instances, you will have non-Microsoft binaries listed, so you will need to have PDBs for them. Also in this example, the DBG and PDB for Notepad were also copied, because it was the sample application used.

After you click Stop Debugging on the Debug menu, pressing F5 will list a call stack, as shown in Figure 4. You may find that, as you add new binaries and debug information, your call stack will change. This is to be expected; a call stack can only be walked accurately with debug information, so as you add more information, your stack will get more accurate, which will often expose additional frames that were not in the original.

In this example, there was no crash. In real instances, you would have sufficient information to determine the cause of around 70 percent of your user crashes. In addition, this stack was created with the stripped symbols that Microsoft ships for system component, so there was no line number information. For your own binaries with full PDBs, you will get an even richer stack.

Figure 4. Call Stack with Symbols and Binaries

Symbol Servers

If you are dealing with many minidumps and performing general debugging, storing and accessing all the binary and PDB/DBG files can be difficult. Windows NT developed a technology known as a symbol server, which was originally conceived as storage for symbols but was extended to support finding binary files. The Windows NT debugger was the first tool to support this, but Visual Studio .NET also does so as an undocumented feature. For more information on symbol server, see http://www.microsoft.com/ddk/debugging/symbols.asp.

You can also retrieve symbols from the Microsoft symbol server. These symbols will be cached and indexed locally for you.

Method B: Symbols The Easy Way: Using Symbol Server

First, go to http://www.microsoft.com/ddk/debugging and download the debugging tools. You need Symsrv.dll, which needs to be on the path. You can either copy it next to devenv.exe or into your System32 directory, to allow Visual Studio .NET access to it. Once you have copied Symsrv.dll, you can safely uninstall the debugging tools. You will also need to make a local directory. For this example, create a local directory as C:\localstore.

In the Project Properties dialog box, set the Symbol Path on the Debugging page to:

SRV*c:/localstore*http://msdl.microsoft.com/download/symbols

This string tells the debugger to use the symbol server to get symbols and create a local symbol server, where they will be copied. Now, when you press F5 on the minidump, the symbols are copied from the Microsoft Web site, copied to the local store, and then used by the debugger. After the first time you do this, your performance will be quicker, because they will be retrieved from the local store rather than from the Web.

When debugging a non-Microsoft application, you should use a combination of methods A and B. Use A to get the system components and add paths to your bits and symbols by separating them with semicolons, such as:

c:\drop\build\myapp;SRV*c:\localstore*http://msdl.microsoft.com/download/symbols

Because the symbol server is an undocumented feature of Visual Studio .NET, there is no error reporting. If the syntax is incorrect or Symsrv.dll is not on the path, the symbols will fail to load with the error "No symbols loaded". You can also use symbol servers to store and retrieve binaries, but the MODPATH syntax needs to use symsrv*symsrv.dll* instead of SRV*.

Note   The Microsoft symbol server does not contain binary files, but any symbol servers that you create can.

Symbol servers work for "live" debugging, as well, not only for minidumps. To do this, you will need to set the Symbol Path on the Debugging page properly.

How Microsoft Uses Minidumps

Microsoft has been using minidumps to improve the quality of its applications for more than a year. Microsoft Internet Explorer 5.5 and Microsoft Office XP were the first products to ship with the new Dr. Watson, a utility that catches when an application stops responding, creates a minidump, and asks the user if he or she wants to submit the information to Microsoft.

If the user clicks Send Error Report, then Dr. Watson creates and submits the minidump to a server on the Microsoft Web site. The utility performs the user prompting and minidump saving in a different process, which is spawned from the crashing process. This places less demand on the crashed application, increasing the chances of getting a valid minidump from the user.

Further Improvements

On the server side, the minidumps are analyzed into areas of similar crashes, based on where the crash occurred and in what component. This gives product teams statistics of how often the application crashed and how often a given crash occurs. The teams also receive the actual minidumps of the crashes for further investigation. In some cases where the crash is fully understood, users are automatically directed to a Web page that contains information about a known workaround or contains a fix to correct the problem. Since the release of Internet Explorer 5.5 and Office XP, many other product teams use similar technology to gather crash information. It is also a standard part of Windows XP.

The sample discussed in this article provides a basis for understanding minidumps. The sample does not discuss retrieving the dump file from the user. In the simplest case, the user can be prompted to send the minidump by e-mail. Also, potential privacy issues can occur, because user data may be present on the stack and is guaranteed to be present in a minidump that includes the full heap. This should be made clear to users. The Microsoft data collection policy, which also contains additional information about the exact contents of minidumps, is at http://watson.microsoft.com/dw/1033/dcp.asp.

In addition, the creation of minidumps from a Windows service that has an unhandled exception poses additional challenges, to do with desktop access (for example, if no one is using the console, then you cannot prompt them) and security contexts.

Conclusion

Minidumps are a new technology to port-mortem debug crashes on user workstations. It is easy to add code to existing applications to automatically create them when an unhandled exception occurs. Visual Studio .NET can easily read them back to recreate the crash and allow the developer to debug the problem. Symbol server can be used to make it much easier to find system symbols to aid in this analysis.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here

About the Author

 Andy Pennell
Web Developer
United States United States
Member
I'm a developer at Microsoft on Visual Studio. I am responsible for the native code debugger, the SQL debugger, plus much of the debugger's infrastructure. I've been a debugger developer at MS for six years, plus for other people many years before. Anyone used the 68k versions of HiSoft Devpac in the early 80s? That was me.

Article Top
 
Sign Up to vote   Poor Excellent
Add a reason or comment to your vote: x
Votes of 3 or less require a comment

Comments and Discussions

 
You must Sign In to use this message board.
Search this forum  
    Spacing  Noise  Layout  Per page   
FirstPrevNext
GeneralRe: Multiple instances of MiniDumper and use in a DLLmemberHarold Bamford6 Dec '10 - 5:39 
Thanks for the quick response.
Sign In·View Thread·Permalink
QuestionCreates dmp, but WinDBG doesnt align the stack and source windowsmemberBillInPA9 Nov '10 - 7:16 
In vis studio 2008 or 2010, when debugging you can pick Debug/Save Dump As
 
If you then open the dmp file in WinDBG, it aligns the stack, source windows, and you can hover over a local variable to get a tool tip with its value at the time of the crash
 
Ive built this sample, and many othrs - I can create the dmp files, but when I open them in WinDBG, it has some undecorated minimal information, and the stack/source windows are unavailable
 
I have tried samples that use the deeper levels of minidump information flags, they make a larger dmp file but WinDBG still doesnt seem to have enough information to hook up the stack and source windows
 
Has anyone had a similar experience, and does anyone know what I am doing wrong/how to get the dmp to be readable by WinDBG as the vis studio output is?
Bill in PA/USA
Sign In·View Thread·Permalink
GeneralThanks alot works great !memberJochen Baier7 Nov '10 - 11:02 
hi,
 
i included automatic crash reporting in my project. Works great!
 

Jochen
Sign In·View Thread·Permalink
GeneralMiniDump Versus Dr WatsonmemberAltran Jeff12 May '10 - 22:35 
Hi All, 'newbie' question here!
 
We are looking after a 10 year old large lump of a C++ application under a new maintenance job.
 
This app crashes randomly under reasonably heavy load. (After 10 years in service in a safety related context OMG | :OMG: )
 
We have 'permission' to investigate this a little, and the suggestion is simply to use Dr Watson to get some information from the debris.
 
However, the minidumper seems more comprehensive.
 
Is there a straightforward way I can compare Dr Watson Vs MiniDumper to put before 'the management'?
 
Thanks
 
Jeff Adams
Sign In·View Thread·Permalink
GeneralRe: MiniDump Versus Dr WatsonmemberAltran Jeff13 May '10 - 1:28 
Ah - so sorry - should have read the article more carefully. All I needed was in there already. Dead | X|
 
Thanks
 
Jeff
Sign In·View Thread·Permalink
GeneralWhen debuging the code, you can...memberreeman3 Mar '09 - 17:45 
You cannot debug the code that writes the minidump with a debugger (in the sample code, Minidumper::TopLevelFilter). If a debugger is attached to a process, then the unhandled exception filter will never be called. If you encounter problems, you will need to use MessageBox debugging.
 
An alternative way is shown here:
http://blog.kalmbachnet.de/?postid=75[^]
 
Except that the sequece of the routine call in _tmain()
maybe it should be:
...
BOOL bRet = PreventSetUnhandledExceptionFilter();
SetUnhandledExceptionFilter(MyUnhandledExceptionFilter);
...
Hopefully, it will help Smile | :)
Sign In·View Thread·Permalink
QuestionLicense of code sample?memberDhruva Krishnamurthy25 Nov '08 - 2:15 
Can I use the code verbatim in my proprietary code? Since the code is small, even if I have to write it myself, it will not be too different.
 
Thanks,
dhruva
Sign In·View Thread·Permalink
GeneralCrash reporting comparisonmembermeco114411 Jul '08 - 8:32 
Hi,
Do you know what is the difference of using .NET minidumps (generated with Dbghelp.dll) and the minidumps generated with the open source library named Breakpad? I think Breakpad use Dbghelp.dll to generate minidumps, but if I can manage the exceptions using the information provided in the link copied below, I don't know what is this library for? (I'm talking about Breakpad's exception handler library)
 
Thanks in advance,
 
Vlad
 
How to use Dbghelp.dll: http://www.codeproject.com/KB/debug/postmortemdebug_standalone1.aspx?fid=3419&df=90&mpp=25&noise=3&sort=Position&view=Quick&select=2441205
Breakpad: http://code.google.com/p/google-breakpad/
Sign In·View Thread·Permalink
GeneralHaving compilation problem...memberVite Falcon26 Jun '08 - 6:15 
This is the compilation error i get when trying to use mdump.h and mdump.cpp in my project WTF | :WTF: ...
1>e:\program files\microsoft visual studio 8\vc\platformsdk\include\dbghelp.h(61) : error C2146: syntax error : missing ';' before identifier 'ModuleName'
1>e:\program files\microsoft visual studio 8\vc\platformsdk\include\dbghelp.h(61) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>e:\program files\microsoft visual studio 8\vc\platformsdk\include\dbghelp.h(61) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>e:\program files\microsoft visual studio 8\vc\platformsdk\include\dbghelp.h(62) : error C2146: syntax error : missing ';' before identifier 'hFile'
1>e:\program files\microsoft visual studio 8\vc\platformsdk\include\dbghelp.h(62) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>e:\program files\microsoft visual studio 8\vc\platformsdk\include\dbghelp.h(62) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>e:\program files\microsoft visual studio 8\vc\platformsdk\include\dbghelp.h(63) : error C2146: syntax error : missing ';' before identifier 'MappedAddress'
1>e:\program files\microsoft visual studio 8\vc\platformsdk\include\dbghelp.h(63) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>e:\program files\microsoft visual studio 8\vc\platformsdk\include\dbghelp.h(63) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>e:\program files\microsoft visual studio 8\vc\platformsdk\include\dbghelp.h(67) : error C2146: syntax error : missing ';' before identifier 'FileHeader'
1>e:\program files\microsoft visual studio 8\vc\platformsdk\include\dbghelp.h(67) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>e:\program files\microsoft visual studio 8\vc\platformsdk\include\dbghelp.h(67) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>e:\program files\microsoft visual studio 8\vc\platformsdk\include\dbghelp.h(69) : error C2146: syntax error : missing ';' before identifier 'LastRvaSection'
1>e:\program files\microsoft visual studio 8\vc\platformsdk\include\dbghelp.h(69) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>e:\program files\microsoft visual studio 8\vc\platformsdk\include\dbghelp.h(69) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>e:\program files\microsoft visual studio 8\vc\platformsdk\include\dbghelp.h(70) : error C2146: syntax error : missing ';' before identifier 'NumberOfSections'
1>e:\program files\microsoft visual studio 8\vc\platformsdk\include\dbghelp.h(70) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>e:\program files\microsoft visual studio 8\vc\platformsdk\include\dbghelp.h(70) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>e:\program files\microsoft visual studio 8\vc\platformsdk\include\dbghelp.h(71) : error C2146: syntax error : missing ';' before identifier 'Sections'
1>e:\program files\microsoft visual studio 8\vc\platformsdk\include\dbghelp.h(71) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>e:\program files\microsoft visual studio 8\vc\platformsdk\include\dbghelp.h(71) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
.........[cut to avoid the wrath of those going through this :omg: ]........
1>e:\program files\microsoft visual studio 8\vc\platformsdk\include\dbghelp.h(91) : fatal error C1903: unable to recover from previous error(s); stopping compilation
 
Any help will be much appreciated.... thanks...
Sign In·View Thread·Permalink
QuestionWhat about Visual Studio 2008 and Server 2008?memberM.Vo.10 Jun '08 - 6:37 
Hi, I've got a Server 2008 with Visual Studio 2008, select the dmp-File as desribed, press F5, but get only the following messagebox:
 
---------------------------
Microsoft Visual Studio
---------------------------
Unable to start program 'C:\Data\Mini061008-01.dmp'.
 

The specified file is an unrecognized or unsupported binary format.
---------------------------
OK
---------------------------
 
Any ideas?
Thank you!
Martin
Sign In·View Thread·Permalink
AnswerRe: What about Visual Studio 2008 and Server 2008?memberkinchungwong7 Nov '08 - 12:17 
Some dump files are kernel (OS) dump files. Visual studio wouldn't open such dump files.
 
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=101034[^]
Sign In·View Thread·Permalink
Questiondifferent results with release and debug binariesmemberRui Fernandes4 Jun '08 - 9:18 
Hi,
 
I've used your class with some code added and I get different results with debug and release binaries.
With the debug executable I can see the heap and stack, however when I generate de dump file using a release version the only thing I can see is the stack. The executable staticaly links to several libraries.
I'm using VC++ 8.0. The release version was compiled with /Zi and /DEBUG options for the libraries and the executable.
 
Could you please help me diagnose the problem? I'm executing the binaries in the same machine I used to build.
 
Thank you very much.
Rui.
 
My mdump.cpp is as follows:
 
------------ BEGIN --------------
#if defined (_WIN32)
 
#include
 
#include
#define BUSINCLUDES
#include
#undef BUSINCLUDES
 
// use library
//#pragma comment ( lib, "dbghelp.lib" )
 
extern void makeReport (const EFAString applicationId, const EFAString& message);
 
WCHAR MiniDumper::szImageFileName[_MAX_FNAME] = L"";
WCHAR MiniDumper::szImageFullPath[_MAX_PATH] = L"";
 
static const unsigned long error_buff_size = 512;
 
MiniDumper::MiniDumper()
{
// get fully-qualified path of the executable
if (GetModuleFileNameW( NULL, szImageFullPath, _MAX_PATH )) {
// extract the executable file name (without the extension)
_wsplitpath( szImageFullPath, NULL, NULL, szImageFileName, NULL );
}
 
::SetUnhandledExceptionFilter( TopLevelFilter );
}
 
//static
BOOL CALLBACK MiniDumper::MyMiniDumpCallback(
PVOID pParam,
const PMINIDUMP_CALLBACK_INPUT pInput,
PMINIDUMP_CALLBACK_OUTPUT pOutput
)
{
BOOL bRet = FALSE;
 
// Check parameters
 
if( pInput == 0 )
return FALSE;
 
if( pOutput == 0 )
return FALSE;
 
// Process the callbacks
 
switch( pInput->CallbackType )
{
case IncludeModuleCallback:
{
// Include the module into the dump
bRet = TRUE;
}
break;
case IncludeThreadCallback:
{
// Include the thread into the dump
bRet = TRUE;
}
break;
case ModuleCallback:
{
// Are data sections available for this module ?
if( pOutput->ModuleWriteFlags & ModuleWriteDataSeg )
{
// Yes, they are, but do we need them?
if( !IsDataSectionNeeded( pInput->Module.FullPath ) )
{
// Excluding module data sections
pOutput->ModuleWriteFlags &= (~ModuleWriteDataSeg);
}
}
 
bRet = TRUE;
}
break;
case ThreadCallback:
{
// Include all thread information into the minidump
bRet = TRUE;
}
break;
case ThreadExCallback:
{
// Include this information
bRet = TRUE;
}
break;
case MemoryCallback:
{
// We do not include any information here -> return FALSE
bRet = FALSE;
}
break;
case CancelCallback:
break;
}
 
return bRet;
}
 
// static
LONG MiniDumper::TopLevelFilter( struct _EXCEPTION_POINTERS *pExceptionInfo )
{
LONG retval = EXCEPTION_CONTINUE_SEARCH;
 
if( wcsicmp( szImageFullPath, L"" ) == 0 ) // no class instance was created
return retval;
 
// firstly see if dbghelp.dll is around and has the function we need
// look next to the EXE first, as the one in System32 might be old
// (e.g. Windows 2000)
HMODULE hDll = NULL;
 
WCHAR* szDbgHelpPath;
szDbgHelpPath = _wcsdup(szImageFullPath);
WCHAR *pSlash = wcsrchr( szDbgHelpPath, '\\' );
if (pSlash)
{
wcscpy( pSlash+1, L"DBGHELP.DLL" );
hDll = ::LoadLibraryW( szDbgHelpPath );
free(szDbgHelpPath);
}
else {
free(szDbgHelpPath);
return retval; // something wrong !
}
 
if (hDll==NULL)
{
// load any version we can
hDll = ::LoadLibraryW( L"DBGHELP.DLL" );
}
 
if (hDll)
{
MINIDUMPWRITEDUMP pDump = (MINIDUMPWRITEDUMP)::GetProcAddress( hDll, "MiniDumpWriteDump" );
if (pDump)
{
char szScratch [_MAX_PATH];
 
// the dump file will be located next to the executable.
WCHAR* szDumpPath = szImageFullPath; // no need to copy because the class attr won't be needed anymore
WCHAR* pSlash = wcsrchr( szDumpPath, '\\' ); // if slash was absent then would not reach this execution point
wcscpy( pSlash+1, L"core-" );
wcscat( szDumpPath, szImageFileName);
wcscat( szDumpPath, L".dmp");
 
// create the file
HANDLE hFile = ::CreateFileW( szDumpPath, GENERIC_WRITE, FILE_SHARE_WRITE, NULL, CREATE_ALWAYS,
FILE_ATTRIBUTE_NORMAL, NULL );
 
if (hFile!= NULL && hFile!=INVALID_HANDLE_VALUE)
{
MINIDUMP_EXCEPTION_INFORMATION mdei;
 
mdei.ThreadId = GetCurrentThreadId();
mdei.ExceptionPointers = pExceptionInfo;
mdei.ClientPointers = 0;
 
MINIDUMP_CALLBACK_INFORMATION mci;
 
mci.CallbackRoutine = (MINIDUMP_CALLBACK_ROUTINE)MyMiniDumpCallback;
mci.CallbackParam = 0;
 
MINIDUMP_TYPE mdt = (MINIDUMP_TYPE)(MiniDumpWithPrivateReadWriteMemory |
MiniDumpWithDataSegs |
MiniDumpWithHandleData |
MiniDumpWithFullMemoryInfo |
MiniDumpWithThreadInfo |
MiniDumpWithUnloadedModules );
 
// write the dump
EFATime startTime = EFATime::now();
BOOL bOK = pDump( GetCurrentProcess(), GetCurrentProcessId(), hFile,
mdt, (pExceptionInfo != 0) ? &mdei : 0, 0, &mci );
EFATime endTime = EFATime::now();
if (bOK)
{
// how much time did it take to dump?
unsigned long diffSecs = endTime.seconds () - startTime.seconds ();
short diffMSecs = endTime.milliseconds () - startTime.milliseconds ();
unsigned long diffHour = 0;
unsigned long diffMin = 0;
unsigned long diffSec = 0;
if (diffMSecs < 0) {
// overflow
diffMSecs += 1000;
diffSecs --;
}
if (diffSecs) {
EFATime diffTime (diffSecs, diffMSecs);
diffHour = diffTime.hourUTC ();
diffMin = diffTime.minuteUTC ();
diffSec = diffTime.second ();
}
 
sprintf( szScratch, "Core file saved (Time taken = %lu:%lu:%lu.%hd)", diffHour, diffMin, diffSec, diffMSecs );
logMsg( szScratch );
retval = EXCEPTION_EXECUTE_HANDLER;
}
else
{
char errorMsg[error_buff_size] = "";
getLastErrorMsg( errorMsg );
sprintf( szScratch, "Failed to save core file - error: %s", errorMsg );
logMsg( szScratch );
}
 
::CloseHandle(hFile);
}
else
{
char errorMsg[error_buff_size] = "";
getLastErrorMsg( errorMsg );
sprintf( szScratch, "Failed to create core file - error: %s", errorMsg );
logMsg( szScratch );
}
}
else
{
logMsg ("Couldn't create core file - DBGHELP.DLL too old");
}
}
else
{
logMsg ("Couldn't create core file - DBGHELP.DLL not found");
}
 
return retval;
}
 
//static
bool MiniDumper::IsDataSectionNeeded( const WCHAR* pModuleName )
{
// Check parameters
 
if( pModuleName == NULL )
{
return false;
}
 
// Extract the module name
 
WCHAR szFileName[_MAX_FNAME] = L"";
 
_wsplitpath( pModuleName, NULL, NULL, szFileName, NULL );
 
// Compare the name with the list of known names and decide
 
if( wcsicmp( szFileName, szImageFileName ) == 0 )
{
return true;
}
//else if( wcsicmp( szFileName, L"ntdll" ) == 0 )
//{
// return true;
//}
 
// Complete
 
return false;
}
 
// static
void MiniDumper::logMsg (char* pMsg)
{
wcscat( szImageFileName, L".exe.log");
// convert image file name to char
size_t origsize = wcslen(szImageFileName) + 1;
const size_t newsize = 100;
size_t convertedChars = 0;
char convertedFileName[newsize];
wcstombs_s(&convertedChars, convertedFileName, origsize, szImageFileName, _TRUNCATE);
 
makeReport (convertedFileName, pMsg);
}
 
void MiniDumper::getLastErrorMsg(LPSTR lpMsgBuf)
{
// Retrieve the system error message for the last-error code
 
DWORD dw = ::GetLastError();
 
FormatMessageA(
FORMAT_MESSAGE_FROM_SYSTEM |
FORMAT_MESSAGE_IGNORE_INSERTS,
NULL,
dw,
MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
lpMsgBuf,
error_buff_size, NULL );
}
 
#endif // _WIN32
 
------------- END ---------------
Sign In·View Thread·Permalink
Question0 kB dump file?memberbearzp5 Apr '08 - 22:45 
Hi Andy,
 
I used your method to post-mortem debug my program. When a program generated and a dump file was created, why the size of it is 0 kB? How come this happened?
 
Thank you.
Sign In·View Thread·Permalink
AnswerRe: 0 kB dump file?memberGreen Fuze27 Nov '08 - 6:43 
Happened to me to... Does anyone know why ???
Sign In·View Thread·Permalink
GeneralPDB ArchivingmemberJeff Schmitz11 Mar '08 - 5:12 
The article states:
 
"After generating a PDB, you also must archive every binary that ships to customers and its matching PDB; you will need the PDB later to debug any minidumps that your customers submit."
 
This point needs some clarification - almost all tools need these, but never explain the what and how of archiving and restoring PDB files.
 
It works great when I develop, build, run, and then pull .dmp file into VS.NET on my PC, but that's not anything like a production environment, where development, build, execution, and debugging are all done in different environments.
 
Does the PDB need to be present in the production runtime environment for the minidump to work?
How does VS.NET or other tools find PDB files? Does it have to have a similar directory structure as the prod environment or build environment?
 
Help would be appreciated.
 
Jeff
Sign In·View Thread·Permalink
GeneralRe: PDB ArchivingmemberChristoph Herzog26 Nov '08 - 4:17 
Hi
 
Even if you already have the answer => here it is for all others Smile | :)
 
You create your own "Symbol-Store" using "symstore.exe" from the DDebugging Tools for Windows..
A symbol store is just a directory, which contains the files in a special structure.... using filename and hashes as directories, e.g. like this:
"C:\Symbols\MyComponent.pdb\45B72787c000\MyComponent.pd_"
 

Example for adding file:
symstore add /r /f "C:\MyBuildDir\" /s C:\Symbols /t "MyProduct" /compress
[MyBuildDir should contain all your binaries and their pdb-files]
 

Of course you should place it somewhere on a server and not only on your local disk.
Then add this to your symbol path in Visual Studio, WinDbg,...
 

cheers!
Sign In·View Thread·Permalink
QuestionCan i have minidump in C#?membersenthil_msk12 Feb '08 - 21:32 
Is there any minidump feature for C#?
 
Senthil
Sign In·View Thread·Permalink
GeneralVETlog.dmpmemberDianeReno26 Jan '08 - 7:50 
Anyone out there know how to solve this. I see this implanted in the diretroy program files. I don't know why or what it is. It keep replicating each day and I have tons of crashes/ disconnects with my aol service provider. I tried to find the source but can't seem to find it. What is this? And is this a spy issue with my computer? Help someone!
 
Dianereno@aol.comConfused | :confused: OMG | :OMG: Unsure | :~
Sign In·View Thread·Permalink
QuestionBlue screen (of death)memberjamesmc26 Dec '07 - 23:33 
I created my first mini dump and things were seemingly going smoothly. However, whenever I tried to debug it in VS (2005), it always causes a blue screen. Any suggestions on how to get around this?
Sign In·View Thread·Permalink
AnswerRe: Blue screen (of death)memberdaher27 Oct '09 - 15:59 
me too, any light on this?
Sign In·View Thread·Permalink
GeneralRe: Blue screen (of death)membermrfreitag17 Mar '10 - 10:41 
Deactivate zonealarm...
Sign In·View Thread·Permalink
QuestionHow we use minidumps [modified]memberPaul Sanders (AlpineSoft)28 Oct '07 - 8:14 
Nice article - too few people know about minidumps and how powerful they can be. We produce just such a dump file in our app in the event of a program crash. Our attitude is that you can't have too much information in such circumstances, so, here's what we do:
 
1. You can produce minidumps of varying sizes containing varying amounts of information. We actually produce three:
- 'small' - MiniDumpNormal - just a stack trace, essentially, about 20k
- 'large' - MiniDumpWithDataSegs - includes all global variables, about 1MB in our case
- 'huge' - MiniDumpWithFullMemory - the works, several 10's of MB
 
The first two of these are small enough to be emailed (which we ask the user to do after he/she reports the problem). The huge dump file is left on the user's disk on the basis that if it's a really gnarly bug we can get him/her to upload it to our webserver overnight.
 
2. We pepper our code with asserts, even in the release version. To produce a dump file in the event of an assert failure, we do this:
// Force a minidump to be generated
void force_minidump (void)
{
    __try
    {
        * (int *) 0 = 0;
    }
    __except (generate_minidump (GetExceptionInformation ()))
    {
    }
}
where generate_minidump is our routine for generating the dumpfiles listed above.
 
3. We have found that Visual Studio 2005 (even with SP1 installed) often blue-screens XP when you try to load a dump file (!) To get around this, we analyse dump files on Vista Sleepy | :zzz: . YMMV.
 

-- modified at 11:33 Tuesday 30th October, 2007
 
Paul Sanders
http://www.alpinesoft.co.uk
Sign In·View Thread·Permalink
QuestionDebugging InformationmemberProgramm3r4 Oct '07 - 3:22 
Hi Andy,
 
Thanks for a great article, I have one question though. I have developed a small application in Borland Developer Studio 2006, will the minidumps still work ??? I have used to following code:
 
//---------------------------------------------------------------------------

#pragma hdrstop
#include <windows.h>
#include <dbghelp.h>
#include <shellapi.h>
#include <shlobj.h>
#include <strsafe.h>
#include <conio.h>
//---------------------------------------------------------------------------

#pragma argsused
 
int GenerateDump(EXCEPTION_POINTERS* pExceptionPointers)
{
    BOOL bMiniDumpSuccessful;
    CHAR szPath[MAX_PATH]; 
	CHAR szFileName[MAX_PATH];
	CHAR* szAppName = "AppName";
    CHAR* szVersion = "v1.0";
    DWORD dwBufferSize = MAX_PATH;
    HANDLE hDumpFile;
    SYSTEMTIME stLocalTime;
    MINIDUMP_EXCEPTION_INFORMATION ExpParam;
 
    GetLocalTime( &stLocalTime );
    GetTempPath( dwBufferSize, szPath );
 
	StringCchPrintf( szFileName, MAX_PATH, "%s%s", szPath, szAppName );
    CreateDirectory( szFileName, NULL );
 
    StringCchPrintf( szFileName, MAX_PATH, "%s%s\\%s-%04d%02d%02d-%02d%02d%02d-%ld-%ld.dmp", 
               szPath, szAppName, szVersion, 
               stLocalTime.wYear, stLocalTime.wMonth, stLocalTime.wDay, 
               stLocalTime.wHour, stLocalTime.wMinute, stLocalTime.wSecond, 
               GetCurrentProcessId(), GetCurrentThreadId());
    hDumpFile = CreateFile(szFileName, GENERIC_READ|GENERIC_WRITE, 
                FILE_SHARE_WRITE|FILE_SHARE_READ, 0, CREATE_ALWAYS, 0, 0);
 
    ExpParam.ThreadId = GetCurrentThreadId();
    ExpParam.ExceptionPointers = pExceptionPointers;
    ExpParam.ClientPointers = TRUE;
 
    bMiniDumpSuccessful = MiniDumpWriteDump(GetCurrentProcess(), GetCurrentProcessId(), 
                    hDumpFile, MiniDumpWithDataSegs, &ExpParam, NULL, NULL);
 
    return EXCEPTION_EXECUTE_HANDLER;
}
 

void SomeFunction()
{
	__try
	{
        int *pBadPtr = NULL;
        *pBadPtr = 0;
	}
	__except(GenerateDump(GetExceptionInformation()))
   {
   }
}
 
int main(int argc, char* argv[])
{
	SomeFunction();
	_getch();
	return 0;
}
 
It generates a dmp file, but when I try and run it in VS it states that debugging information is missing ....
 
Can you please help me ???
 
Many thanks
Regards,
 
The only programmers that are better that C programmers are those who code in 1's and 0's Green Alien | [Alien]

Smile | :) Programm3r
My Blog: ^_^
Sign In·View Thread·Permalink
AnswerRe: Debugging InformationmemberPaul Sanders (AlpineSoft)28 Oct '07 - 8:18 
I don't think so. To the best of my knowledge, Borland don't produce PDB files which is what VS needs to be able to debug your application in anything other than 'raw assembler' mode. Bummer.
 
Paul Sanders
http://www.alpinesoft.co.uk
Sign In·View Thread·Permalink
GeneralSee also BugTrap for a really powerful tool like thismemberMike Diack19 Sep '07 - 1:32 
See:
 
http://www.codeproject.com/tools/BugTrap.asp
 
It's a similar project, but dare I say it, even more powerful and easy to use.
Sourcecode is provided and it supports native and managed code.
 
Mike
Sign In·View Thread·Permalink
GeneralRe: See also BugTrap for a really powerful tool like thismemberPaul Sanders (AlpineSoft)28 Oct '07 - 8:19 
I believe that minidumps, however they are produced, support both native and managed code. But someone tell me I'm wrong...
 
Paul Sanders
http://www.alpinesoft.co.uk
Sign In·View Thread·Permalink
GeneralStrange dumpmemberLazyInNet6 Jun '07 - 16:25 
Hi,
 
Thanks for your great article, it has definitely helped me on resolving mysterious crashes.
 
However, sometimes I get a dump file and when I run it, it only has the following lines in the call stack (I'm sure that I have the correct application version for the dump file):
> ntdll.dll!7c911e58()
ntdll.dll!7c910d5c()

Though I don't believe it's the fault of the ntdll itself, but this dump file is not really useful because I have no idea what in my code causes it.
 
Any hint on how I can obtain more information from it?
 
Cheers,
 
Jackie
Sign In·View Thread·Permalink
AnswerRe: Strange dumpmemberPaul Sanders (AlpineSoft)28 Oct '07 - 8:21 
You may have crashed in a function with no valid stack frame. If you can, compile your app without 'Omit frame pointers' (/Oy).
 

 

 
Paul Sanders
http://www.alpinesoft.co.uk
Sign In·View Thread·Permalink
GeneralRe: Strange dumpmemberLazyInNet1 Nov '07 - 15:54 
Thanks for your reply Paul.
 
I have double checked the project configuration and confirmed that 'Omit frame pointers' is already set to No.
Sign In·View Thread·Permalink
GeneralRe: Strange dumpmemberPaul Sanders (AlpineSoft)2 Nov '07 - 0:33 
Hi,
 
What has probably happened then, is that your exception has occurred inside a function in NTDLL which has no proper stack frame, and it probably crashed because you passed in a bad parameter (e.g. a null pointer).
 
You might be able to find out what that function is by loading symbols for NTDLL into your debugger. To do this, see:
 
http://msdn2.microsoft.com/en-us/library/b8ttk8zy(VS.80).aspx[^]
 
Or, if you are running VS 2003 .NET, the following Google search will turn up a bunch of helpful links: visual studio symbol server
 
Should really have mentioned all this in my first post; sorry about that.
 
Paul Sanders
http://www.alpinesoft.co.uk
Sign In·View Thread·Permalink
News[Message Deleted]memberStefano Castelvetri29 May '07 - 9:06 

Sign In·View Thread·Permalink
Newshttp://cfnm.tangoing.info/susshttp://cfnm.tangoing.info/4 Dec '07 - 23:33 
http://cfnm.tangoing.info/
http://cfnm.tangoing.info/
Sign In·View Thread·Permalink
QuestionWhy using FILE_SHARE_WRITE ?membersivsoft29 Mar '07 - 23:14 
In mdump.cpp source file CreateFile is called with FILE_SHARE_WRITE value for dwShareMode parameter. What for is this needed? Why not use FILE_SHARE_READ ?
Sign In·View Thread·Permalink
QuestionGetting rid of .dmp filesmemberSAAmppa8 Mar '07 - 7:32 
I got two .dmp files on to my computer and I have no idea what to do so if sombody could help me I would be more than happy. Thank you!!!!!!
Sign In·View Thread·Permalink
QuestionDoes this work for Visual Studion 2005memberkepler772 Mar '07 - 11:47 
I have been trying to get this working with Visual Studio 2005 (.NET 2.0). I have no problem getting the symbol server to load all the OS dlls, but when I F5 as directed, all symbols are loaded except my own application's symbols.
 
For example I get
TestMiniDump.exe C:\Src\bin\TestMiniDump.exe N/A N/A No native symbols in symbol file. etc...
 
The PDB is in the same directory as the exe , as well as the .DMP file.
 
All the System32 dll's show as loaded. All I see for debugging is the assembly language code.
 
Any suggestions?
THX!
 


 
kep
Sign In·View Thread·Permalink
GeneralRe: Does this work for Visual Studion 2005memberwolfbert25 Feb '08 - 20:14 
I have the same Problem!
and somehow it don't use the specified directory to store the downloaded dlls
 
regards WOlfbert
Sign In·View Thread·Permalink
GeneralGood job, u got my 5memberx-b31 Jan '07 - 3:39 
Thank you for your atricle, saved me a lot of time. Roll eyes | :rolleyes:
Sign In·View Thread·Permalink
QuestionLine Number InformationmemberSmudo4 Jul '06 - 5:47 
First: I really like this Feature, and it helped often to identify crashes at customer sites.
 
I´ve enabled the creation of a map-file with line number information in my last builds, and got yesterday my first crashdump with this version.
 
I was very pleased, when i could jump to the line in the first function of the call stack, and wanted to get to the next, but it has not worked in my own functions.
 
The function, where i get to the right line in sources was a win32-api function ( MyApp.exe!WinMainCRTStartup() + 0x185 C), and worked as expected. But when i tried to jump in the sources of the function i´ve written on my own, i got the message: "for the actual position there are no sources available" (i´ve translated this message from german, so it may be not 1:1 in english).
 
Does anybode here know, where i have to place my source-code files, so that i also can jump to the right line in my own functions??
 
this would really help me alot!
 
thnx in advance,
Stefan Binder
Sign In·View Thread·Permalink
AnswerRe: Line Number Informationmemberkalleh29 Aug '06 - 3:33 
I have the same problem too.
I can see the source lines of everything but my own code. The PDBs seem to contain all needed information, but the debugger cannot find the source.
The exact message in english is: There is no source code available for the current location.Sigh | :sigh:
 
Kalle Hammarsten
Sign In·View Thread·Permalink
GeneralRe: Line Number Informationmembermr.mvp18 Jun '07 - 6:13 
The same problem for me, it would be great if someone could post a solution for this.
 
Thanks,
markus
Sign In·View Thread·Permalink
AnswerRe: Line Number Informationmembermr.mvp19 Jun '07 - 1:56 
Finally I found out what's the problem. The .pdb files of my release version didn't include all relevant information. I had to switch the project settings of my application under "Configuration Properties/C-C++/General/Debug Information Format from "disabled" to the "Program Database (/Zi)" option. With those generated .pdb files everthing works fine.
 
Thanks for this article.
markus
Sign In·View Thread·Permalink
QuestionMinidumps to catch more detailed info of "Object reference not set to an instance of an object"memberBleuke22 May '06 - 3:20 
Hi,
Currently we're in the user acceptance test pahse of our project. Our users are running from time to time to the error "Object reference not set to an instance of an object". In some cases it's very difficult to reproduce the error.
My question : can minidumps help us in catching more detailed information for this annoying problem?
 
Thanks for your support.
Sign In·View Thread·Permalink
AnswerRe: Minidumps to catch more detailed info of "Object reference not set to an instance of an object"memberMatt Adamson26 Jun '07 - 3:56 
Yes because you probably only have a call stack logged when this exception occurs however if the function is very large it's hard to know exactly which line threw this exception.
 
A dump can help by capturing the state of the application when the exception is raised, and therefore can be read using windbg / VS.NET 2003 to find the actual line of code which threw the exception, rather than just the method name where it was thrown.
 
Matt Adamson
Sign In·View Thread·Permalink
GeneralUsing Minidump to catch the method or function that caused the problemmemberCedar Sith6 Oct '05 - 12:03 
I have installed your program and really enjoy it. Thank you.
 
I have a question, my app is throwing an exception which the minidumper is catching and saving in a file for me.
 
However, the problem, as far as I can tell, resides in the NTDLL.DLL but I can't do anything about that because I can't alter the code.
 
My question is, how can I find the process right before the exception? The process that was called that created the exception? Just for clarification, obviously, something in my code made a call to NTDLL.DLL that caused the exception. If I could know what the call was from my code, I could solve the problems.
 
I hope this question is trivial and that someone who knows can give me an answer. Thank you.
Sign In·View Thread·Permalink
GeneralRe: Using Minidump to catch the method or function that caused the problemmembermykel26 Nov '05 - 6:28 
In short: You need the DLLs of the operating system where the crash appeared.
 
For example: If the program crashed on a Windows XP machine and on your machine is also Windows XP installed, you can analyze the minidump without further effort. You see the complete stack trace in the debugger because you already have the binaries (DLLs) and can get the symbols e.g. from MS Symbol Server (see article). So in this case you have the matching DLLs already on your hard disk because you use the same OS like the machine where the crash appeared.
 
Another example: If the crash appears on a Windows 2000 machine and you want to analyze the minidump on a Windows XP machine you need to get the DLLs of Windows 2000 to see the complete stack trace in the debugger. If you don't have the Windows 2000 DLLs you see for example only a crash in ntdll.dll and no further entries in the stack trace. You don't have the appropriate binaries and the debugger cannot get and load the matching symbols.
 
Check the modules window after starting to debug the minidump. There you can see if the symbols were loaded. The articles explains the modules window very well.
 
I nearly forgot: It's also important to have the DLLs in the same language as the machine where the program crashed. You cannot see the complete stack trace if the program crashed e.g. on a german Windows XP and you are analyzing the minidump on an english Windows XP.

Regards, mykel
 
If they give you lined paper, write the other way!
Sign In·View Thread·Permalink
GeneralRe: Using Minidump to catch the method or function that caused the problemmembertom groezer28 May '07 - 23:58 
I pondered on the idea of copying the dlls from one system to another system. I have couple of queries regarding the same.
 
1) My machine is using windows XP and the .dmp file is created on Windows2000 machine. How can I make sure that while copying the dlls required for debugging and getting a rich stack trace my own version of dlls corresponding to WindowsXP are preserved.
 
2)Secondly what is the best,rapid and easiest way to accomplish the task of copying the dlls and reverting to teh original OS dlls after done with the task.
 
Thanks
Sign In·View Thread·Permalink
GeneralRe: Using Minidump to catch the method or function that caused the problemmembermykel29 May '07 - 7:19 
hi tom,
 
please read chapter "Reading a Minidump with Visual Studio .NET" of the article again. there you will find all information you need.
 
let me try to explain the key points...
 
at first, you certainly don't want to overwrite the system dlls of your running system (e.g. c:\windows\system32\user32.dll) with for example dlls from Windows 2000! not recommended!
 
as you can read in the chapter mentioned above, copy all alien dlls to a local folder of your choice. then set the MODPATH variable in your project settings to this folder. you can also right click on a dll in module window which says "No matching binary found" and select something like "Browse for matching binary" (sorry, i don't know the exact name of this context menu item by heart but you will find it).
 
now set up a link to M$ Symbol Server (check article for details) because "getting matching binaries will not necessarily improve your call stack; you also need debug information that matches them". after this is done start a debug session, get a cup of java because now the debug symbols are downloaded (i hope you have a fast internet connection Poke tongue | ;-P ) and finally you should have the richest stack trace of the crash you can ever get! Wink | ;)
 
so you don't have to revert anything after debugging is done, the alien dlls are not active in your system. just copy them to a local folder and let Visual Studio know where they are... that's all.
 
cheers,
mykel
 
OMM: "Let us be thankful we have commerce. Buy more. Buy more now. Buy. And be happy."
Sign In·View Thread·Permalink
GeneralSaved my bacon.membergerry9917 Aug '05 - 13:23 
Thanks, I could not get my server exes to produce a dump file if they crashed. With this code I can.
 
Whew.
Sign In·View Thread·Permalink
QuestionCan anyone help me get started?membermTIE13 Jun '05 - 12:47 
Can anyone help a newbie get started debugging a minidump.
(I'm not a newbie at debugging in general, but I've never used a minidump before.)
 
* File | Open | Project/Solution ...
* Choose the .dmp file the user sent me and open it.
* F5 to start debugging ...
 
Unable to start program '.dmp'.
The specified file is an unrecognized or unsupported binary format.
 
Huh?
I'm using VS 2005 beta 2.
 
When VS is not in debugging mode, it won't show me anything of interest; I can't open
any of the debug windows: call stack, modules, registers.... Any I can't get into
debug mode because I can't "start debugging".
Sign In·View Thread·Permalink
Generalunable to get minidumpwritedump work properlymembervivek ramaswamy1 Jun '05 - 13:50 
First of i am working on 2003 server.
 
I have registered an unhandled exceptionfilter which prints the stack trace to a file to be mailed later. After printing out the stacktrace i would like to dump the core so that i can do some debugging if needed.
 
I use another thread to dump core. However when i look at the stack trace i do not see a proper one for the exception causing thread although i pass in proper values for the exception pointers.
What i see is the stack with the unhandled exception filter (which is the same as the thread causing the exception).
 
for example i get something like
 
0012f818 77e995f7 0012fab8 c0000005 003b1e90 ghost!util::handle_exception+0x1c5
0012fa70 009cd90a 0012fab8 00000000 00000000 kernel32!UnhandledExceptionFilter+0
xdb
0012fa8c 009c3bbc 00000000 0012fab8 009c943d ghost!_XcptFilter+0x15f
0012fa98 009c943d 0012fac0 00000000 0012fac0 ghost!mainCRTStartup+0x197
0012fac0 7c82eeb2 0012fba4 0012ffb0 0012fbc0 ghost!_except_handler3+0x61
0012fae4 7c82ee84 0012fba4 0012ffb0 0012fbc0 ntdll!RtlRaiseStatus+0xda
0012fb8c 7c82ecc6 00126000 0012fbc0 0012fba4 ntdll!RtlRaiseStatus+0xac
0012fee4 009c3b91 00000001 003b2d68 003b2d88 ntdll!KiUserExceptionDispatcher+0xe
 
0012ffc0 77e523cd 00000000 00000000 7ffda000 ghost!mainCRTStartup+0x16c
0012fff0 00000000 009c3a25 00000000 00000000 kernel32!IsProcessorFeaturePresent+
0x9e
 
is minidumpwritedump capable of retracing to the actual location of the exception instead of just printing the current stack of the thread?
 
I have to mention that i can get good stack traces when i do a stackwalk with the exception information.
 
Thanks for the help in advance.
 

 
Vivek
Sign In·View Thread·Permalink
Last Visit: 31 Dec '99 - 18:00     Last Update: 21 May '13 - 4:29Refresh1234 Next »

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

About Article
This article describes how minidumps work, how to make your application create them when it crashes, and how to read them back with Visual Studio .NET.
Type Article
Licence 
First Posted 6 Mar 2002
Views 828,771
Bookmarked 329 times

, +
Top News

The Next Version of Android - Some of What's Coming

Get the Insider News free each morning.
Related Videos
Visual C# 2012: Debugging With Breakpoints Part 2
Visual C# 2012: Debugging With Breakpoints Part 1
XCrashReport : Exception Handling and Crash Reporting - Part 3
Get Started: Debugging Memory Related Issues in .Net Application Using WinDBG and SOS
Catch All Bugs with BugTrap!
Remote IIS Debugging : Debug your ASP.NET Application which is hosted on "Remote IIS Server"
XML Visualizer v.2
Debug your ASP.NET Application while Hosted on IIS
Source Indexing and Symbol Servers: A Guide to Easier Debugging
Effective Exception Handling in Visual C++
Zeta Color Visualizer
Integrating Crash Reporting into Your Application - A Beginners Tutorial
Windows Debuggers: Part 1: A WinDbg Tutorial
Develop Your Own Operating System in C# or VB.NET
Semicolon - How to get support for Visual C++
Debugging Made Easier with Mole 2010
Debugging Windows Services under Visual Studio .NET
Session Vizualizer for Visual Studio 2005
Processing Global Mouse and Keyboard Hooks in C#
Advanced Debugging in Visual Studio
Automating the Reporting of Critical Errors in Your Program
Visual Studio 2012 New Features of the IDE
Permalink | Advertise | Privacy | Mobile
Web02 | 2.6.130516.1 | Last Updated 7 Mar 2002
Article Copyright 2002 by Andy Pennell
Everything else Copyright © CodeProject, 1999-2013
Terms of Use
Layout: fixed | fluid