2

I have a running C# application that got caught into some kind of deadlock and I'd like to obtain stack traces of all running threads to analyze the problem. Unfortunately this application is a Release build and I have lost the pdb files.

When I attach a VS2013 debugger (via remote debugging), I can see the list of threads, but not any stack traces. The stack trace window just contains "External code" for each thread.

It would be of great help to see a basic stack trace - I don't care about details like line numbers.

UPDATE I've actually observed that I have the exact same issue as long I run the Release configuration (with the remote host running the exact same build as in VS, and PDBs being available). I have only ever been able to see a stack trace in Debug builds. Could this be some other issue than a lack of PDB files?

Ambroz Bizjak
  • 7,809
  • 1
  • 38
  • 49
  • You can try to perform native debugging instead of managed debugging. This should show you the stack traces. This is mostly useful if you want to see the system calls that each thread is executing inside. Your own code will probably be hard to track. – Martin Liversage Jul 17 '15 at 17:49

2 Answers2

2

I have found the solution, using WinDbg. In WinDbg, attach to the process, then issue the following commands.

.cordll -ve -u -l
~*e !clrstack

The former will load the extension for managed debugging (see here), and the latter will print all the backtraces (credit to this answer). I believe this just means "for all threads, do !clrstack".

Helpful tip. The installer for Windows Debugging Tools may want to restart the system after having installed the .NET framework. You probably don't want this since it would kill the application you want to debug. Even worst, when it tells you that a restart is required, it will restart no matter if you click "OK" or "Cancel". Fortunately, one can run the installer on another machine, and copy WinDbg to the target machine, where it will work just fine without installation.

Community
  • 1
  • 1
Ambroz Bizjak
  • 7,809
  • 1
  • 38
  • 49
0

You could use .NET Reflector to decompile the DLL's, take the resulting source and recompile it in debug so the .pdb files are included and then do your debugging.

Kristofor
  • 58
  • 10
  • Hm, doubt that would help. Note that I actually have the source code, and I have already tried building the same source code and attaching the debuffer. But for some reason I still get no stack traces. I've even tried copying the binaries of the running application into the VS project and hacking the pdb files to match those binaries (using the ChkMatch tool). – Ambroz Bizjak Jul 17 '15 at 17:38
  • I've actually observed that I have the exact same issue as long I run the Release configuration (with the remote host running the exact same build as in VS, and PDBs being available). I have only ever been able to see a stack trace in Debug builds. Could this be some other issue than a lack of PDB files? – Ambroz Bizjak Jul 17 '15 at 17:40
  • I think the issue is that when building in release mode pdb files are not included. If you need to debug while in release mode I suggest looking into using a remote debugger but I'm not familiar with that. – Kristofor Jul 17 '15 at 17:59