如何使用 dbghelp!StackWalk64 遍历混合模式（托管+本机）堆栈？
我正在尝试使用 StackWalk64 在 x64 进程上遍历包含托管帧和本机帧的调用堆栈。一切工作正常，直到第一个或第二个托管帧，之后 StackWalk64 无法计算出该帧的返回地址并失败。
我使用 SymFunctionTableAccess64 进行函数表访问回调，并且符号处理程序已使用 SymInitialize() 进行初始化。我需要在 dbghelp 中执行一些魔法才能使其正确遍历托管帧吗？
失败的调用堆栈示例：
UnmanagementFrame1UnmanagedFrame2UnmanagedFrame3ManagedFrame1 <-----（StackWalk64 在此帧后失败）ManagedFrame2UnmanagedFrame4UnmanagedFrame5ntdll!RtlUserThreadStart
注意：这个问题不是关于如何将托管帧解析为符号/方法名称/等，我只是想遍历整个堆栈而不考虑符号解析/等。
此外，IDebugControl4::GetContextStackTrace 工作正常，但 DbgEng 使用自定义函数表回调，而不是简单地委托给 SymFunctionTableAccess64。我怀疑问题在于 CLR 使用 RtlInstallFunctionTableCallback 安装回调函数表（指向 mscordacwks），而 SymFunctionTableAccess64 不够智能，无法遵循这一点。
我花了一些时间尝试编写一个自定义函数表访问回调来遍历函数表链并在 mscordacwks 中调用回调，但它变得非常粗略并且实际上并没有起作用。
I'm trying to walk a callstack that contains both managed and native frames on a x64 process using StackWalk64. Everything works fine until the first or second managed frame, after which StackWalk64 can't figure out the return address of the frame and fails.
I'm using SymFunctionTableAccess64 for the function table access callback and the symbol handler has been initialized with SymInitialize(). Is there some magic I need to do in dbghelp to get it to walk over managed frames correctly?
Example callstack that fails:
UnmanagedFrame1UnmanagedFrame2UnmanagedFrame3ManagedFrame1 <----- (StackWalk64 fails after this frame)ManagedFrame2UnmanagedFrame4UnmanagedFrame5ntdll!RtlUserThreadStart
Note: this question IS NOT about how to resolve the managed frames to symbols/method names/etc, I simply want to walk the full stack with no regard to symbol resolution/etc.
Also, IDebugControl4::GetContextStackTrace works correctly, but DbgEng uses a custom function table callback, and doesn't simply delegate to SymFunctionTableAccess64. I suspect the issue is that the CLR uses RtlInstallFunctionTableCallback to install a callback function table (which points to mscordacwks), and SymFunctionTableAccess64 isn't smart enough to follow that.
I spent some time trying to write a custom function table access callback to traverse the function table chain and call the callback in mscordacwks, but it got pretty sketchy and didn't really work anyways.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
SOS 调试器扩展有帮助吗？它提供了从
windbg和Visual Studio完全按照您希望的方式遍历堆栈的能力。或者.NET Framework 2.0 中的探查器堆栈遍历：基础知识及其他 可能有一定用处。
Does the SOS debugger extension help at all? It provides the ability, from
windbgandVisual Studioto walk the stack exactly the way you wish.Alternatively Profiler Stack Walking in the .NET Framework 2.0: Basics and Beyond might be of some use.