title: Retrieving the stack trace from the stored exception context in a minidump (similar to .ecxr; k)
body: <p>Dumps obtained from Windows Error Reporting typically have a useless current context set on the faulting thread, with a stack deep in <code>WerpReportFault</code>. The actual context at the time of the exception can be retrieved with <code>.ecxr</code> -- which also sets the context in such a way that subsequent commands on the same thread (such as <code>k</code>) return the "correct" information.</p>
  
  <p>I am building a tool for automatic dump analysis, which uses <code>IDebugControl::GetStackTrace</code> to obtain the faulting thread's stack. I can retrieve the stored exception context using <code>IDebugControl4::GetStoredEventInformation</code>. If I use the EBP/RBP, ESP/RSP, EIP/RIP values from the stored context with <code>GetStackTrace</code>, I get the correct stack. However, I would much rather replicate what the <code>.ecxr</code> command does, setting the "correct" state until the thread is switched. I tried using <code>IDebugAdvanced::SetThreadContext</code>, but it seems to be an illegal operation for dump targets and fails with 0x8000FFFF.</p>
  
  <p>I tried to figure out what <code>.ecxr</code> does by debugging a WinDbg instance, and it looks like <code>.ecxr</code> is implemented in <code>dbgeng!DotEcxr</code>. However, from tracing it (with <code>wt</code>) I wasn't able to understand how it resets the current thread's context. It doesn't seem to call any of the COM debug-client interface methods, anyway, and doesn't use <code>IDebugAdvanced::SetThreadContext</code>.</p>
  
  <p>Any suggestions on how to set the thread context in a dump file would be much appreciated. As a last resort, I can always use <code>IDebugControl::Execute</code> and simply invoke the <code>.ecxr</code> command, but I'd prefer a more programmatic approach.</p>