• Resolved issue with High CPU in dbghost due to exception monitoring when the target throws high rate of exceptions
• Resolved issue with memory leak in dbghost due to bug in sos.dll
• Added Autoupdate security enhancements
• Fixes in leaktrack native memory tracking
• Resolved Breakpoint issue against .net 4.6 targets
• A number of exceptions during analysis are resolved
• New report format with greatly improved organization and filtering
• Introduced latest Microsoft.Diagnostics.Runtime.dll
• Added support for analysis of .net 4.6 targets
• A number of new analysis checks are added
• …etc.

As you know, in DebugDiag 2.0, we introduced a new feature called "Exception Management", this feature basically manages all exceptions that are thrown by the target process since the debugger was attached. We know that the feature's performance is dependent on the number of exceptions/sec thrown by the target process, so we have added a configuration option that turns off the feature when the # of exceptions/sec is above a threshold. This helped a little, but still due to the way the control script manages every exception, we still saw some  performance issues reported.

 With DebugDiag 2.0 Update 2 (To be released July/August 2015) , this issue has been fixed.

Update 9/8/2015:  We have found a showstopper that prevented us from releasing the update on time. We are sorry for the inconvenience and are working on fixing the issue before the release!

• Mourad Lagdas

Lead Developer:

• Wade Mascia  (Thank you DebugDiag 2.0 Team!)

Core Team: 

• Bret Bentzinger
• Brian Roder
• Ivanov Cepeda Pinto
• Tomas Restrepo
• Trevor Fellman
• Richard Marr 

Script Conversion Team:

• Amol Mehrotra
• Devendra Asane
• Nazeef Mallick
• Puneet Gupta (Script Conversion Team Lead)
• Rajkumar Rangaraj
• Rakki Muthukumar
• Santhosh Somayajulu
• Shamik Misra
• Sunil Kumar Chakrapani

Additional Contributors:

• Dario Spilkin
• George Archer
• Jack Davis
• Jeremy Phelps (Nasty Bug Ninja)
• Kelvin Houghton
• Larry Wall
• Prakash Patel
• Rodney Viana
• Todd Foust

External Contributors:

• Practices Checker: Sean Thompson
• DynamicsAX: Tariq Bell, Pere Turegano, Erik Engstrom, Doug Bartley
• CLRMD: Lee Culver

The DebugDiag development team is very excited to announce the general availability of DebugDiag 2.0. The long waited DebugDiag 2.0 comes now with the new analysis engine fully converted to .NET to allow for faster analysis rule development. The tool comes also with a number of new features in the Collection and Analysis modules such as .NET 4.5 support, CLRMD integration, C# and XAML sample rules, Detailed 1^st chance exception logging …etc.

Download the tool from debugdiag.com 
(it should redirect here)

Thank you

Some customers have experienced a memory leak in dbghost.exe when using this feature (on by default).  The issue is not in the tool itself, but is due to a problem in sos.dll.  Until an update is available, users can workaround the problem by turning off the feature off in the DebugDiag options.  Unchecking the box to include the summary table in the log file doesn't completely address the issue.  Instead, set the thresholds to 0 as shown below.

You might not need a dump file anymore

DebugDiag 2.0 introduces a new feature to track exceptions. This feature is very helpful since it provides details on all exceptions thrown during the debugging session. Many times you don’t really need a dump file to
troubleshoot an exception.  Instead you may just need the exception Type, Message, and Call Stack.  In those cases, simply using an “empty” crash rule may be enough to figure out the root cause of the issue being debugged.  An “empty” crash rule is one where you select your target (Executable, IIS Application Pool, Service, etc.), and then just click ‘Next’, ‘Next’, ‘Finish’ without configuring any specific actions such as ‘Create Full UserDump’ or ‘Log Stack Trace’.

This feature is ON by default, and can be turned OFF or configured in the Crash Rule preferences Tab in the Options and Settings Windows under the Tool Menu. 

