Is there a way to know the thread id in another process which throws an exception?

Question

I am trying to use MiniDumpWriteDump() API to dump a crashed process B from another process A. I am doing this because MSDN said so:

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

The MiniDumpWriteDump() is defined as this:

BOOL WINAPI MiniDumpWriteDump(
  __in  HANDLE hProcess,
  __in  DWORD ProcessId,
  __in  HANDLE hFile,
  __in  MINIDUMP_TYPE DumpType,
  __in  PMINIDUMP_EXCEPTION_INFORMATION ExceptionParam,
  __in  PMINIDUMP_USER_STREAM_INFORMATION UserStreamParam,
  __in  PMINIDUMP_CALLBACK_INFORMATION CallbackParam
);

Especially, the ExceptionParam is of type PMINIDUMP_EXCEPTION_INFORMATION, which is defined as below:

typedef struct _MINIDUMP_EXCEPTION_INFORMATION {
  DWORD               ThreadId;
  PEXCEPTION_POINTERS ExceptionPointers;
  BOOL                ClientPointers;
} MINIDUMP_EXCEPTION_INFORMATION, *PMINIDUMP_EXCEPTION_INFORMATION;

Now I am wondering how to prepare the following 2 parameters:

ThreadId The identifier of the thread throwing the exception.

ExceptionPointers A pointer to an EXCEPTION_POINTERS structure specifying a computer-independent description of the exception and the processor context at the time of the exception.

How could I get the faulting thread id and exception pointers in process B while running in process A?

Thanks.

Answer 1

A pointer to a MINIDUMP_EXCEPTION_INFORMATION structure describing the client exception that caused the minidump to be generated. If the value of this parameter is NULL, no exception information is included in the minidump file.

Despite the fact that the paramter is marked __in and not __in_opt you can indeed pass NULL here. To get that information in the first place from the target process your process would have to be debugging it anyway.

How and when does process A known to take a minidump of process B? If A is indeed debugging B, when WaitForDebugEvent returns with an EXCEPTION_DEBUG_EVENT, the information is available in the info structure.

If A isn't debugging B, then perhaps B is telling A through some IPC mechanism "Hey I'm crashing, take a minidump". In this case either B could take the dump itself or pass the exception information through the same IPC mechansim to A. Again though, this is problematic for the same reasons calling MiniDumpWriteDump in the crashing process is problematic, if things are blowing up, the thing that might have blown up may be what you need to tell A about it.

The other mechanism that might have A take a dump for B is A is installed as the JIT debugger, in which case, A will be debugging B and you can use the debugging APIs to get the exception information.

If A is just periodically taking minidumps of B, then there won't necessarily be any exceptions, so you can just pass NULL in this case.

Note that if you're intending on doing something like

WaitForSingleObject(handleToProcessB, INFINITE);
MiniDumpWriteDump(handleToProcessB, ...)

that this will not work. The OS keeps around a very few things, mainly the exit code for the process, not the virtual address space and the stacks which you need to take a minidump.