Visual Studio stacks elide some CLR frames in mixed mode

[danmoseley]

In a particular dump I see these frames in windbg:

0:005> ~~[0xb60].  5  Id: a38.b60 Suspend: 0 Teb: 7efa9000 Unfrozen      Start coreclr!ThreadNative::KickOffThread (73344d30)      Priority: 0  Priority class: 128  Affinity: f0
i:005> kp # ChildEBP RetAddr      
00 0829f448 75221629ntdll!ZwWaitForSingleObject(void)+0x15 [d:\win7.obj.x86fre\minkernel\ntdll\wow6432\objfre\i386\usrstubs.asm @
135 01 0829f448 75111194KERNELBASE!WaitForSingleObjectEx(void * hHandle = 0x00000088, unsigned long dwMilliseconds = 1, int bAlertable = 0n0)+0x98 [d:\win7\minkernel\kernelbase\synch.c @
1301 02 0829f460 73346fc4kernel32!WaitForSingleObjectExImplementation(void * hHandle = 0x00000088, unsigned long dwMilliseconds = 1, int bAlertable = 0n0)+0x75 [d:\win7\base\win32\client\synch.c @
**345 03 (Inline) ------- coreclr!CLREventWaitHelper2(void)+0x9 [D:\a\_work\1\s\src\coreclr\vm\synch.cpp @
372 04 0829f4b4 73346f7 coreclr!CLREventWaitHelper(void * handle = <Value unavailable error>, unsigned long dwMilliseconds = <Value unavailable error>, int alertable = 0n0)+0x2d [D:\a\_work\1\s\src\coreclr\vm\synch.cpp @
397 05 0829f4c4 733469c coreclr!CLREventBase::WaitEx(unsigned long dwMilliseconds = 1, WaitMode mode = WaitMode_None (0n0), struct PendingSync * syncState = 0x00000000)+0x32 [D:\a\_work\1\s\src\coreclr\vm\synch.cpp @
469 06 0829f4dc 7333562 coreclr!CLREventBase::Wait(unsigned long dwMilliseconds = 1, int alertable = 0n0, struct PendingSync * syncState = 0x00000000)+0x1a [D:\a\_work\1\s\src\coreclr\vm\synch.cpp @
413 07 0829f560 733705a coreclr!ThreadSuspend::SuspendRuntime(ThreadSuspend::SUSPEND_REASON reason = <Value unavailable error>)+0x54a [D:\a\_work\1\s\src\coreclr\vm\threadsuspend.cpp @
3563 08 0829f60c 7337045 coreclr!ThreadSuspend::SuspendEE(ThreadSuspend::SUSPEND_REASON reason = SUSPEND_FOR_GC (0n1))+0xf9 [D:\a\_work\1\s\src\coreclr\vm\threadsuspend.cpp @
5714 09 0829f634 733708c coreclr!GCToEEInterface::SuspendEE(SUSPEND_REASON reason = SUSPEND_FOR_GC (0n1))+0x26 [D:\a\_work\1\s\src\coreclr\vm\gcenv.ee.cpp @
28 0a 0829f634 7337041 coreclr!WKS::GCHeap::GarbageCollectGeneration(unsigned int gen = 0, gc_reason reason = reason_alloc_soh (0n0))+0xa8 [D:\a\_work\1\s\src\coreclr\gc\gc.cpp @
45101 0b 0829f658 732ef1b coreclr!WKS::gc_heap::trigger_gc_for_alloc(int gen_number = <Value unavailable error>, gc_reason gr = <Value unavailable error>, struct WKS::GCDebugSpinLock * msl = 0x73681a18, bool loh_p = false)+0x19 [D:\a\_work\1\s\src\coreclr\gc\gc.cpp @
17075 0c 0829f68c 733c3bb coreclr!WKS::gc_heap::try_allocate_more_space(struct alloc_context * acontext = 0x0255f270, unsigned int size = 0x10, unsigned int flags = 2, int gen_number = 0n0)+0x1e4 [D:\a\_work\1\s\src\coreclr\gc\gc.cpp @
17221 0d 0829f6a4 732ee47 coreclr!WKS::gc_heap::allocate_more_space(struct alloc_context * acontext = 0x0255f270, unsigned int size = 0x10, unsigned int flags = 2, int alloc_generation_number = 0n0)+0x18 [D:\a\_work\1\s\src\coreclr\gc\gc.cpp @
17685 0e (Inline) ------- coreclr!WKS::gc_heap::allocate(void)+0x40 [D:\a\_work\1\s\src\coreclr\gc\gc.cpp @
17716 0f 0829f6c4 732d989 coreclr!WKS::GCHeap::Alloc(struct gc_alloc_context * context = 0x0255f270, unsigned int size = 0x10, unsigned int flags = 2)+0x53 [D:\a\_work\1\s\src\coreclr\gc\gc.cpp @
44097 10 (Inline) ------- coreclr!Alloc(GC_ALLOC_FLAGS flags = <Value unavailable error>)+0x108 [D:\a\_work\1\s\src\coreclr\vm\gchelpers.cpp @
226 11 0829f724 732ee14 coreclr!AllocateObject(class MethodTable * pMT = 0x0079e774, bool fHandleCom = <Value unavailable error>)+0x175 [D:\a\_work\1\s\src\coreclr\vm\gchelpers.cpp @
979 12 0829f7a8 007abb6 coreclr!JIT_New(struct CORINFO_CLASS_STRUCT_ * typeHnd_ = 0x0079e774)+0xaa [D:\a\_work\1\s\src\coreclr\vm\jithelpers.cpp @ 2312] 13 0829f7c0** 718474f5MicroBenchmarks!System.Collections.Concurrent.AddRemoveFromDifferentThreads`1+<>c__DisplayClass8_0[[System.Int32, System.Private.CoreLib]].<SetupConcurrentStackIteration>b__0(<Win32 error 0n318>)+0x4b14 0829f7d0 7184b61dSystem_Private_CoreLib!System.Threading.Tasks.Task.InnerInvoke(System.Threading.Tasks.Task this = <Value unavailable error>)+0x35 [/_/src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs @
2411 15 0829f7d8 71833751System_Private_CoreLib!System.Threading.Tasks.Task.<>c.<.cctor>b__272_0(<>c this = <Value unavailable error>, object obj = <Value unavailable error>)+0xd [/_/src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs @ 2390]

[danmoseley]

But in VS debugging in mixed mode, several of the frames do not appear -- just "managed to native transition"

Apparently this is a long standing limitation. Certainly only 0.0001% of VS users are likely to care about these frames, and I don't mind dropping to windbg (or native debugging) for this specific situation, but it would be good if it could at least hint they were there for us developer on .NET itself, so I can trust VS when debugging CLR.

[danmoseley]

cc @AaronRobinsonMSFT because this is something he expressed an interest in...

[AaronRobinsonMSFT]

/cc @gregg-miskelly @chuckries @auott

[gregg-miskelly]

Yup, mixed mode debugging in VS doesn't let you do anything with coreclr.dll/clr.dll. This is because:

1. The architecture of mixed mode debugging very deeply doesn't let you debug the runtime itself
   -and-
2. coreclr/clr show up on stacks regularly, mostly for reasons that users don't care about, but we don't know about the cases where this isn't true.

The first issue is an unsolvable issue without a massive effort (OPEC). The second issue might be solvable.

[danmoseley]

Yes, definitely not suggesting we need to debug CLR in mixed mode. Just that some hint when to drop to Windbg would make it easier to start with VS. A marker like [.NET runtime frames] perhaps, in mixed mode only?

[gregg-miskelly]

I think DBI would need to tell us when the CLR frames are "interesting" vs things that are they just because you are debugging (ex: exception hijack). But if that is feasible for the DBI to know, it sounds like it wouldn't be too hard to implement.