IMPORTANT:  This information is only written to the log file at the end of the debug session.  Either deactivate the rule or stop the target process to end the debug session.

Performance Details

To avoid affecting performance, only minimal information is logged to disk throughout the life of the process.  If the exception rate rises above the configurable thresholds, then the more expensive information is no longer collected (notice the ‘omitted’ sections below).  If the exception rate drops below the threshold, the full information is collected from that point forward.  The exception details are stored in memory, and the ’Exception Details’ and the ‘Exception Summary’ sections are written to the log file only when the process exits or when a rule is deactivated.  Additional memory is only required when a new entry in these summary sections is added.  If the same exception repeatedly occurs at the same place in the application, a count is incremented and additional memory is not needed.

The various options for this feature are found on the ‘Crash Rule Preferences’ tab of the ‘Tools | Options & Settings’ dialog:

If configured, an exception summary table will be included at the end of the rule's log file located now in the rule's folder (the log files are now located with the dump files - this is another new feature in 2.0).

EG: C:\Program Files\DebugDiag\Logs\Crash rule for all instances of DemoApp.exe\DemoApp__PID__6172__Date__09_10_2013__Time_10_48_10PM__153__Log.txt

In this table, a breakdown per exception type and count is displayed. Something like below:

**********************************

*  EXCEPTION SUMMARY  *

**********************************

          |----------------------------------------|

       | Count | Exception                      |

       |----------------------------------------|

       | 100  | System.IndexOutOfRangeException |

       | 100  | System.ArgumentException        |

       | 100  | System.IO.FileNotFoundException |

       | 100 | System.NullReferenceException    |

       |----------------------------------------|

.

.

.

Only the following information is logged each time an exception is caught:

Date-Time:  Date and Time when the exception was thrown.

Exception kind: First or Second chance exception.

Exception Code: Exception Code

Causing Thread ID: ID of the thread that threw the exception

Exception Type: For .NET exception, this is the type of the exception thrown 

Detail ID: ID used to classify each exception based on Type, Message, and Call Stack.  Use this ID to look up the details in the ‘Exception Details’ section.

An example of this logging follows:

[9/10/2013 10:48:21 PM] Thread exited. Exiting thread system id - System ID: 9872. Exit code - 0x00000000

[9/10/2013 10:48:21 PM] First chance exception - 0XE0434352 caused by thread with System ID: 8832.  Type = System.IndexOutOfRangeException.  DetailID = 2

[9/10/2013 10:48:21 PM] Thread created. New thread system id - System ID: 10000

[9/10/2013 10:48:21 PM] Thread exited. Exiting thread system id - System ID: 8832. Exit code - 0x00000000

[9/10/2013 10:48:21 PM] First chance exception - 0XE0434352 caused by thread with .  Type = System.IndexOutOfRangeException.  DetailID = 2

[9/10/2013 10:48:21 PM] Thread created. New thread system id - System ID: 7712

[9/10/2013 10:48:21 PM] Thread exited. Exiting thread system id - System ID: 10000. Exit code - 0x00000000

[9/10/2013 10:48:21 PM] First chance exception - 0XE0434352 caused by thread with System ID: 7712.  Type = System.IndexOutOfRangeException. DetailID = 2

[9/10/2013 10:48:21 PM] Thread created. New thread system id - System ID: 7720

[9/10/2013 10:48:21 PM] Thread exited. Exiting thread system id - System ID: 7712. Exit code - 0x00000000

[9/10/2013 10:48:21 PM] Thread created. New thread system id - System ID: 4292

[9/10/2013 10:48:21 PM] First chance exception - 0XE0434352 caused by thread with System ID: 7720.  Type = System.ArgumentException.  DetailID = 3

[9/10/2013 10:48:21 PM] First chance exception - 0XE0434352 caused by thread with System ID: 4292.  Type = System.ArgumentException.  DetailID = 3

[9/10/2013 10:48:21 PM] Thread created. New thread system id - System ID: 10976

[9/10/2013 10:48:21 PM] Thread exited. Exiting thread system id - System ID: 7720. Exit code - 0x00000000

