New .NET Diagnostic info added to Process Explorer

New .NET Diagnostic info added to Process Explorer

Rate This
  • Comments 28

Productivity is the hallmark of programming with managed code. So often productivity boils down to figuring out why something isn’t working – diagnostics. The CLR provides one of the best foundations for diagnostics. In this post, Richard Lander – a program manager for the Common Language Runtime – shows how more than just developers can now track down root causes for problems. -- Brandon

In this post, we will look at a new feature in Process Explorer, the popular SysInternals tool, which enables developers and IT Pros to collect accurate stack traces for .NET applications.

Adding .NET Stack frames to Process Explorer

A few months ago, a few of us on the .NET Team were looking at how we could improve Process Explorer to provide better diagnostic information for .NET applications. Process Explorer is a very useful tool for investigating why something is going wrong. We know that millions of developers and IT Pros use Process Explorer, so it would seem that even small improvements for .NET would be pretty useful.

After a little conversation, we decided that adding support for .NET frames in Process Explorer’s Stack window would be the most valuable improvement that we could make. We reached out to Mark Russinovich to pitch the idea. For those of you that don’t know, Mark is the creator and maintainer of Process Explorer, and is a Technical Fellow at Microsoft. Mark was immediately supportive of the idea, and gave us the go-ahead to make the changes in the Process Explorer code. That work is now done, and available as part of Process Explorer v15.2 (or later).

What can you do with this new support?

Developers typically reach for Visual Studio when one of their applications starts doing the wrong thing. As the developer of an app, you can reproduce the issue on your own, attach to a badly behaving live repro or look at a dump. You have the source, and can easily go from there. Visual Studio 2012 is great for that scenario.

Sometimes you are a developer working with a customer on their machine and don’t have access to your tools or your application source. You could also be an IT Pro who supports an application that someone else built. In either case, Process Explorer can help you quickly collect diagnostic information, such as call stacks, that can give you an early lead.

The call stack is a hierarchical list of method calls that are active at any one given time on a particular thread within an application. It provides a developer with a really good idea of what the code was doing and why it was doing it. In the case that an app is mis-behaving, the call-stack can be a first-order clue as to why. You will need to use Visual Studio after that, but you’ll be a step closer to a solution with this information.

Process Explorer shows us .NET Stack Frames in Paint.Net

Paint.NET is a really great image and photo editing application written in .NET. For clarity, Paint.NET wasn’t misbehaving, but seemed like a pretty good candidate to first try this new addition to Process Explorer. You can repeat these same steps with any other application.

The following steps assume that the app in question is already running. In this example, it is Paint.NET.

  1. Launch process explorer.
  2. Select the application to inspect. In the screenshot below, Paint.NET is selected.


  1. Right click on the application and choose "Properties".


  1. The “Properties” window will be displayed. Select the “Threads” tab.
  2. Select a thread
    • This part of the exercise can require a little exploration, since there might be quite a few threads running in the app
    • You typically have to check out a few threads before you see method names that match ones that you expect
    • In the Paint.NET example, the first thread is a managed thread that we can inspect


  1. Click the "Stack" button to inspect the callstack for the selected thread
  2. The “Stack” window will be displayed. You can explore the stack and choose to copy frames, one by one, or all at once.

Two examples of the Stack window with managed frames are displayed below. They contain both managed and native frames, and display transitions between managed and native frames with frames labeled “Managed to Unmanaged Transition” and "Unmanaged to Managed Transition".



The following screenshot shows the result of the exact same set of steps using an older version of Process Explorer. Needless to say, the new version improves the process of collecting diagnostic information for .NET applications quite a lot.


Important Considerations

There are a few important operational details that you will need to consider when using this feature.

  • This feature works with applications running on .NET Framework 4.0 or later
  • Update – 9/17/2012: The architecture of Process Explorer must match the architecture of the managed process you are inspecting. Process Explorer always runs at the native bitness of the machine (ex: X64 on X64 Windows). Unfortunately, there is no way to run Process Explorer as a 32-bit app on X64 Windows at this time, which therefore means that you cannot use this feature with 32-bit apps on X64 Windows. We recognize that this is limitation is pretty significant for many of you.
  • The architecture of Process Explorer must match the architecture of the managed process you are inspecting in order to see managed frames–applies to x64 Windows only


