!clrstack never reports anything

Question

I know I am dealing with a managed thread but I have never managed to get !clrstack to work. I always get:

0:000> !clrstack
OS Thread Id: 0xaabb (0)
Child SP       IP Call Site
GetFrameContext failed: 1
00000000 00000000

Admittedly I could use !dumpstack but I can't figure out how to make it show the arguments. It only shows ChildEBP, Return Address and the function name. Besides it mixes managed and unmanaged calls and I'd like to focus only on the managed portions.

UPDATE

As requested by Thomas, !clrstack -i returns:

0:000> !clrstack -i
Loaded c:\cache\mscordbi.dll\53489464110000\mscordbi.dll
Loaded c:\cache\mscordacwks_x86_x86_4.0.30319.34209.dll\5348961E69d000\mscordacwks_x86_x86_4.0.30319.34209.dll



Dumping managed stack and managed variables using ICorDebug.
=================================================================
Child SP IP       Call Site
003ad0bc 77d1f8e1 [NativeStackFrame]
Stack walk complete.

Its progress :-)

Related: http://stackoverflow.com/questions/22316393/windbg-clrstack — Thomas Weller, Aug 12 '16 at 19:46
Related: http://stackoverflow.com/questions/7878112/how-to-i-resolve-getframecontext-failed-in-windbg — Thomas Weller, Aug 12 '16 at 19:47
@ThomasWeller The first link leads to the second and I don't see a good solution anywhere. I do have sosex and have loaded it. Should that help me? — ForeverLearning, Aug 12 '16 at 20:15
I also don't see a good explanation what exactly the error means, where it comes from and how to really solve it. That's why I wrote "related" and did not flag as a duplicate. SOSex `!mk` might work, but has the same issue as `!dumpstack`: it prints the native parts as well. But the output of `!mk` is much nicer, if I recall correctly.It might even be possible to write a PyKd script to filter the native parts so that only the managed parts remain. — Thomas Weller, Aug 12 '16 at 20:19
I felt free to add the SOS and SOSex tag. Maybe Steve Johnson (author of SOSex) has a good answer. He's certainly following the SOSex tag — Thomas Weller, Aug 12 '16 at 20:20
In [strike.cpp](https://github.com/dotnet/coreclr/blob/master/src/ToolBox/SOS/Strike/strike.cpp) you can find the string "GetFrameContext failed" and the value is the status (HRESULT) of the call being made. 1 is S_FALSE I think. The method is [ICorDebugStackWalk->GetContext](https://msdn.microsoft.com/en-us/library/dd647533(v=vs.110).aspx) — Thomas Weller, Aug 12 '16 at 20:34
Can you try if your version of SOS supports `!clrstack -i`? It uses ICorDebug instead if ICorDebugStackWalk — Thomas Weller, Aug 12 '16 at 20:38
@ThomasWeller I updated the post with `!clrstack -i`. We are definitely making progress :-) — ForeverLearning, Aug 12 '16 at 21:12
@ThomasWeller Surprisingly enough when I loaded SOSex and ran !mk, I got: `Thread 0: IXCLRDataStackWalk::GetFrame failed. Error = 0x80070057.` — ForeverLearning, Aug 12 '16 at 21:14
The 0x80070057 could be ERROR_INVALID_PARAMETER or E_NOINTERFACE (the source code of SOSex is not available). "I am dealing with a managed thread": how did you determine that? Can you provide evidence? At the moment the thread looks like a native thread or a threads who's call stack is corrupted. — Thomas Weller, Aug 14 '16 at 07:38
@ThomasWeller I determined that by running `!threads`. As I said if I run `!dumpstack` I _can_ see both managed and unmanaged calls. Its just that its in a format that is hard to decipher. — ForeverLearning, Aug 15 '16 at 12:59

score 0 · Answer 1 · answered Aug 15 '16 at 11:02

Please post the output from !dumpstack or k to double check the callstack, you know the !clrstack only display the managed code call stack, however sometimes , if the managed thread finished this work, it would be waited in the CLR code(semaphore) if you use the thread pool, and the remain call stack become totally unmanaged call stack.so !clrstack display nothing for it.

!clrstack never reports anything

1 Answers1