[9/10/2013 10:48:21 PM] Thread exited. Exiting thread system id - System ID: 4292. Exit code - 0x00000000

[9/10/2013 10:48:21 PM] First chance exception - 0XE0434352 caused by thread with .  Type = System.ArgumentException.  DetailID = 3

[9/10/2013 10:48:21 PM] Thread created. New thread system id - System ID: 11700

[9/10/2013 10:48:21 PM] Thread exited. Exiting thread system id - System ID: 10976. Exit code - 0x00000000

[9/10/2013 10:48:21 PM] First chance exception - 0XE0434352 caused by thread with System ID: 11700.  Type = System.ArgumentException.  DetailID = 3

[9/10/2013 10:48:21 PM] Thread created. New thread system id - System ID: 5308.

.

.

An example of the ‘Exception Details’ and ‘Exception Summary’ sections follows:

.

.

.

[9/10/2013 10:48:32 PM] Process exited. Exit code - 0x00000000

***********************

*  EXCEPTION DETAILS  *

***********************

DetailID = 1

       Count:   1

       Type:    System.IndexOutOfRangeException

       Message: IndexOutOfRangeException.

       Stack:   

              [HelperMethodFrame]

              System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)

              System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)

              System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)

              System.Threading.ThreadHelper.ThreadStart()

              [GCFrame]

              [DebuggerU2MCatchHandlerFrame]

DetailID= 2

       Count:   99

       Type:    System.IndexOutOfRangeException

       Message: IndexOutOfRangeException.

       Stack:   

              [HelperMethodFrame]

              DemoApp.Program.IOORException() [c:\DemoApp\DemoApp\DemoApp\Program.cs @ 148]

              System.Threading.ThreadHelper.ThreadStart_Context(System.Object)

              System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)

              System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)

              System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)

              System.Threading.ThreadHelper.ThreadStart()

              [GCFrame]

              [DebuggerU2MCatchHandlerFrame]

DetailID= 3

       Count:   100

       Type:    System.ArgumentException

       Message: ArgumentException

       Stack:   

              [HelperMethodFrame]

              DemoApp.Program.AException()[c:\DemoApp\DemoApp\DemoApp\Program.cs @ 161]

              System.Threading.ThreadHelper.ThreadStart_Context(System.Object)

              System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)

              System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)

              System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)

              System.Threading.ThreadHelper.ThreadStart()

              [GCFrame]

              [DebuggerU2MCatchHandlerFrame]

DetailID= 4

       Count:   31

       Type:    System.IO.FileNotFoundException

       Message: Invalid file argument

       Stack:   

              [HelperMethodFrame]

              DemoApp.Program.FNFException()[c:\DemoApp\DemoApp\DemoApp\Program.cs @ 173]

              System.Threading.ThreadHelper.ThreadStart_Context(System.Object)

              System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext,System.Threading.ContextCallback, System.Object, Boolean)

              System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext,System.Threading.ContextCallback, System.Object, Boolean)

              System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext,System.Threading.ContextCallback, System.Object)

              System.Threading.ThreadHelper.ThreadStart()

              [GCFrame]

              [DebuggerU2MCatchHandlerFrame]

DetailID= 5

       Count:   69

       Type:    System.IO.FileNotFoundException

       Message: Invalid file argument

       Stack:   

              (omitted)

DetailID= 6

       Count:   100

       Type:    System.NullReferenceException

       Message: Null String

       Stack:   

              (omitted)

As explained in the beginning of this article, this feature could be disabled if it all affects the performance of the target process.  When the feature is enabled, DebugDiag collects the exception code, type, message and callstack for every exception thrown. This may affect performance.  We have specified some default values for exception rate per sec where it would be unacceptable in term of target process performance to leave the feature ON. However, these numbers are by no mean a norm.

Thanks for reading.

Finbar Ryan (Debug Diag Blog Editor.)

