Google-breakpad processor doesn't recognize and use context records generated by ::RtlCaptureContext (e.g. DumpProcessWithoutCrashThread)

[GoogleCodeExporter]

What steps will reproduce the problem?

1.You need to have a forced minidump - this is a minidump produced by 
explicitly calling ExceptionHandler::WriteMinidump().  On Win32 it fabricates 
an artificial exception context record which lacks the ContextFlags to properly 
identify the CPU architecture (e.g. 0x1003f on X86):

bool ExceptionHandler::WriteMinidump() {
  // Make up an exception record for the current thread and CPU context
  // to make it possible for the crash processor to classify these
  // as do regular crashes, and to make it humane for developers to
  // analyze them.
  EXCEPTION_RECORD exception_record = {};
  CONTEXT exception_context = {};
  EXCEPTION_POINTERS exception_ptrs = { &exception_record, &exception_context };

  ::RtlCaptureContext(&exception_context);  <<=================
  exception_record.ExceptionCode = STATUS_NONCONTINUABLE_EXCEPTION;

  return WriteMinidumpForException(&exception_ptrs);
}

2. Use minidump_stackwalk on the dump and look at the crashing thread. You'll 
see that google-breakpad doesn't use the stored exception context record.  Here 
is an example:

Thread 25 *CRASHED* ( EXCEPTION_NONCONTINUABLE_EXCEPTION @ 0x00000000 )

KiFastSystemCallRet
NtWaitForMultipleObjects
CreateFileMappingA
WaitForMultipleObjects
google_breakpad::CrashGenerationClient::SignalCrashEventAndWait()
google_breakpad::CrashGenerationClient::RequestDump(_EXCEPTION_POINTERS 
*,MDRawAssertionInfo *)
google_breakpad::ExceptionHandler::WriteMinidumpWithException(unsigned 
long,_EXCEPTION_POINTERS *,MDRawAssertionInfo *)
google_breakpad::ExceptionHandler::WriteMinidumpForException(_EXCEPTION_POINTERS
 *)
google_breakpad::ExceptionHandler::WriteMinidump()
`anonymous namespace'::DumpProcessWithoutCrashThread(void *)
BaseThreadStart

3. Open the dump in Windbg, switch to the stored exception context and compare 
the callstacks.  Windbg properly uses the stored exception context record: 

0:025> .ecxr
eax=06b7fc90 ebx=00000000 ecx=06b7ff5c edx=00000000 esi=00b15a50 edi=00000009
eip=00421f99 esp=06b7ffb8 ebp=06b7ffec iopl=0         nv up ei pl nz ac pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000216
chrome!`anonymous namespace'::DumpProcessWithoutCrashThread+0x5:
00421f99 33c0            xor     eax,eax
0:025> knL 0n30
 # ChildEBP RetAddr  
00 06b7ffb4 7c80b729 chrome!`anonymous 
namespace'::DumpProcessWithoutCrashThread+0x5
01 06b7ffec 00000000 kernel32!BaseThreadStart+0x37

What is the expected output? What do you see instead?

The expected output from google-breakpad should be the same as the one produced 
by WinDbg.

Original issue reported on code.google.com by ivan.penkov on 7 Sep 2012 at 1:09

[GoogleCodeExporter]

http://code.google.com/p/google-breakpad/source/detail?r=1088

Original comment by ivan.penkov on 8 Dec 2012 at 3:21

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by ivan.penkov on 13 Dec 2012 at 12:57

• Changed state: Verified

[GoogleCodeExporter]

The same issue is now reproduced for Windows 7 x64 running 32-bit application. 
Google Breakpad dump which contains EXCEPTION_NONCONTINUABLE_EXCEPTION doesn't 
contain valid information about call-stack when minidump creation is forced by 
ExceptionHandler::WriteMinidump():

Operating system: Windows NT
                  6.1.7601 Service Pack 1
CPU: x86
     GenuineIntel family 6 model 42 stepping 7
     4 CPUs

Crash reason:  EXCEPTION_NONCONTINUABLE_EXCEPTION
Crash address: 0x0

Thread 0 (crashed)
 0  0x286e020
    eip = 0x0286e020   esp = 0x02829c9c   ebp = 0x1029bdac   ebx = 0x6677d6e0
    esi = 0x0281fb88   edi = 0x0ffe591b   eax = 0x0035f3a0   ecx = 0x0035f3a0
    edx = 0x0035f350   efl = 0x00000216
    Found by: given as instruction pointer in context
...

Original comment by alexande...@gmail.com on 16 Dec 2013 at 4:51

[GoogleCodeExporter]

This issue is fixed. If you're seeing a related problem please file a new issue.

Original comment by ted.mielczarek on 16 Dec 2013 at 11:46