Access violation in MiniDumpWriteDump when invoked out-of-process

Question

The documentation of the MiniDumpWriteDump function states that

MiniDumpWriteDump should be called from a separate process if at all possible, rather than from within the target process being dumped.

So I wrote a small MFC crash handler program that does just that. I followed the advice in this SO answer by Hans Passant, i.e. I am passing the value of the exception pointer from the crashing program to the crash handler program even though the exception pointer is not valid in the context of the crash handler program. This works well when I run tests in a debug build, but when I switch to a release build the crash handler program crashes, with an access violation that occurs inside the MiniDumpWriteDump function.

I am stumped. Why should this work in debug builds, but not in release builds? It's maddening because access violations often are indicators for accessing invalid pointers, and the exception pointer I am receiving in the crash handler program is indeed invalid - but on the other hand I am told that this should not matter, that MiniDumpWriteDump is interpreting the pointer in the context of the crashing process (from where the pointer originated).

Any ideas what I could be doing wrong?

On a sidenote: In his answer, Hans proposes a solution where the watchdog process is pre-launched, then goes to sleep and wakes up when it is triggeredd by the crashing process. My solution is slightly different: I am simply launching the crash handler program at the time when the crash occurs, then I pass the necessary information from the crashing program to the crash handler program via command line arguments. I double-checked that the information being passed is correct, specifically the exception pointer.