This action plan can be applied when your W3WP.exe process or your application is hanged and that you are quickly aware of the situation to generate a dump yourself before the issue is gone. A hang of a process means the application is no longer responding within a normal execution time or is even not responding at all but the process is not crashing. This means there is no stop or restart of the process and you won't see any change to the Process ID.

Debug Diag can use the answer time of a specific URL to generate a dump file.
The main difficulty in this action plan is to decide what is the correct value to generate dumps. If you set a too high value, you'll never get a dump, however, if you set a too low value, you'll get tons of dumps which are may not be relevant to the issue you are trying to resolve.

Action Plan

• Debug Diagnostic 1.2 can be download at the following URL: https://www.microsoft.com/download/en/details.aspx?id=26798
• Once the tool has been installed and executed on the IIS server, the wizard "Select Rule Type" loads
• Select "Performance", then click on "Next >"

• Select "HTTP Response Times", then click on "Next >"

• Click on "Add URL"
  • Here we'll use the PING monitoring. This allows us to test the accessibility to a page of a web application at regular interval. If the page is not accessible, Debug Diag will generate a series of dumps
  • In the "URL to ping" field, inform the page address facing the hang issue
  • In the "Ping every" field, set 30 seconds
  • In the "Timeout after" field, set 120 seconds
  • Then click on "OK"

Note: Those values are just example values so you may need to change them depending on your scenario.

• Debug Diag offers you to test the specified URL to check it can correctly access to it. You can click on "yes"
  • Once the test has been completed, click on "OK"

• Click on "Next >"

                  

• In the "Select Dump Targets" window
  • Click on "Add Dump Target"
  • In the "Target Type" field, choose "Web application pool" and select the Application Pool which is facing the hang issue
  • Click on "OK", and then on "Next >"

• Set the "Configure UserDump Series" settings as followed:
  • Note 1: You may need to change these values depending on your scenario.
  • Note 2: Here, we'll generate a Full UserDump every 10 seconds. A maximum of 3 dumps will be generated.

• Choose a name and a location for dumps file, then click on "Next >"
  • Setting those dumps on another disk than C:\ is possible
  • Please check you have enough available space disk as the dump size will be equal to the memory consummed by the process you are monitoring

• In the window "Rule Completed", select "Activate the rule now", and then click on "Finish"
  • The rule is now configured and ready to generate dumps

• Check the status is "Active"
  • If it's not, The "DbgSvc" service is surely not started
  • You can go in "Administrative Tools > Services" and start it
• When a dump will be generated, you'll see the column "UserDump Count" being incremented

The dumps are located by default in "C:\Program Files\DebugDiag\Logs\Rule_Name".

We hope this article will help you out.

See you soon.

Sylvain Lecerf and the French IIS Microsoft Support Team

This action plan can be applied when your W3WP.exe process or your application is hanged and that you are quickly aware of the situation to generate a dump yourself before the issue is gone. A hang of a process means the application is no longer responding within a normal execution time or is even not responding at all but the process is not crashing. This means there is no stop or restart of the process and you won't see any change to the Process ID.

Debug Diag can use the execution time of specific requests to generate a dump file.
The main difficulty in this action plan is to decide what is the correct value to generate dumps. If you set a too high value, you'll never get a dump, however, if you set a too low value, you'll get tons of dumps which are may not be relevant to the issue you are trying to resolve.

Action Plan

• Debug Diagnostic 1.2 can be download at the following URL: https://www.microsoft.com/download/en/details.aspx?id=26798
• Once the tool has been installed and executed on the IIS server, the wizard "Select Rule Type" loads
• Select "Performance", then click on "Next >"

• Select "HTTP Response Times", then click on "Next >"

• Click on "Add URL"
  • Here we'll use the ETW monitoring. This allows us to monitor every incoming requests on the IIS server and to generate a dump if a request is taking more time to be executed than the one specified in the "Timeout after" field
  • In the "Partial URL segment to match" field, use the URL or the page which is representative of the performance issue:
    • A general rule of thumb would be that typically it's the page with the biggest time-taken in the IIS logs file
    • In the example below we'll monitor all ASPX pages
  • In the "Timeout after" field, set a value matching the time-taken but it needs to be less than the maximum time the request can take to be executed

