Partilhar via

Opening a Crash Dump File (Automating Crash Dump Analysis Part 1)

  • Artigo

So let's assume for the moment that you have a collection of crash dump files from your team's application. These files may be generated from your stress tests, betas, etc. But where they come from really isn't important, what is important is that we want some way to dig into these files and gather information, evaluate priority, etc., without having to manually open each one in the debugger.

 

Once you install WinDBG, you are given a COM interface allowing you to integrate debugging functionality into your own application. We can then use this to drive the task of opening and querying a crash dump file. When installing, just make sure you select the SDK option, which will give you the header files you will need. To make you life happier, you should also install the symbol packages for all the Operating Systems you support (also available from the above link) - doing so will give you function names from system binaries in the stack traces we will eventually create.

 

To start with we will go over the minimum code to initialize the debugging library and open a crash dump file.

 

#include <windows.h>

#include "dbgeng.h" // windbg header

int __cdecl main(int argc, char* argv[])

    {

    HRESULT hr = E_FAIL;

    IDebugClient *client = NULL;

    IDebugControl *control = NULL;

    IDebugSymbols *symbols = NULL;

 

    // Initialize COM

    hr = CoInitialize(NULL);

    if(FAILED(hr))

        goto cleanup;

 

    // Create the base IDebugClient object

    hr = DebugCreate(__uuidof(IDebugClient), (LPVOID*)&client);

    if(FAILED(hr))

        goto cleanup;

 

    // from the base, create the Control and Symbols objects

    hr = client->QueryInterface(__uuidof(IDebugControl), (LPVOID*)&control);

    if(FAILED(hr))

        goto cleanup;

 

    hr = client->QueryInterface(__uuidof(IDebugSymbols), (LPVOID*)&symbols);

    if(FAILED(hr))

        goto cleanup;

 

    // we can supplement the _NT_SYMBOL_PATH environment variable

    // by adding a path here

    symbols->SetSymbolPath("c:\\myApp\\release");

 

    // the debugger will need to look at the actual binaries

    // so provide the path to the exsecutable files

    symbols->SetImagePath("c:\\myApp\\release");

 

    // open the crash dump

    hr = client->OpenDumpFile("c:\\myApp\\myApp.dmp");

    if(FAILED(hr))

        goto cleanup;

 

    // wait for the engine to finish processing

    control->WaitForEvent(DEBUG_WAIT_DEFAULT, INFINITE);

 

 

    cleanup:

 

    // cleanup and destroy the objects

    if(symbols)

        {

        symbols->Release();

        symbols = NULL;

        }

    if(control)

        {

        control->Release();

        control = NULL;

        }

    if(client)

        {

        client->Release();

        client = NULL;

        }

 

    // cleanup COM

    CoUninitialize();

 

    return 0;

    }

The semicolon separated path you pass into SetSymbolPath() should provide the location of the .pdb symbol files for all binaries consumed by your application. The same goes for the paths to the actual binary files themselves, which is passed in via SetImagePath(). Without the symbols or the actual binaries, your investigations won't be as successful.

MSDN References

· DebugCreate() which is used to instantiate the initial IDebugClient interface.

· IDebugClient

· IDebugControl

· IDebugSymbols

Comments

  • Anonymous
    May 30, 2008
    .NET A Brief History Of C# Style Writing your own rules for Microsoft Source Analysis for C# Checking

  • Anonymous
    June 02, 2008
    So now that we have a memory dump file , and know how to open it , we will want to pull some useful data

  • Anonymous
    June 23, 2008
    For a reference, here are some links to the previous parts in this series: · Prolific Usage of MiniDumpWriteDump

  • Anonymous
    December 21, 2010
    New training program with Dr. Jeff Sutherland, co founder of Scrum, and qaSignature to super-accelerate Scrum Dear Agile Professional, Scrum Inc., and qaSignature are offering Optimized Scrum, a new Scrum training course designed to super-accelerate software development. Optimized Scrum will integrate full daily regression testing cycles into the self-organizing Scrum framework to achieve faster delivery to market. Embedding full regression testing cycles at both the sprint and daily Scrum level will provide almost instant feedback and eliminate lag time. The course is offered as a one day session for CSMs or packaged with CSM training course and it is scheduled for January 19th, 2011. The course is offered either as a one day course for CSMs at: scrumtraininginstitute.com/.../458 Or as an optional course* packaged as a third day with Scrum Inc's CSM training: scrumtraininginstitute.com/.../459 *This optional course is not part of CSM certification program and not required for ScrumMaster certification. I hope to see you there, and let me know if you have any questions.