As you can see, we have added new support in Process Explorer to capture basic diagnostic information about .NET applications. I expect that developers will find this additional support useful in scenarios where you are troubleshooting application problems on customer machines. On the flipside of the coin, I expect that IT Pros will find that the new Process Explorer provides them with a valuable new ability to communicate accurate information back to developers.

Please tell us if you find this new Process Explorer feature useful. We’d also like to know which other .NET diagnostic features you would find useful in Process Explorer, or some other popular tool.

Leave a Comment
  • Please add 6 and 6 and type the answer here:
  • Post
  • This is excellent work, and really useful. Thanks!

  • Yes, this is extremely useful.  One suggestion, please consider chaning the wording as "Unmanaged" is an awful term. Please use Native instead

    "Managed to Unmanaged Transition” => "Managed to Native Transition"

    "Unmanaged to Managed Transition" => "Native to Managed Transition"


  • How is this done? What is the best way to get a mixed callstack from an external process?


  • This is both chocolatey and awesome.  Nice work!

  • Hi Staffon,

      The managed frame data comes from using the public ICorDebug APIs ( Within ICorDebug there are APIs for enumerating threads, walking callstacks, inspecting particular frames, etc. All the managed debugging information Visual Studio and Process Explorer gets is coming through this public API (and some related APIs such as IMetadataImport and ISymUnmanagedReader).

       While you have always been able to use this API to attach a debugger to a .Net process, before version 4.0 that was a somewhat invasive action. In version 4.0 we added a new non-invasive debugging technique that we use for dump debugging. In order to get these callstacks we momentarily suspend the process threads, and then read memory from the live process the same way as reading memory from a process dump.

    If you want to explore more of what you can do with .Net debugging I would encourage you to look at mdbg, a sample managed debugger that comes with full source written in C#. You can check it out here:

    As for the question of what is the best way to get a mixed callstack from an external process I’d you start by checking if you can adapt or script an existing debugging tool for your purposes. However if you envision building a standalone tool similar to Process Explorer then you probably want to replicate this technique. There are a few other options out there depending on your exact needs as well. If you want to support older CLR versions and are ok being more invasive then you could get stack traces via in-process ICorDebug debugging or in-process profiling (ICorProfiler APIs). If you are thinking of making a lightweight profiler (ie CPU sampling) then ETW might fit into your tool more smoothly and you can take a look at some of CLR’s ETW support.

    There is an msdn forum dedicated to .Net diagnostic tools here: A variety of hobbyist and professional tool developers visit the forum, as well as the CLR developers that build these APIs (such as myself).

    Hope that helps you get started,

    Noah Falk

    (developer on CLR at MSFT)

  • Oops! Should be Staffan not Staffon, my apologies!

  • Cool feature but would it possible to support older (V2.0) .NET Framework versions?

  • Is there any chance you will support .net managed thread names in the thread list view?

    Great job adding this!!!

  • Adam and Dan,

     We don't have any plan right now to add those things, but we do appreciate hearing what you would like to see in the future. Thanks for the feedback!

    -Noah (MSFT)

  • This is a very useful feature, thanks for adding it.

  • "The architecture of Process Explorer must match the architecture of the managed process you are inspecting in order to see managed frames–applies to x64 Windows only" - how do you run the 32 bit Process Explorer on 64 bit windows? Is it possible? I can't find a switch to do that and I want to see the stack of a 32 bit managed process.

  • "The architecture of Process Explorer must match the architecture of the managed process you are inspecting in order to see managed frames" -- is this restriction going to be lifted anytime? It's ugly and makes me feel bad every time I use WinDbg, too.

    Of course I know that this isn't easy to change, but it would be very nich and much easier for us. Thanks!

  • You need to write standalone tools to dump the managed thread stack similar to jstack for jvm which ships with jdk . Also it would be great if running application dumps the current stack trace of all threads to some file. Java has similar tools ( ).

    These tools will be extremely valuable for production debugging.

  • I have found it to work on my Windows 7 x64 machine for x64 Processes. But I have no idea how I should start process explorer in 32 bit mode to look into 32 bit processes.

    On my home machine with a 32 bit Windows 7 it does not work but this may be due to .NET 4.5. This is really a great addition but please make it work for x64 and x86.

    Another nice thing would be a snapshot of all threads in a process so one can look into the call stacks more easily. Something like the VS Parallel Stacks Window would be extremly nice.

  • Will it also be possible to monitor the size and contents of the different .NET heaps ? Useful if wanting to investigate memory leaks.

Page 1 of 2 (28 items) 12