问题
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:
UnmanagedFrame1
UnmanagedFrame2
UnmanagedFrame3
ManagedFrame1 <----- (StackWalk64 fails after this frame)
ManagedFrame2
UnmanagedFrame4
UnmanagedFrame5
ntdll!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.
回答1:
Does the SOS debugger extension help at all? It provides the ability, from windbg
and Visual Studio
to 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.
来源:https://stackoverflow.com/questions/5653719/how-do-you-walk-a-mixed-mode-managednative-stack-with-dbghelpstackwalk64