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

Summary

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.