3 minute read

.NET Debugging Labs

This is a series of debugging labs aimed to help you get some hands on experience in debugging the most common types of hang, performance, memory and crash scenarios in .net applications.

Update 2021: The labs have been rewritten to use asp.net core. Some of the tools and functionality has changed since the original edit so wherever possible I have made substitutions. All the labs have been verified to still work Jan 2021 - on Windows 10

Note: The labs used to reference adplus - this has been replaced with ProcDump and Debug Diagnostics for dump capture.

Each lab will have a set of instructions on how to get started but the lab instructions are deliberately kept very brief in order to give you the most chance to explore on your own. Hints will be available for each lab in case you get stuck.

All labs use the same web site so there is only one application to run for all labs.

Note: These labs will cause high CPU usage, high memory consumption and crashes, so make sure that you are only installing these labs on development machines where no one else will be bothered by the system hanging or the web server crashing.


  1. Clone the source code for the labs from the Buggy Bits repository
  2. Run the application on IISExpress or any webserver you like, if you use something else than IISExpress, revise the commands for taking dumps in the labs accordingly.
  3. Verify that you can browse to the various pages, some of them take longer to load, this is expected.

Tools and Terminology

The labs will be using the following tools

Tool Description
WinDbg Native debugger, primarily used for dump (post-mortem) debugging
Debug Diagnostic Tool a.k.a DebugDiag Debugging tool for automatic memory dump analysis, and also memory dump capture
ProcDump Tool for memory dump capture. This tool used to be a part of the sysinternals suite.
Tinyget powershell script Tinyget used to be a part of the IISToolkit, as this is no longer available, I have created a PS script and added it to my DebuggingScripts Repository
sos.dll .net debugging extension for WinDbg. Comes with the framework. Load it in WinDbg with the command .loadby sos coreclr - NOTE: In later versions you need to install it with dotnet-sos install and load it using .load path-to-sos - see the dotnet-sos documentation
dotnet-dump .net core tool for dump capture and dump analysis (as an alternative to ProcDump and WinDbg)
dotnet-counters .net core performance counters

Setting up symbols

Symbols are needed for native/non-dotnet debugging and for viewing the non-dotnet parts of the stack. See “Why do I get weird function names on my stack” for more info.

To set up the symbol path in windbg you run

.symfix c:\mycache

where c:\mycache is where it will store the local copies of the cached symbols. If you choose to save workspace information when asked in windbg, this symbol path will be saved for the next debugging session.


Some familiarity with the sos commands and windbg is useful. The following articles are good starting points for getting used to debugging with WinDbg


Lab Challenge Instructions Walkthrough
Lab 1: Performance Problem - Instructions Walkthrough
Lab 2: Crash - Instructions Walkthrough
Lab 3: High Memory Usage - Instructions Walkthrough
Lab 4: High CPU Performance Problem - Instructions Walkthrough
Lab 5: Crash Challenge Instructions Walkthrough
Lab 6: Memory Leak Challenge Instructions Walkthrough
Lab 7: Memory Leak - Instructions Walkthrough