.NET Debugging for the Production Environment

Diagnosing Application Issues - 01

Download this episode

Download Video

Description

Download PPTX slide here: Part 1 

You can't troubleshoot a problem effectively until you first know what the problem is.

When applications encounter stability or performance issues in the production environment, obtaining an accurate problem definition is a key first-step to reducing Time To Resolution.  Learn how Microsoft Support leverages various tools & techniques to help customers define the problems plaguing their production applications.

 

.NET Debugging for the Production Environment, Part 2

Embed

Format

Available formats for this video:

Actual format may change based on video formats available and browser capability.

    The Discussion

    • scott_m

      Great video!  Would also be nice to see some troubleshooting of IIS 7.5 hosted WCF services (long running and/or high memory).

    • BradL

      @scott_m - Thanks for the suggestion.  The next series of recordings will focus on high memory.  The debugging techniques are the same regardless of whether it's for WCF or a Winforms app or ASP.NET, etc.  Stay tuned...

    • Stilgar

      Cool! In our current application I feel like every part of the application is slowin things just a little bit. I wonder how I can figure out what is the most important/impactful thing to optimize.

    • BradL

      @Stilgar - What's worked for me &  my customers in the past is to first concentrate on resolving problems, and _then_ think about optimizations.  If you feel your app is running slowly, get data that will help to show if there is, in fact, a problem.
      If this video didn't help you find your problem, try Part2 in this series, Using Perfmon to Diagnose Application Issues.

    • Nestor Sanchez A

      Cannot wait to see the next episodes of the series.
      Hopefully I would be able to find the code guilty of this unmanaged memory leak I found in some slow netbooks:
      http://stackoverflow.com/questions/10038155/how-to-detect-net-wpf-memory-leak-or-gc-long-run

    • felix9

      Wow ! Very interesting series.

    • Magic​Andre1981

      nice series. But why don't you use procdump from sysinternals?

    • BradL

      @MagicAndre1981:You can use whatever tool you like that does .dump /ma.  Personal preference certainly plays a role.  The reason I focus on DebugDiag is b/c that's what most of our customers use to get dumps in production (and pre-prod).  So what advantages does it have over procdump?  I haven't used procdump in a while, but from what I recall...
      - Let's say you set up a Crash Rule to dump foo.exe when it experiences ExceptionX.  If foo.exe shuts down for whatever reason and ExceptionX never happened, DD's Crash Rule kicks back in after foo.exe restarts.  So DD's Crash Rules sustain process restarts & machine reboots.
      - DD tracks native leaks (very well, I might add), whether it's a leak in the native heaps or from calls to VA or a handle leak.  Yes, this series will focus on .NET debugging, but it's not uncommon that we have to wander into native debugging to find root cause.  So if a customer starts w/ DD, they don't have to switch to a different tool.
      - DD also has an analyzer for hangs, crashes, and native leaks.
      - Customers like the GUI/wizard of DD.  It's very intuitive.

      There may be additional reasons.  These are the ones that come to mind first.

    • wowps

      Thanks, excellent video.

      Could you please share the links you showed in video? It's difficult to type in all those links.

    • Magic​Andre1981

      , BradL wrote

      - Let's say you set up a Crash Rule to dump foo.exe when it experiences ExceptionX.  If foo.exe shuts down for whatever reason and ExceptionX never happened, DD's Crash Rule kicks back in after foo.exe restarts.  So DD's Crash Rules sustain process restarts & machine reboots.
      - DD tracks native leaks (very well, I might add), whether it's a leak in the native heaps or from calls to VA or a handle leak.  Yes, this series will focus on .NET debugging, but it's not uncommon that we have to wander into native debugging to find root cause.  So if a customer starts w/ DD, they don't have to switch to a different tool.
      - DD also has an analyzer for hangs, crashes, and native leaks.
      - Customers like the GUI/wizard of DD.  It's very intuitive.

      ok, thanks.

      1 question. ProcDump has those new MiniPlus dumps, which are smaller than full dumps. Have you tried them? Are they good to debug issues?

    • BradL

      @wowps:DD usage (written before the 1.2 release): http://msdn.microsoft.com/en-us/library/ff420662.aspx#Usage.  Also, see the DD help file.  Download the latest DD from microsoft.com/downloads.
      AD+: read Debugger.chm in the Debugging Tools for Windows package
      ASP.NET Health Monitoring: http://msdn.microsoft.com/en-us/library/bb398933(v=vs.100).aspx">http://msdn.microsoft.com/en-us/library/bb398933(v=vs.100).aspx
      ASP.NET Performance Monitoring: http://msdn.microsoft.com/en-us/library/ms972959.aspx

    • BradL

      @MagicAndre1981:I haven't messed with MiniPlus dumps.  If memory serves correct, they have their root in tshooting Exchange issues and come in handy when dumping large processes (e.g., x64 processes with a lot of committed memory).  I'm not implying they're exclusive for Exchange issues, as I don't think that's the case.  I'm not aware of an equivalent switch for the .dump command that'll create MiniPlus's.
      Without any experience with them, I can't say much about them.

    • dm1608

      Hi ---

       

      Is it possible for us to get the slides for each one of these sessions?

       

    • BradL

      @dm1608:We're working on it.  No ETA yet.

    • deadonthefl​oor

      I concur.  Slides would be great.  My organization is entirely new to .NET and we need all the resources that the great folks at MS provide Big Smile

       

    • RodAtWork

      I just started watching this series.  Great series!  I'm learning a lot, especially about things I didn't even know was there, like Perfmon.  I've got a question about performance monitor.  I have been able to find it on my Windows 7 box, but can't on my old XP box.  Here at work we have a mixture of XP and Win7, so it would be great if I could run that on XP as well.  Is it there?

    • BradL

      @RodAtWork:Yes, it's there.  Start, Run, perfmon.  You should see it in the sys32 directory.

    • Rama Krushnudu

      excellent video series. It would be nice if you share the slides.
      Please provide the PPT to all

    • RodAtWork

      , BradL wrote

      @RodAtWork:Yes, it's there.  Start, Run, perfmon.  You should see it in the sys32 directory.

      Thank you, @BradL, that works perfectly!

    • windev

      @BradL:  The MiniPlus dumps are between Mini and Full. e.g.  procdump -mp notepad.exe

      If it is a managed application, ProcDump forces you to get a Full - as you can't debug a partial managed application dump file.

      If it is a native application, the dumping starts by making a Mini, and then adds the MEM_PRIVATE pages of the process. That is, the IMAGE and MAPPED pages are not included - thus causing a large space saving (these pages are still available as they are mapped in to the dump by the debugger via the original EXE/DLL file on disk or symbol server - .exepath).

      The additional magic kicks in when there is more than 512Mb in the process (e.g. Exchange, AD, SQL Server, etc.). The heuristic removes the cache that these allocate but keep any fragment (4Mb blocks) that is being accessed at the time of the dump.  For a 48Gb process, you usually get a 1-2Gb dump file (that captures in 45-60sec, instead of 30+min).

    Comments closed

    Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.