New .NET Diagnostic info added to Process Explorer

New .NET Diagnostic info added to Process Explorer

Rate This
  • Comments 27

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.

clip_image002[4]

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

clip_image004[4]

  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

clip_image005[4]

  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".

clip_image006[4]

clip_image007[4]

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.

clip_image008[4]

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.

Leave a Comment
  • Please add 3 and 6 and type the answer here:
  • Post
  • @Rolf Kristensen

    > Will it also be possible to monitor the size and contents of the different .NET heaps

    That's been in Process Explorer for a while. In the process properties dialogue (NB. double clicking on a process is a quicker way to open it) look at the ".NET Performance" tab, in the lower section select ".Net CLR Memory" to see all the perf counters for the process in that object.

  • @rjcox

    > Select ".Net CLR Memory" to see all the perf counters for the process in that object.

    I want more than performance counters. I want to see the number of each object type the .NET heap. Knowing the heap size will not tell me what type of objects I'm leaking. Thought that when you were able to display .NET callstacks, then you would not be far from doing .NET reflection :)

  • @Rolf Kristensen

    > I want more than performance counters.

    In that case you might want to use a different (and also free, xcopyable) tool: Perf View

    www.microsoft.com/.../details.aspx

  • How about a break on variable modified that allows for the variable to be moved during GC?  This would let us break on object.field.subfield.x being modified.

  • Great work! Some information about JIT would be nice.

  • Very nice feature indeed!

    I bumped into a catch in trying to use it "in the real world" though, and the catch is already described in your "Important Considerations" section, namely the bit where you write "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".

    Most of the .NET process on my 64-bit windows machine run as 32-bit processes, so I cannot use this feature unless I recompile them to 64-bit. As far as I know it is not possible to run 32-bit Process Explorer on a 64-bit OS, isn't it? Trying to do so simply extracts a 64-bit version and runs that.

    Is there any hope that in the future we may be able to inspect 32-bit managed stacks on a 64 bit OS? Or is the reason it is not possible to do so now "too deep" to fix?

  • Multiple releases in few weeks of the tool - The wonderful util is crashing now on my machine - Windows XP SP2 with Office 2010 SP1.

  • @Ashish -- We'll need more information in order to help you.  No other customers are reporting issues, so this is likely something pretty specific.

    Repro steps and a dump file would be super useful for us to move forward on this.

  • Good work, a very useful tool.

  • A bunch of people have posted this but there's been no answer.  You say the architecture of Process Explorer has to match the architecture of the process you're getting the stack from... but Process Explorer always runs as 64 bit on 64 bit OSes.  Is there a way to override that so it runs as 32 bit, in order to get stack traces from 32 bit applications running on a 64 bit OS?  I'm sure this has to be a pretty common occurrence.

  • @Nate Finch -- Thanks for the feedback, Nate. I added an update near the end of the blog post, in "Important Considerations".

    Process Explorer only supports running in X64 on X64 Windows. Our implementation only works when the architecture of Process Explorer and the app process match. We were able to deliver this experience w/o a lot of expense, so opted to do so. We would have liked to deliver the better experience, but could not due to the significantly larger cost impacting other commitments. Apologies that the wording was less than clear. I hope the updated text fixes that.

    It would be good to know how important it would be too you if you could use this feature for 32-bit apps on X64 machines. Would it be a big win for you?

  • i just used this feature to inspect a high cpu thread of aspnet app on a production server 2008, and after few minutes process explorer hang and the inspected process was terminated. (used latest version 15.40 Published: August 1, 2013 )

Page 2 of 2 (27 items) 12