WinDBG basic commands, part 1

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
.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 extension

.load [path] command loads WinDBG extension into debugger

WinDDB extension load example
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 !do vs !mdt).

List of loaded extensions into WinDBG

.chain command shows extensions currently loaded into debugger

Display WinDBG loaded extensions
Display WinDBG loaded extensions

Use case: Verify extensions powering commands are loaded (f.e. mex).

Unload extension

.unload [path] command unloads extension from debugger

Unloading extension from WinDBG on demand
Unloading extension from WinDBG on demand

Use case: Commands might overlap (sos and mex define !threadpool).

List threads

!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?

Hint: !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.

Loading memory snapshot into debugger

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.


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

The .cordll -u -l -ve command attempts to automatically load core dll:

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 .load:

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:

Memory dumps intro

What ‘memory dump’ is in human language?

It is a snapshot of an application, similar to real-world picture – just an array of bytes:

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

Application picture

  • 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?

Application picture

  • 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?


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.


Caching layer is typically implemented based on objects, that are captured in single snapshot.

ASP.NET cache summary
ASP.NET cache summary


SQL commands are implemented as objects, hence visible in a single snapshot.

SQL commands captured in the memory snapshot
SQL commands captured in the 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.

About blog

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: [LinkedIn][Twitter]