• If you have set a Timeout which is less than 30 seconds, you'll get the following message:
  • It can be ignored, just click on "Yes"

• Click on "Next >"

                  

• In the "Select Dump Targets" window
  • Click on "Add Dump Target"
  • In the "Target Type" field, choose "Web application pool" and select the Application Pool which is facing the hang issue
  • Click on "OK", and then on "Next >"

• Set the "Configure UserDump Series" settings as followed and click on "Next >":
  • Note 1: You may need to change these values depending on your scenario.
  • Note 2: Here, we'll generate a Full UserDump every 10 seconds. A maximum of 3 dumps will be generated.

• Choose a name and a location for dumps file, then click on "Next >"
  • Setting those dumps on another disk than C:\ is possible
  • Please check you have enough available space disk as the dump size will be equal to the memory consumed by the process you are monitoring

• In the window "Rule Completed", select "Activate the rule now", and then click on "Finish"
  • The rule is now configured and ready to generate dumps

• Check the status is "Active"
  • If it's not, The "DbgSvc" service is probably not started
  • You can go in "Administrative Tools > Services" and start it
• When a dump will be generated, you'll see the column "UserDump Count" being incremented

The dumps are located by default in "C:\Program Files\DebugDiag\Logs\Rule_Name".

We hope this article will help you out.

See you soon.

Sylvain Lecerf and the French IIS Microsoft Support Team

This action plan can be applied when your W3WP.exe process is crashing which means, in an IIS context, the specified process has been killed or restarted for an obscure reason. This implies a stop of the process and if it has been restarted, a change in the Process ID. You really have to make the difference between a crash and a hang, as configuring a crash rule if you are facing a hang will not generate any dumps.

Action Plan

• Debug Diagnostic 1.2 can be download at the following URL: https://www.microsoft.com/download/en/details.aspx?id=26798
• Once the tool has been installed and executed on the IIS server, the wizard "Select Rule Type" loads
• Select "Crash" and then click on "Next >"

• In the window "Select Target Type"
  • Check "A specific IIS web application pool", then click on "Next >"

    This will have for effect to only generate a dump on the W3WP.exe process corresponding to your Application Pool

    • If you want to monitor every processes owned by IIS, you can select "All IIS/COM+ related processes"
    • You can also select "A specific process" to monitor every instances of a process or just a unique one (a specific process with a specific PID)

      The drawback of "A specific process" for a unique instance is you need to recreate the rule each time the process is restarted as his PID would have changed

       

• Select the Application Pool facing the crash issue, then click on "Next >"

• Add the breakpoint as you can see in the below screenshot
  • This allows you to generate a dump as soon as the command "TerminateProcess" is sent in the process without waiting for a complete stop
  • In addition, if a problem is detected by WAS in the process, it will stop it with this command, so without this breakpoint, no dump will be generated while the process is facing a crash

     

• Then click on "Next >"

   

• Choose a name and a location for dumps file, then click on "Next >"
  • Setting those dumps on another disk than C:\ is possible
  • Please check you have enough available space disk as the dump size will be equal to the memory consumed by the process you are monitoring

     

• In the window "Rule Completed", select "Activate the rule now", and then click on "Finish"
  • The rule is now configured and ready to generate dumps

     

• Check the status is "Active"
  • If it's not, The "DbgSvc" service is surely not started
  • You can go in "Administrative Tools > Services" and start it
• When a dump will be generated, you'll see the column "UserDump Count" being incremented

The dumps are located by default in "C:\Program Files\DebugDiag\Logs\Crash rule for all IIS_COM+ related processes" or in "C:\Program Files\DebugDiag\Logs\Rule_Name".

We hope this article will help you out.

See you soon.

Sylvain Lecerf and the French IIS Microsoft Support Team