WinDBG debugger brings you behind the scenes to witness CLR magic from backstage. You’ll be able to see the hidden gems that turn magic into reality.
This post shows basic WinDBG commands to begin your journey. It is a good one to start exploring the world full of fascinating technical magic.
Snapshot creation time
Similar to picture capturing a single point in time, memory snapshots captures the process state in single moment.
.time command shows when the snapshot was taken or time of the debugging session (in case attaching to process)
.time command example
Use case: Get the time diff between a few sequential memory snapshots.
The distance between
SPECS cameras is known as well as speed limit. Hence the minimal legal journey time is known.Speeding fine shall be issued in case two cameras capture same car in shorter span.
.load [path] command loads WinDBG extension into debugger
WinDDB extension load example
Anybody can create extension to automatize the sequence of re-occurring steps.
Use case: Extensions provide additional commands to execute, or better view for same data (like displaying object content
List of loaded extensions into WinDBG
.chain command shows extensions currently loaded into debugger
Display WinDBG loaded extensions
Use case: Verify extensions powering commands are loaded (f.e. mex).
.unload [path] command unloads extension from debugger
Unloading extension from WinDBG on demand
Use case: Commands might overlap ( and sos define mex
!thread lists threads in the process:
List threads from memory snapshot
Use case: Answer these questions:
Are there any exceptions being handled? Are there any locks owned? How many application domains are there? Is the number of threads seem legit?
!threads -special would show threads with specific roles (GC, Finalizer, IOCompletion)
Switch to the thread
~[thread_number]s switches debugger to the thread:
Switching to GC thread
Use case: Investigate thread-specific data (like call stack or thread stack values).
Get unmanaged call stack
kb [number of frames] gets unmanaged thread call stack
Use case: Check the garbage collection phase.
Memory snapshot captures a picture of the process in time. It is a source of wonderful information about application. You can see on your own what operations are being executed, is there a bottleneck around locking expensive resource and so much more. The most important part to me is to see the application from the angle you’ve never seen it before.
This post shows how to unlock access to the data.
WinDbg is to be installed from Microsoft store:
WinDbg download screen
Alternatively, WinDbg could be installed as a part of
Debugging Tools for Windows SDK. Drag & Drop *.dmp file into WinDBG
Memory snapshot opened in WinDbg Main bits to read snapshot data
The debugger must load
data access component (DAC) (mscordacwks.dll) from the machine snapshot was created on.
Although in 99% of the cases debugger is able to load needed version from the web, you might need to copy it from ‘
%WINDOWS%\Microsoft.NET\Framework64\[framework_version]\mscordacwks.dll‘ location. WHAT IS ‘SOS’ ?
SOS Debugging Extension (SOS.dll) provides information about the internal Common Language Runtime (CLR) environment. In simple words – it translates data to human-understandable format Automatically load needed assemblies
.cordll -u -l -ve command attempts to automatically load
Core DLL for snapshot processing is loaded Manually load needed assemblies
Should command fail to locate matching version, you’ll need to get the assembly from source machine and manually load it with
Manually loaded mscordacwks.dll Open local memory snapshot
Should the memory snapshot be collected from local machine, local
core dll can be loaded via
.loadby sos clr command:
Verify snapshot is loaded correctly
Execute any sos-driven command (f.e.
!eestack -ee ) to verify snapshot loaded correctly:
What ‘memory dump’ is in human language?
It is a snapshot of an application, similar to real-world picture – just an array of bytes:
Application picture Real world picture Application snapshot VS real world picture How to open memory snapshot?
As you need software to open pictures you need
WinDBG to open memory snapshots. What is inside the snapshot?
Typical park picture
Trees, humans, birds The timestamp it was taken Clues about ongoing activities Tree top bend hints wind Sport outfit hints jogging A queue to the coffee shop Some fallen branches
All objects The timestamp it was collected Thread call stacks SQL – hints DB activity IIS7Request – hints ASP.NET How many entries in queue No longer needed data What cannot be answered from one snapshot?
Typical park picture
When the tree was planted? What is the speed of the wind? For how long the guy is running? How fast the shop queue is being processed? When did the branch fall?
When was an object created? How fast operation is executed? For how long the request is processed? Is the processing queue grows or shrinks? When was the object last used? MYTH: WHY SLOW FROM SINGLE SNAPSHOT
At least sequential 2 pictures depicting same activity are needed. The progress (
f.e. number of records processed/(queue length)) is checked in both snapshots and correlated to time stamp difference. CONFIRMED: CACHE STATS
Caching layer is typically implemented based on objects, that are captured in single snapshot.
ASP.NET cache summary CONFIRMED: ONGOING SQL COMMANDS
SQL commands are implemented as objects, hence visible in a single snapshot.
SQL commands captured in the snapshot CONFIRMED: ANYBODY CAN OPEN SNAPSHOT
All you need is proper program to open it. Assistant file (translator) might be needed from exact machine in case not found in web automatically.
Update: I’ve published Loading memory snapshot into debugger post for you.
Have you ever caught yourself thinking how the computer works? I did.
People used to treat it as a black box. That is so true even for software developers!
I’ll guide you to the program backstage to let you witness coding from totally different angle. You’ll be able to see the flow from C# code into 0/1 data stored inside the process.
Threads, heaps, garbage collection, structures, registers would be seen as never before. Knowing how the software runs from inside will help building better software.
From GitHub to first-class blog
Github blog content is being migrated from
KeepSitecoreSimple. Contact me
Here are the channels I’m reachable: [