To create mixed (managed and native) call stacks, you need to use both
ICorDebug* and DIA, then do post processing to interleave the frames
correctly. You can resolve managed call stacks with ICorDebug* from
cordebug.h and IMetaData* from cor.h. EnumerateChains on ICorDebugThread is
a starting point.
HabibH.
[quoted text, click to view] "asanford" <anonymous@discussions.microsoft.com> wrote in message
news:99C19990-9685-4321-BF16-6CC84A2D7EFF@microsoft.com...
> any help from Microsoft on this one?
>
> ----- asanford wrote: -----
>
> We use StackWalk(StackWalk64) from dbghelp.dll to walk our
> callstacksas needed, using the various Sym* methods
> (SymGetSymFromAddr, SymGetLineFromAddr) to resolve source file,
> function name, and source line number for each frame. This works
fine
> for unmanaged code, but when we have a call stack that goes into or
> through some managed code, we cannot resolve any info for the managed
> frames - we can however, get all the information for the unmanaged
> frames in the stack, both before and after the managed frames.
>
> Is there a way to get the dbghelp functions to resolve the managed
> frame info? I tried all the latest dbghelp versions, up thru
6.3.5.1,
> and it still doesn't work. It looks like 6.1 added a new method
> SymFromToken that supports managed code, but what about supporting
> managed code with the other methods? For the exact same callstack
> that dbghelp cannot resolve info for, the debugger in visual
> studio.net CAN resolve info for (if set for Mixed-mode debugging).
Is
> this because VS.net uses DIA instead of, or in addition to, dbghelp?
> Will microsoft ever add full support for managed code in dbghelp? Is
> there some other way to get this info? I know I can get a managed
> call stack from within managed code by using the stacktrace classes,
> but in some cases, this isn't practical - such as in an app that has
> both managed and unmanaged code creating threads - unhandled
> exceptions that occur in the unmanaged threads, perhaps once the
> thread has travelled thru managed code to get to the point causing
the
> exception, are not readily catchable in managed code (we end up
> catching them in the uhe handler specified via Win32). So at this
> point, we have a call stack that has both managed and unmanaged.
> Ideas?
>
> So, will the Sym* (dbghelp) be supported for managed?
> Do I need to use DIA?
> What about IDebug* interfaces (from the "debugger engine" stuff from
> "Debugging tools for windows")?
> What about ICorDebug* (from the CLR)?
>
> we already re-wrote our stackwalker once (to go manual debug info
> walking to using dbghelp); do we now need to re-write again? If so,
> to what? Will it change?
>
> thanks for any help!
>
