Diagnosing Application Issues - 01

Sign in to queue

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

Download

Download this episode

The Discussion

  • User profile image
    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).

  • User profile image
    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...

  • User profile image
    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.

  • User profile image
    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.

  • User profile image
    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

  • User profile image
    felix9

    Wow ! Very interesting series.

  • User profile image
    Magic​Andre1981

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

  • User profile image
    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.

  • User profile image
    wowps

    Thanks, excellent video.

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

  • User profile image
    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?

  • User profile image
    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

  • User profile image
    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.

  • User profile image
    dm1608

    Hi ---

     

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

     

  • User profile image
    BradL

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

  • User profile image
    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

     

  • User profile image
    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?

  • User profile image
    BradL

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

  • User profile image
    Rama Krushnudu

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

  • User profile image
    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!

  • User profile image
    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).

Add Your 2 Cents