7

Feels like there's probably a simple answer to this, but I haven't been able to find it.

The scenario in question is a C# .NET Console app.

I commonly use DebugDiag 1.2 to examine .dmp files that come from hangs we experience - usually thread locking issues. They are created using DebugDiag's "Create Full Userdump" option.

I recently began compiling the app targeting .NET 4 in preparation for starting to use some of .NET 4's features. However, I noticed that when analyzing these .dmp files with DebugDiag, all the .NET stack information is missing.

If I change the CLR target back to .NET 3.5, and capture a .dmp from the new executable, the .NET call stack information is there.

When I look at the output of DebugDiag, I see one note that says:

CLR Information

CLR version = 4.0.30319.17929 CLR Debugger Extension = C:\Program Files\DebugDiag\Exts\psscor4.dll

.NET Threads Summary

Failed to request ThreadStore

I presume that 'Failed to Requested ThreadStore' is the key to the issue, since the .NET 3.5 .DMP file (which is using psscor2.dll) reports all the thread information under the 'Threads Summary' header.

Is the issue that the .dmp is missing information, or DebugDiag is unable to retrieve it for some reason?

Erik Schierboom
  • 16,301
  • 10
  • 64
  • 81
JakeL
  • 401
  • 1
  • 4
  • 10
  • possible duplicate of [Using WinDbg/SOS to debug managed->native callstack. I get "Failed to request ThreadStore"](http://stackoverflow.com/questions/1478802/using-windbg-sos-to-debug-managed-native-callstack-i-get-failed-to-request-th) – Hans Passant Jan 29 '13 at 18:19
  • Similar, but different. The resolution of the other issue is "minidump type has to be MiniDumpWithFullMemory". OP says this is a full memory dump, and it works OK in .NET 3.5. – Paul Williams Jan 29 '13 at 19:40
  • JakeL: Did you find a solution for this? I created this thread which may be related: http://stackoverflow.com/questions/17432560/debugdiag-and-mvc4-gives-no-usable-stacktrace – Stephan Møller Jul 02 '13 at 18:00

3 Answers3

3

Ultimately, this one solved itself. I sent a question to Microsoft about it, and they said that DebugDiag 1.1 does not support .NET 4+. They released v1.2 not too long ago, which does - works like a charm again:

http://www.microsoft.com/en-us/download/details.aspx?id=26798

JakeL
  • 401
  • 1
  • 4
  • 10
0

Assuming you're taking a full dump, it may be related to how it co-locates sos. Under 3.5 it would co-locate using mscorlib whereas under CLR 4 it would co-locate using clr. It would be up to whoever wrote debugdiag to be CLR 4 tolerant.

jmcg
  • 357
  • 3
  • 12
0

I faced the same issue and for me it helped to delete psscor4.dll from the sub-directory "exts" of DebugDiag

In the DebugDiag-Report, my CLR-runtime ist now shown as:

CLR Information

CLR version = 4.0.30319.18052

CLR Debugger Extension = C:\Windows\Microsoft.NET\Framework\v4.0.30319\sos.dll

PS: Please take care to use the right version of DebugDiag (32-bit vs. 64-bit).

Baby Groot
  • 4,637
  • 39
  • 52
  • 71
user2588875
  • 1