从Windows错误报告中获得的转储通常在故障线程上有一个无用的当前上下文集,在WerpReportFault
深处有一个堆栈。异常发生时的实际上下文可以用.ecxr
检索——它也设置上下文,使同一线程上的后续命令(如k
)返回"正确"的信息。
我正在构建一个自动转储分析工具,它使用IDebugControl::GetStackTrace
来获取故障线程的堆栈。我可以使用IDebugControl4::GetStoredEventInformation
检索存储的异常上下文。如果我使用EBP/RBP, ESP/RSP, EIP/RIP值从GetStackTrace
存储的上下文中,我得到正确的堆栈。但是,我更愿意复制.ecxr
命令所做的事情,设置"正确"的状态,直到切换线程。我尝试使用IDebugAdvanced::SetThreadContext
,但它似乎是转储目标的非法操作,并以0x8000FFFF失败。
我试图找出.ecxr
做什么调试一个WinDbg实例,它看起来像.ecxr
在dbgeng!DotEcxr
实现。然而,从跟踪它(与wt
)我无法理解它是如何重置当前线程的上下文。无论如何,它似乎没有调用任何COM调试客户端接口方法,也没有使用IDebugAdvanced::SetThreadContext
。
IDebugControl::Execute
并简单地调用.ecxr
命令,但我更喜欢一种更程序化的方法。。Ecxr内存复制上下文记录
设置作用域,可以使用
EXT_COMMAND( setscope, "setscope", "{;e,d=@$ip;!setscope;}" )
{
m_Symbols3->SetScopeFromStoredEvent();
}
调用之后如果你执行k etc它将用于最后一个set context
:>cdb -z oktest.dmp
Microsoft (R) Windows Debugger Version 10.0.10586.567 X86
This dump file has a breakpoint exception stored in it.
The stored exception information can be accessed via .ecxr.
0:000> k
ChildEBP RetAddr
0007fb1c 7c940442 ntdll!DbgBreakPoint
0007fc94 7c9210af ntdll!LdrpInitializeProcess+0xffa
0007fd1c 7c90e457 ntdll!_LdrpInitialize+0x183
00000000 00000000 ntdll!KiUserApcDispatcher+0x7
0:000> .load setscope
0:000> !setscope
0:000> k
*** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr
0007fb1c 7c940442 ntdll!DbgBreakPoint
0007fc94 7c9210af ntdll!LdrpInitializeProcess+0xffa
0007fd1c 7c90e457 ntdll!_LdrpInitialize+0x183
00000000 00000000 ntdll!KiUserApcDispatcher+0x7
0:000>
完整扩展代码,包括getstacktrace和outputstacktrace
#include <codeanalysiswarnings.h>
#pragma warning( push )
#pragma warning ( disable : ALL_CODE_ANALYSIS_WARNINGS )
#include <engextcpp.cpp>
#pragma warning( pop )
class EXT_CLASS : public ExtExtension
{
public:
EXT_COMMAND_METHOD(setscope);
};
EXT_DECLARE_GLOBALS();
EXT_COMMAND( setscope, "setscope", "{;e,d=@$ip;!setscope;}" )
{
m_Symbols3->SetScopeFromStoredEvent();
DEBUG_STACK_FRAME Frames[0x20] = {0};
ULONG FramesFilled = NULL;
m_Control->GetStackTrace(0,0,0,Frames,0x20,&FramesFilled);
m_Control->OutputStackTrace(DEBUG_OUTCTL_THIS_CLIENT,Frames,FramesFilled,0x1fff);
}
执行KVF和setscope
0:000> kVf
*** Stack trace for last set context - .thread/.cxr resets it
# Memory ChildEBP RetAddr Args to Child
00 0007fb1c 7c940442 00000000 00000000 00000000 ntdll!DbgBreakPoint (FPO: [0,0,0])
01 178 0007fc94 7c9210af 0007fd30 7c900000 0007fce0 ntdll!LdrpInitializeProcess+0xffa (FPO: [Non-Fpo])
02 88 0007fd1c 7c90e457 0007fd30 7c900000 00000000 ntdll!_LdrpInitialize+0x183 (FPO: [Non-Fpo])
03 00000000 00000000 00000000 00000000 00000000 ntdll!KiUserApcDispatcher+0x7
0:000> !setscope
# Memory ChildEBP RetAddr Args to Child
00 0007fb1c 7c940442 00000000 00000000 00000000 ntdll!DbgBreakPoint (FPO: [0,0,0])
01 178 0007fc94 7c9210af 0007fd30 7c900000 0007fce0 ntdll!LdrpInitializeProcess+0xffa (FPO: [Non-Fpo])
02 88 0007fd1c 7c90e457 0007fd30 7c900000 00000000 ntdll!_LdrpInitialize+0x183 (FPO: [Non-Fpo])
03 00000000 00000000 00000000 00000000 00000000 ntdll!KiUserApcDispatcher+0x7
我认为在dbgeng中没有神奇的方法来保留注册上下文并在每个进一步的API调用中使用它,但是如果您从IDebugControl4::GetStoredEventInformation()中获得异常上下文,我相信您应该更喜欢IDebugControl4::GetContextStackTrace()而不是欺骗GetStackTrace()。