@Thomas I would hope so. Both the crashing process and the crash handler process are running with normal (i.e. non-admin) privileges. There is also the thing that debug builds work, but release builds do not work. How can permissions make a difference here? — herzbube, Sep 21 '15 at 13:11
@Thomas Yeah, I know, code is better, but I wouldn't know what to post - the problem area is too wide :-( The program launches the handler via `ShellExecute`, then it goes to sleep forever (i.e. it enters an infinite loop where in each iteration it invokes `Sleep` with a really large number). — herzbube, Sep 21 '15 at 13:26
My crystal ball says that you only pass the exception pointer value through the command line. That cannot work, you need a deep-copy and must copy the *entire* EXCEPTION_POINTERS structure. Very unpractical, that takes dozens of command line arguments. Biggest problem is that your approach just doesn't work, you can no longer reliably start a process. CreateProcess() allocates from the default process heap, the one most likely to be corrupted in a crashed process. — Hans Passant, Sep 21 '15 at 14:02
@HansPassant Your crystal ball is correct. I do it like this because I thought it is the correct thing to do - for instance, in [this answer of yours](http://stackoverflow.com/a/16149572/1054378) you said: "[...] you cannot dereference the pointer in another process, it is only valid in the crashed process. It is only good enough to pass to MiniDumpWriteDump() [...]". So did I completely misunderstand you? — herzbube, Sep 21 '15 at 14:43
@HansPassant After quickly cobbling together a solution that makes a deep copy, it appears you are right (but you knew that already, didn't you ☺) and I misunderstood you. In this case, of course, I agree that command line arguments are impractical (besides any other problems). Even when passing data via `MapViewOfFile`, it is quite annoying to make a deep copy, esp. because `EXCEPTION_RECORD` is a linked-list of potentially unlimited size. I wonder how much space I should pre-allocate in `CreateFileMapping` / `MapViewOfFile` ? — herzbube, Sep 21 '15 at 15:41
@HansPassant If you write your comment as an answer I will accept it. It would also be very interesting if your crystal ball had information about why a debug build works, but a release build does not. — herzbube, Sep 21 '15 at 15:44
Hans Passant does not always write answers. Instead, he lets people learn themselves from the comments he gives. When you understood and implemented the solution, you can write an answer yourself, give credits to Hans Passant and accept that answer after 2 days. If you mark the answer as "Community Wiki", you don't even earn reputation for it. — Thomas Weller, Sep 21 '15 at 17:28

score 0 · Answer 1 · answered Sep 22 '16 at 21:34

I struggled with a similar issue, and have now finally noticed what was wrong.

The MSDN documentation of MINIDUMP_EXCEPTION_INFORMATION states that the ClientPointers field must be TRUE if the ExceptionPointers address is from the target process instead of the local process.

After setting this field correctly, I can simply pass ThreadId and ExceptionPointers from the crashing process, fill them into a MINIDUMP_EXCEPTION_INFORMATION in the dump-writing process, and it works perfectly.

herzbube · Accepted Answer · 2017-04-24T15:25:14.157

I changed my approach so that the final solution looks like the one suggested by Hans Passant: The watchdog process is pre-launched, then goes to sleep and wakes up when it is triggeredd by the crashing process. The crashing process makes a deep-copy of the EXCEPTION_POINTERS structure and passes that information to the watchdog process.

Here's the code that makes the deep-copy. As mentioned in the comments to the question, the main "problem" is EXCEPTION_RECORD which is a linked-list of potentially unlimited size.

// The maximum number of nested exception that we can handle. The value we
// use for this constant is an arbitrarily chosen number that is, hopefully,
// sufficiently high to support all realistic and surrealistic scenarios.
//
// sizeof(CrashInfo) for a maximum of 1000 = ca. 80 KB
const int MaximumNumberOfNestedExceptions = 1000;


// Structure with information about the crash that we can pass to the
// watchdog process
struct CrashInfo
{
    EXCEPTION_POINTERS exceptionPointers;
    int numberOfExceptionRecords;
    // Contiguous area of memory that can easily be processed by memcpy
    EXCEPTION_RECORD exceptionRecords[MaximumNumberOfNestedExceptions];
    CONTEXT contextRecord;
};


// The EXCEPTION_POINTERS parameter is the original exception pointer
// that we are going to deep-copy.
// The CrashInfo parameter receives the copy.
void FillCrashInfoWithExceptionPointers(CrashInfo& crashInfo, EXCEPTION_POINTERS* exceptionPointers)
{
    // De-referencing creates a copy
    crashInfo.exceptionPointers = *exceptionPointers;
    crashInfo.contextRecord = *(exceptionPointers->ContextRecord);

    int indexOfExceptionRecord = 0;
    crashInfo.numberOfExceptionRecords = 0;
    EXCEPTION_RECORD* exceptionRecord = exceptionPointers->ExceptionRecord;

    while (exceptionRecord != 0)
    {
        if (indexOfExceptionRecord >= MaximumNumberOfNestedExceptions)
        {
            // Yikes, maximum number of nested exceptions reached
            break;
        }

        // De-referencing creates a copy
        crashInfo.exceptionRecords[indexOfExceptionRecord] = *exceptionRecord;

        ++indexOfExceptionRecord;
        ++crashInfo.numberOfExceptionRecords;
        exceptionRecord = exceptionRecord->ExceptionRecord;
    }
}

When we receive the CrashInfo structure in the watchdog process we now have a problem: The EXCEPTION_RECORD references are pointing to invalid memory addresses, i.e. to memory addresses that are valid only in the crashing process. The following function (which must be run in the watchdog process) fixes those references.

// The CrashInfo parameter is both in/out
void FixExceptionPointersInCrashInfo(CrashInfo& crashInfo)
{
    crashInfo.exceptionPointers.ContextRecord = &(crashInfo.contextRecord);

    for (int indexOfExceptionRecord = 0; indexOfExceptionRecord < crashInfo.numberOfExceptionRecords; ++indexOfExceptionRecord)
    {
        if (0 == indexOfExceptionRecord)
            crashInfo.exceptionPointers.ExceptionRecord = &(crashInfo.exceptionRecords[indexOfExceptionRecord]);
        else
            crashInfo.exceptionRecords[indexOfExceptionRecord - 1].ExceptionRecord = &(crashInfo.exceptionRecords[indexOfExceptionRecord]);
    }
}

We are now ready to pass &(crashInfo.exceptionPointers) to the MiniDumpWriteDump function.

Note: Obviously this is not a complete solution. You will probably want to pass more info from the crashing process to the watchdog process. The CrashInfo structure is the candidate to hold this information. Also the way how the processes communicate with each other is not shown here. In my case I went with the solution presented by Hans Passant which is linked at the beginning of the question: Use an event for synchronization (CreateEvent + SetEvent) and a memory-mapped file (CreateFileMapping + MapViewOfFile) to shuffle the information from one process to the next. The (unique) names of the event and the memory-mapped file are determined by the main process and passed to the watchdog process via command line arguments.

Access violation in MiniDumpWriteDump when invoked out-of-process

2 Answers2

Linked