.NET Debugging Labs - Information and setup instructions
.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.
Installation
- Clone the source code for the labs from the Buggy Bits repository
- 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.
- 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
.reload
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.
Resources
Some familiarity with the sos commands and windbg is useful. The following articles are good starting points for getting used to debugging with WinDbg
- Getting started with WinDbg and sos - Part I
- Getting started - Part II
- Scripting and Advanced commands in WinDbg
Labs
| 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 |
