Contents

Debugging Tools for Windows (WinDbg, KD, CDB, NTSD)

Download Debugging Tools for Windows - WinDbg
Download Debugging Tools for Windows - WinDbg
Download Windows Symbol Packages for Debugging
Getting Started with Windows Debugging
Getting Started with Windows Debugging
Getting Started with WinDbg (User-Mode)
Getting Started with WinDbg (Kernel-Mode)
Debugging Environments
Choosing the 32-Bit or 64-Bit Debugging Tools
Setting Up Debugging (Kernel-Mode and User-Mode)
Setting Up Debugging (Kernel-Mode and User-Mode)
Setting Up Kernel-Mode Debugging
Setting Up Kernel-Mode Debugging
Setting Up KDNET Network Kernel Debugging Automatically
Setting Up KDNET Network Kernel Debugging Manually
Setting Up Network Debugging of a Virtual Machine Host - KDNET
Setting Up Kernel-Mode Debugging of a Virtual Machine Manually using a COM
Port
Setting Up Local Kernel Debugging of a Single Computer Manually
Setting Up Kernel-Mode Debugging over a Serial Cable Manually
Setting Up 2PF Kernel-Mode Debugging using KDNET
Setting Up Kernel-Mode Debugging over USB EEM on an ARM device using
KDNET
Setting Up Kernel-Mode Debugging over a USB 3.0 Cable Manually
Setting Up Kernel-Mode Debugging over a USB 2.0 Cable Manually
Setting Up Kernel-Mode Debugging over a 1394 Cable Manually
Supported Ethernet NICs for Network Kernel Debugging in Windows 10
Supported Ethernet NICs for Network Kernel Debugging in Previous Versions of
 Windows
Supported Ethernet NICs for Network Kernel Debugging in Windows 10 - 2004
Supported Ethernet NICs for Network Kernel Debugging in Windows 10 - 1909
Supported Ethernet NICs for Network Kernel Debugging in Windows 10 - 1903
Supported Ethernet NICs for Network Kernel Debugging in Windows 10 - 1809
Supported Ethernet NICs for Network Kernel Debugging in Windows 10 - 1803
Supported Ethernet NICs for Network Kernel Debugging in Windows 10 - 1709
Supported Ethernet NICs for Network Kernel Debugging in Windows 10 - 1703
Supported Ethernet NICs for Network Kernel Debugging in Windows 8.1
Supported Ethernet NICs for Network Kernel Debugging in Windows 8
Configuring tools.ini
Using KDbgCtrl
Debug Windows Drivers - Step by Step Lab (Echo Kernel-Mode)
Debug Drivers - Step by Step Lab (Sysvad Kernel-Mode)
WinDbg Preview
Debugging Using WinDbg Preview
WinDbg Preview - What's New
WinDbg Preview - Installation
WinDbg Preview - Command line startup options
WinDbg Preview – Settings and workspaces
WinDbg Preview – Keyboard shortcuts
WinDbg Preview - Start a user-mode session
WinDbg Preview - Start a kernel mode session
WinDbg Preview - Start a remote, process or dump file session
WinDbg Preview – File menu
WinDbg Preview – Home menu
WinDbg Preview – View menu
WinDbg Preview – Breakpoints menu
WinDbg Preview – Time Travel menu
WinDbg Preview – Data Model menu
WinDbg Preview – Scripting menu
WinDbg Preview – Notes, Command, Memory and Source menus
 WinDbg Preview Basics
WinDbg Preview Basics
Time Travel Debugging
Time Travel Debugging - Overview
Time Travel Debugging - Record a trace
Time Travel Debugging - Replay a trace
WinDbg Preview - Timelines
Time Travel Debugging - Working with trace files
Time Travel Debugging - Troubleshooting
Time Travel Debugging - Navigation commands
Time Travel Debugging - Commands
Time Travel Debugging - Overview of Extension Commands
Time Travel Debugging - !tt (time travel)
Time Travel Debugging - !index (time travel)
Time Travel Debugging - !positions (time travel)
Time Travel Debugging - Walkthrough
Time Travel Debugging - Time Travel Debugging objects
Time Travel Debugging - Introduction to Time Travel Debugging objects
Time Travel Debugging - Calls objects
Time Travel Debugging - Heap objects
Time Travel Debugging - Memory objects
Time Travel Debugging - Event objects
Time Travel Debugging - Exception objects
Time Travel Debugging - Position objects
Time Travel Debugging - Range objects
Time Travel Debugging - Thread objects
Time Travel Debugging - Module objects
Time Travel Debugging - Collection objects
Time Travel Debugging - JavaScript Automation
Debugging Resources
Debugging Resources
Debugging Tools for Windows: New for Windows 10
Tools Included in Debugging Tools for Windows
Tools Included in Debugging Tools for Windows
DumpChk
GFlags
GFlags
GFlags Overview
GFlags Details
GFlags Commands
GFlags Flag Table
GFlags and PageHeap
Monitoring Silent Process Exit
Global Flags Dialog Box
Global Flags Dialog Box
Opening the Dialog Box
Setting and Clearing System-wide Flags
Setting and Clearing Kernel Flags
Setting and Clearing Image File Flags
Configuring Silent Process Exit Monitoring
Launching a Program with Flags
Running a Program in a Debugger
Configuring Special Pool
Configuring Special Pool
Requesting Special Pool by Pool Tag
Requesting Special Pool by Allocation Size
Canceling Requests for Special Pool
Detecting Overruns and Underruns
Configuring Object Reference Tracing
Global Flag Reference
Global Flag Reference
Buffer DbgPrint Output
Create kernel mode stack trace database
Create user mode stack trace database
Debug initial command
Debug WinLogon
Disable heap coalesce on free
Disable paging of kernel stacks
Disable protected DLL verification
Disable stack extension
Early critical section event creation
Enable application verifier
Enable bad handles detection
Enable close exception
Enable debugging of Win32 subsystem
Enable exception logging
Enable heap free checking
Enable heap parameter checking
Enable heap tagging
Enable heap tagging by DLL
Enable heap tail checking
Enable heap validation on call
Enable loading of kernel debugger symbols
Enable object handle type tagging
Enable page heap
Enable pool tagging
Enable silent process exit monitoring
Enable system critical breaks
Load image using large pages if possible
Maintain a list of objects for each type
Object Reference Tracing
Show loader snaps
Special Pool
Stop on exception
Stop on hung GUI
Stop on unhandled user-mode exception
 GFlags Examples
GFlags Examples
Example 1: Displaying Global Flags
Example 2: Setting a Flag by Using a Flag Abbreviation
Example 3: Setting a Flag by Using Its Hexadecimal Value
Example 4: Setting Multiple Flags
Example 5: Clearing a Flag
Example 6: Clearing All Flags
Example 7: Clearing All Flags for an Image File
Example 8: Enlarging the User-Mode Stack Trace Database
Example 9: Detecting a Pool Memory Leak
Example 10: Detecting a Heap Memory Leak in a Process
Example 11: Enabling Page Heap Verification
Example 12: Using Page Heap Verification to Find a Bug
Example 13: Listing Image Files with Global Flags
Example 14: Configuring Special Pool
Example 15: Using Object Reference Tracing
Kill Tool
Logger and LogViewer
Logger and LogViewer
Logger
Logger
Using the Debugger and Logexts.dll
Using Logger.exe
Logger Restrictions and Limitations
LogViewer
LogViewer
Reading the LogViewer Display
Filtering the LogViewer Function List
Exporting LogViewer Files to Text
The Logger Manifest
The Logger Manifest
 Overview of the Logging Manifest
Manifest File Placement
Manifest File Format
PLMDebug
Remote Tool
Remote Tool
Remote Tool Concepts
Remote Tool Commands
Remote Tool Commands
Remote Server Syntax
Remote Client Syntax
Remote Server Query Command
Remote Session Commands
Remote Tool Examples
TList
TList
TList Commands
TList Examples
UMDH
UMDH
Preparing to Use UMDH
UMDH Commands
UMDH Commands
Analyze a Running Process
Analyze UMDH Logs
Interpreting a UMDH Log
Interpreting a Log Comparison
USBView
Tools Related to Debugging Tools for Windows
Tools Related to Debugging Tools for Windows
Windows Error Reporting
Source Code
Source Code
Source Path
Source Code Extended Access
Using a Source Server
SrcSrv
SrcSrv
Using SrcSrv
Source Indexing
Source Indexing
The Srcsrv.ini File
The Ssindex.cmd Script
The SrcTool Utility
The PDBStr Tool
The VSSDump Tool
Source Control Systems
Source Control Systems
Using Visual SourceSafe
Debugging with Visual SourceSafe
Using CVS
Using Other Source Control Systems
Using Other Source Control Systems
Creating Your Own Provider Module
Creating Your Own Source Control System
Language Specification 1
Language Specification 2
HTTP Sites and UNC Shares
HTTP Sites and UNC Shares
Setting Up the Web Site
Extracting Source Files
Modifying the Source Indexing Streams in a .pdb File
Using UNC Shares
Using HTTP Sites and UNC Shares in Conjuction with Regular Version Control
Security Considerations
Security Considerations
Debug Privilege
Security Vulnerabilities
Security Vulnerabilities
Security During Kernel-Mode Debugging
Security During User-Mode Debugging
Security During Postmortem Debugging
Security During Remote Debugging
Secure Mode
Secure Mode
Features of Secure Mode
Activating Secure Mode
Processor Architecture
Processor Architecture
The x86 Processor
The x86 Processor
x86 Architecture
x86 Instructions
Annotated x86 Disassembly
The x64 Processor
The x64 Processor
x64 Architecture
x64 Instructions
Annotated x64 Disassembly
Debugger Engine and Extension APIs
Debugger Engine and Extension APIs
Debugger Engine Introduction
Debugger Engine Overview
Debugger Engine Overview
Debugging Session and Execution Model
Client Objects
 Input and Output
Remote Debugging
Targets
Events
Breakpoints
Symbols
Memory
Threads and Processes
Using the Debugger Engine API
Using the Debugger Engine API
Debugger Engine API Overview
Debugger Engine API Overview
Interacting with the Engine
Interacting with the Engine
Using Client Objects
Using Callback Objects
Using Input and Output
Monitoring Events
Monitoring Events
Event Filters
Event Information
Using Breakpoints
Using Breakpoints
Setting Breakpoints
Controlling Breakpoint Flags and Parameters
Memory Access
Memory Access
Virtual and Physical Memory
Registers
Other Data Spaces
Examining the Stack Trace
Controlling Threads and Processes
 Using Symbols
Using Symbols
Modules
Types
Scopes and Symbol Groups
Using Source Files
Connecting to Targets
Connecting to Targets
Live User-Mode Targets
Live Kernel-Mode Targets
Dump-File Targets
Remote Targets
Target Information
Target State
Calling Extensions and Extension Functions
Assembling and Disassembling Instructions
Writing DbgEng Extensions
Writing DbgEng Extensions
DbgEng Extension Design Guide
DbgEng Extension Design Guide
Anatomy of a DbgEng Extension DLL
Using Clients and the Engine
Writing DbgEng Extension Code
Building DbgEng Extensions
EngExtCpp Extensions
EngExtCpp Extensions
EngExtCpp Extension Design Guide
EngExtCpp Extension Design Guide
EngExtCpp Extension Libraries
Client Objects and the Engine
Writing EngExtCpp Extensions
Building EngExtCpp Extensions
 Parsing Extension Arguments
Typed Data
Writing WdbgExts Extensions
Writing WdbgExts Extensions
WdbgExts Extension Design Guide
WdbgExts Extension Design Guide
WdbgExts Extension API Overview
32-Bit Pointers and 64-Bit Pointers
Using WdbgExts Extension Callbacks
Using the DECLARE_API Macro
Writing WdbgExts Extension Code
Writing WdbgExts Extension Code
WdbgExts Input and Output
WdbgExts Memory Access
WdbgExts Threads and Processes
WdbgExts Symbols
WdbgExts Target Information
Building WdbgExts Extensions
Writing Custom Analysis Debugger Extensions
Writing Custom Analysis Debugger Extensions
Writing an Analysis Extension Plug-in to Extend !analyze
Metadata Files for Analysis Extension Plug-ins
Failure Analysis Entries
Debugger Programming Reference
Debug Engine Interfaces
Debugger Engine Reference
Debugger Engine Reference
DebugBaseEventCallbacks
DebugBaseEventCallbacksWide
Debug API Constants
Debug API Constants
DBG_ASMOPT_XXX
 DBG_ATTACH_XXX
DBG_DUMP_XXX
DBG_DUMP_FIELD_XXX
DBG_ENGOPT_XXX
DBG_EVENT_XXX
DEBUG_FILTER_XXX
DEBUG_FORMAT_XXX
DEBUG_OUTCB_XXX
DEBUG_OUTCTL_XXX
DEBUG_OUTPUT_XXX
DEBUG_PROCESS_XXX
DEBUG_STATUS_XXX
DEBUG_SYMBOL_XXX
DEBUG_TYPEOPTS_XXX
HRESULT Values
Request
Request
DEBUG_REQUEST_SOURCE_PATH_HAS_SOURCE_SERVER
DEBUG_REQUEST_TARGET_EXCEPTION_CONTEXT
DEBUG_REQUEST_TARGET_EXCEPTION_THREAD
DEBUG_REQUEST_TARGET_EXCEPTION_RECORD
DEBUG_REQUEST_GET_ADDITIONAL_CREATE_OPTIONS
DEBUG_REQUEST_SET_ADDITIONAL_CREATE_OPTIONS
DEBUG_REQUEST_GET_WIN32_MAJOR_MINOR_VERSIONS
DEBUG_REQUEST_TARGET_CAN_DETACH
DEBUG_REQUEST_SET_LOCAL_IMPLICIT_COMMAND_LINE
DEBUG_REQUEST_GET_CAPTURED_EVENT_CODE_OFFSET
DEBUG_REQUEST_READ_CAPTURED_EVENT_CODE_STREAM
DEBUG_REQUEST_EXT_TYPED_DATA_ANSI
DEBUG_REQUEST_EXT_TYPED_DATA_ANSI
EXT_TDOP_COPY
EXT_TDOP_RELEASE
 EXT_TDOP_SET_FROM_EXPR
EXT_TDOP_SET_FROM_U64_EXPR
EXT_TDOP_GET_FIELD
EXT_TDOP_EVALUATE
EXT_TDOP_GET_TYPE_NAME
EXT_TDOP_OUTPUT_TYPE_NAME
EXT_TDOP_OUTPUT_SIMPLE_VALUE
EXT_TDOP_OUTPUT_FULL_VALUE
EXT_TDOP_HAS_FIELD
EXT_TDOP_GET_FIELD_OFFSET
EXT_TDOP_GET_ARRAY_ELEMENT
EXT_TDOP_GET_DEREFERENCE
EXT_TDOP_GET_TYPE_SIZE
EXT_TDOP_OUTPUT_TYPE_DEFINITION
EXT_TDOP_GET_POINTER_TO
EXT_TDOP_SET_FROM_TYPE_ID_AND_U64
EXT_TDOP_SET_PTR_FROM_TYPE_ID_AND_U64
ExtExtension
Specific Exceptions
WdbgExts Functions
Customizing Debugger Output Using DML
JavaScript Debugger Scripting
JavaScript Debugger Scripting
JavaScript Debugger Example Scripts
Native Debugger Objects in JavaScript Extensions
Native Debugger Objects in JavaScript Extensions - Debugger Object Details
Native Debugger Objects in JavaScript Extensions - Type Objects
Native Debugger Objects in JavaScript Extensions - Design Considerations
Native Debugger Objects in NatVis
Using LINQ With the debugger objects
Debugger Data Model Function Aliases
Debugger Data Model C++ Overview
 Debugger Data Model C++ Overview
Debugger Data Model C++ Interfaces
Debugger Data Model C++ Objects
Debugger Data Model C++ Additional Interfaces
Debugger Data Model C++ Concepts
Debugger Data Model C++ Scripting
Debugger Data Model - Code Namespace
Debugger Data Model - Code Namespace
Debugger Data Model - Disassembler Objects
Debugger Data Model - Basic Block Objects
Debugger Data Model - Instruction Objects
Debugger Data Model - Instruction Attributes Objects
Debugger Data Model - Operand Objects
Debugger Data Model - Operand Attributes Objects
Debugger Data Model - Register Objects
Debugger Data Model - Live Variable Objects
Debugger Data Model - Source Information Objects
Debugger Data Model - Control Flow Objects
Debugger Data Model - Collections Namespace
Debugger Data Model - File System Namespace
Debugger Data Model - File System Namespace
Debugger Data Model - Directory Objects
Debugger Data Model - File Objects
Debugger Data Model - Text Reader Objects
Debugger Data Model - Text Writer Objects
Glossary
Glossary
A
B
C
D
E
 F
H
I
K
L
M
N
O
P
R
S
T
U
V
W
Debugger Operation
Debugger Operation
Debugging Using WinDbg
Debugging Using WinDbg
Debugging a User-Mode Process Using WinDbg
Debugging a UWP app using WinDbg
Opening a Dump File Using WinDbg
Live Kernel-Mode Debugging Using WinDbg
Ending a Debugging Session in WinDbg
Setting Symbol and Executable Image Paths in WinDbg
Remote Debugging Using WinDbg
Entering Debugger Commands in WinDbg
Using the Command Browser Window in WinDbg
Setting Breakpoints in WinDbg
Viewing the Call Stack in WinDbg
Assembly Code Debugging in WinDbg
Source Code Debugging in WinDbg
 Viewing and Editing Memory in WinDbg
Viewing and Editing Global Variables in WinDbg
Viewing and Editing Local Variables in WinDbg
Viewing and Editing Registers in WinDbg
Controlling Processes and Threads in WinDbg
Configuring Exceptions and Events in WinDbg
Keeping a Log File in WinDbg
Using the Watch Window
Using the Scratch Pad
Debugging Using KD and NTKD
Debugging Using KD and NTKD
Opening a Dump File Using KD
Live Kernel-Mode Debugging Using KD
Ending a Debugging Session in KD
Setting Symbol and Executable Image Paths in KD
Setting Breakpoints in KD
Viewing the Call Stack in KD
Viewing and Editing Memory in KD
Viewing and Editing Registers in KD
Remote Debugging Using KD
Configuring Exceptions and Events in KD
Keeping a Log File in KD
Debugging Using CDB and NTSD
Debugging Using CDB and NTSD
Debugging a User-Mode Process Using CDB
Opening a Dump File Using CDB
Ending a Debugging Session in CDB
Setting Symbol and Executable Image Paths in CDB
Setting Breakpoints in CDB
Viewing the Call Stack in CDB
Viewing and Editing Memory in CDB
Viewing and Editing Registers in CDB
 Configuring Exceptions and Events in CDB
Keeping a Log File in CDB
Local Kernel-Mode Debugging
Controlling the Target
Enabling Postmortem Debugging
Open Enclave debugging
Using the Debugger Command Window
Using the Debugger Command Window
Using Debugger Commands
Evaluating Expressions
Using Shell Commands
Using Aliases
Using Script Files
Using Debugger Command Programs
Using Debugger Command Programs
Elements of a Debugger Command Program
Control Flow Tokens
Executing a Debugger Command Program
Debugger Command Program Examples
Using the WinDbg Graphical Interface
Using the WinDbg Graphical Interface
Using Debugging Information Windows
Using Debugging Information Windows
Opening a Window
Closing a Window
Configuring a Window
Moving Through a Window
Cutting and Pasting Text
Changing Text Properties
Positioning the Windows
Positioning the Windows
Debugging with Floating and Docked Windows
 Docking a Window
Tabbing a Window
Undocking a Window
Creating a New Dock
Resizing and Moving a Window
Arranging Windows
Using Workspaces
Using Workspaces
Creating and Opening a Workspace
Workspace Contents
Using and Customizing WinDbg Themes
Using and Customizing WinDbg Themes
Loading a Theme
Customizing a Theme
Using Themes Provided in Debugging Tools for Windows
Using the Toolbar and Status Bar
Using the Help Documentation
Using Debugger Extensions
Using Debugger Extensions
Loading Debugger Extension DLLs
Using Debugger Extension Commands
Writing New Debugger Extensions
Remote Debugging
Remote Debugging
Choosing the Best Remote Debugging Method
Remote Debugging Through the Debugger
Remote Debugging Through the Debugger
Activating a Debugging Server
Searching for Debugging Servers
Activating a Debugging Client
Client and Server Examples
Controlling a Remote Debugging Session
Controlling the User-Mode Debugger from the Kernel Debugger
Controlling the User-Mode Debugger from the Kernel Debugger
Starting the Debugging Session
Switching Modes
When to Use This Technique
Combining This Method with Remote Debugging
Remote Debugging Through Remote.exe
Remote Debugging Through Remote.exe
The Remote.exe Utility
Starting a Remote.exe Session
Remote.exe Batch Files
Process Servers (User Mode)
Process Servers (User Mode)
Activating a Process Server
Searching for Process Servers
Activating a Smart Client
Process Server Examples
Controlling a Process Server Session
KD Connection Servers (Kernel Mode)
KD Connection Servers (Kernel Mode)
Activating a KD Connection Server
Searching for KD Connection Servers
Activating a Smart Client (Kernel Mode)
KD Connection Server Examples
Controlling a KD Connection Server Session
Repeaters
Repeaters
Activating a Repeater
Using a Repeater
Repeater Examples
Advanced Remote Debugging Scenarios
Advanced Remote Debugging Scenarios
 Debugging Targets on Multiple Computers
Symbols in the Middle
Two Firewalls
Remote Debugging on Workgroup Computers
Debugging Previous Versions of Windows
Debugging Previous Versions of Windows
Debugging Tools For Windows: What's New
Debugging Tools For Windows: What's New
Debugging Tools for Windows: New for Windows 8.1
Debugging Tools for Windows: New for Windows 8
Debugging Tools For Windows8 Release Notes
Debugging Windows Vista
Debugging Using Visual Studio
Setting Up User-Mode Debugging in Visual Studio
Setting Up User-Mode Debugging in Visual Studio
Debugging a User-Mode Process Using Visual Studio
Opening a Dump File Using Visual Studio
Kernel-Mode Debugging in Visual Studio
Ending a Debugging Session in Visual Studio
Setting Symbol and Executable Image Paths in Visual Studio
Remote Debugging Using Visual Studio
Entering Debugger Commands in Visual Studio
Setting Breakpoints in Visual Studio
Viewing the Call Stack in Visual Studio
Source Code Debugging in Visual Studio
Viewing and Editing Memory and Registers in Visual Studio
Controlling Threads and Processes in Visual Studio
Configuring Exceptions and Events in Visual Studio
Keeping a Log File in Visual Studio
Setting Up Kernel-Mode Debugging in Visual Studio
Setting Up Kernel-Mode Debugging in Visual Studio
Setting Up Kernel-Mode Debugging over a Network Cable in Visual Studio
 Setting Up Kernel-Mode Debugging over a 1394 Cable in Visual Studio
Setting Up Kernel-Mode Debugging over a USB 3.0 Cable in Visual Studio
Setting Up Kernel-Mode Debugging over a USB 2.0 Cable in Visual Studio
Setting Up Kernel-Mode Debugging over a Serial Cable in Visual Studio
Setting Up Kernel-Mode Debugging using Serial over USB in Visual Studio
Setting Up Kernel-Mode Debugging of a Virtual Machine in Visual Studio
Debugging Techniques
Debugging Techniques
Standard Debugging Techniques
Standard Debugging Techniques
Using Breakpoints
Using Breakpoints
Methods of Controlling Breakpoints
Breakpoint Syntax
Unresolved Breakpoints (bu Breakpoints)
Processor Breakpoints (ba Breakpoints)
Initial Breakpoint
User Space and System Space
Risks Entailed When Setting Breakpoints
Conditional breakpoints in WinDbg and other Windows debuggers
Executing Until a Specified State is Reached
Reading and Writing Memory
Reading and Writing Memory
Accessing Memory by Virtual Address
Accessing Memory by Physical Address
Accessing Global Variables
Accessing Local Variables
Controlling Variables Through the Watch Window
Converting Virtual Addresses to Physical Addresses
Using the !analyze Extension
Handling a Bug Check When Driver Verifier is Enabled
Noninvasive Debugging (User Mode)
Debugging in Assembly Mode
Debugging in Source Mode
Debugging Optimized Code and Inline Functions
Debugging Managed Code Using the Windows Debugger
Debugging UWP Apps Using the Windows Debugger
Changing Contexts
Controlling Processes and Threads
Using Debugger Markup Language
Controlling Exceptions and Events
Finding the Process ID
Debugging a Stack Overflow
Manually Walking a Stack
Debugging a Stack Trace that has JScript Frames
Debugging an Application Failure
Reattaching to the Target Application
Crashing and Rebooting the Target Computer
Synchronizing with the Target Computer
Finding a Memory Leak
Finding a Memory Leak
Determining Whether a Leak Exists
Finding a Kernel-Mode Memory Leak
Finding a Kernel-Mode Memory Leak
Using PoolMon to Find a Kernel-Mode Memory Leak
Using the Kernel Debugger to Find a Kernel-Mode Memory Leak
Using Driver Verifier to Find a Kernel-Mode Memory Leak
Finding a User-Mode Memory Leak
Finding a User-Mode Memory Leak
Using Performance Monitor to Find a User-Mode Memory Leak
Using UMDH to Find a User-Mode Memory Leak
Debugging a Time Out
Debugging a Time Out
Resource Time Outs
 Critical Section Time Outs
Debugging a Stalled System
Debugging a Stalled System
Finding the Failed Process
Debugging an Interrupt Storm
Debugging Multiple Targets
Tracking Down a Processor Hog
Determining the ACL of an Object
Displaying a Critical Section
Debugging a Deadlock
Debugging a Failed Driver Unload
Reading Bug Check Callback Data
Debugging a User-Mode Failure with KD
Crashing and Rebooting the Target Computer
Mapping Driver Files
Messages from the Target
Messages from the Target
Breaking Into the Debugger
Sending Output to the Debugger
Reading and Filtering Debugging Messages
Determining if a Debugger is Attached
Specialized Debugging Techniques
Specialized Debugging Techniques
Debugging ARM64
Windows Runtime Debugging
Kernel-Mode Driver Framework Debugging
User-Mode Driver Framework Debugging
Debugging Device Nodes and Device Stacks
Debugging Plug and Play and Power Issues
Debugging a User-Mode Failure with KD
Debugging a Device Installation Co-Installer
Debugging a Dual-Boot Machine
Debugging Windows Setup and the OS Loader
Debugging CSRSS
Debugging WinLogon
Debugging BIOS Code
Specifying Module and Function Owners
RPC Debugging
RPC Debugging
Overview of RPC Debugging
Enabling RPC State Information
Displaying RPC State Information
Displaying RPC State Information
Using the RPC Debugger Extensions
Using the DbgRpc Tool
Get RPC Cell Information
Get RPC Endpoint Information
Get RPC Thread Information
Get RPC Call Information
Get RPC Client Call Information
Common RPC Debugging Techniques
Common RPC Debugging Techniques
Analyzing a Stuck Call Problem
Tracking Contention in the Server Process
Checking for Stuck Threads
Identifying the Caller From the Server Thread
RPC State Information Internals
ACPI Debugging
ACPI Debugging
The AMLI Debugger
The AMLI Debugger
Introduction to the AMLI Debugger
Setting Up an AML Debugging Session
Basic AML Debugging
 Using AMLI Debugger Extensions
Using AMLI Debugger Commands
AML Debugging Examples
Other ACPI Debugging Extensions
NDIS Debugging
Overview of NDIS Debugging
Enabling NDIS Debug Tracing
Kernel Streaming Debugging
Kernel Streaming Debugging
Overview of Kernel Streaming Debugging
Analyzing a Video Stream Stall
Analyzing a Video Stream Stall
Determining the Cause of a Video Stream Stall
Debugging a Processing Stall
Using Logging to Track Important Events
Interpreting Bug Check 0xCB
Analyzing a Capture Stall
Live Local Debugging
Graph Analysis with Unloadable Modules
Using !ks.graph
SCSI Miniport Debugging
SCSI Miniport Debugging
Overview of SCSI Miniport Debugging
Extensions for Debugging SCSI Miniport Drivers
Bug Checks for SCSI Miniport Debugging
Analyzing Stalled Drivers and Time-Outs
Important Breakpoints for Analyzing Reproducible Problems
Plug and Play Debugging
Plug and Play Debugging
Extensions for Debugging Plug and Play Drivers
Determining the Status of a Device
Device Node Status Flags
 Device Manager Problem Codes
Checking for Resource Conflicts
Debugging a Service Application
Debugging a Service Application
Choosing the Best Method
Preparing to Debug the Service Application
Debugging the Service Application Automatically
Debugging the Service Application Manually
Symbols for Windows Debugging (WinDbg, KD, CDB, NTSD)
Symbols for Windows Debugging (WinDbg, KD, CDB, NTSD)
Introduction to Symbols
Introduction to Symbols
Symbol path for Windows debuggers
Symbols and Symbol Files
Public and Private Symbols
Portable PDB Symbols
Accessing Symbols for Debugging
Accessing Symbols for Debugging
Installing Windows Symbol Files
Symbol Stores and Symbol Servers
Symbol Stores and Symbol Servers
Using a Symbol Server
SymSrv
SymSrv
Microsoft public symbol server
Advanced SymSrv Use
Firewalls and Proxy Servers
HTTP Symbol Stores
File Share (SMB) Symbol Server
Symbol Store Folder Tree
SymProxy
SymProxy
 Installing SymProxy
Configuring the Registry
Choosing Network Security Credentials
Configuring IIS for SymProxy
Setting Up Exclusion Lists
Dealing with Unavailable Symbol Stores
Handling File Pointers
Caching Acquired Symbol Files
SymProxy Automated Installation
Other Symbol Stores
Other Symbol Servers
Deferred Symbol Loading
Avoiding debugger searches for unneeded symbols
SymStore
SymStore
SymStore Transactions
File System References and Symbol Files
Symbol Storage Format
How the Debugger Recognizes Symbols
How the Debugger Recognizes Symbols
Symbol Syntax and Symbol Matching
Symbol Options
Symbol Status Abbreviations
Symbol Problems While Debugging
Symbol Problems While Debugging
Verifying Symbols
Matching Symbol Names
Reading Symbols from Paged-Out Headers
Mapping Symbols When the PEB is Paged Out
Debugging User-Mode Processes Without Symbols
Debugging Performance-Optimized Code
Offline Symbols for Windows Update
 AgeStore
AgeStore
Using AgeStore
AgeStore Command-Line Options
DBH
DBH
Using DBH
Additional DBH Examples
DBH Command-Line Options
DBH Commands
PDBCopy
PDBCopy
Using PDBCopy
Choosing Which Public Symbols to Remove
PDBCopy Command-Line Options
SymChk
SymChk
Using SymChk
Using a Manifest File with SymChk
SymChk Command-Line Options
Crash dump analysis using the Windows debuggers (WinDbg)
Crash dump analysis using the Windows debuggers (WinDbg)
Kernel-Mode Dump Files
Kernel-Mode Dump Files
Varieties of Kernel-Mode Dump Files
Varieties of Kernel-Mode Dump Files
Complete Memory Dump
Kernel Memory Dump
Small Memory Dump
Automatic Memory Dump
Active Memory Dump
Creating a Kernel-Mode Dump File
 Creating a Kernel-Mode Dump File
Enabling a Kernel-Mode Dump File
Forcing a System Crash
Forcing a System Crash
Forcing a System Crash from the Debugger
Forcing a System Crash from the Keyboard
Forcing a System Crash with the Power Button
Creating a Dump File Without a System Crash
Verifying the Creation of a Kernel-Mode Dump File
Analyzing a Kernel-Mode Dump File
Analyzing a Kernel-Mode Dump File
Analyzing a Kernel-Mode Dump File with KD
Analyzing a Kernel-Mode Dump File with WinDbg
User-Mode Dump Files
User-Mode Dump Files
Analyzing a User-Mode Dump File
Extracting Information from a Dump File
CAB Files that Contain Paging Files Along with a Memory Dump
Debugging OCA minidump files
Bug Checks (Blue Screens)
Bug Checks (Blue Screens)
General Tips for Blue Screens
Blue Screen Data
Bug Check Code Reference
Bug Check Code Reference
Bug Check 0x1: APC_INDEX_MISMATCH
Bug Check 0x2: DEVICE_QUEUE_NOT_BUSY
Bug Check 0x3: INVALID_AFFINITY_SET
Bug Check 0x4: INVALID_DATA_ACCESS_TRAP
Bug Check 0x5: INVALID_PROCESS_ATTACH_ATTEMPT
Bug Check 0x6: INVALID_PROCESS_DETACH_ATTEMPT
Bug Check 0x7: INVALID_SOFTWARE_INTERRUPT
Bug Check 0x8: IRQL_NOT_DISPATCH_LEVEL
Bug Check 0x9: IRQL_NOT_GREATER_OR_EQUAL
Bug Check 0xA: IRQL_NOT_LESS_OR_EQUAL
Bug Check 0xB: NO_EXCEPTION_HANDLING_SUPPORT
Bug Check 0xC: MAXIMUM_WAIT_OBJECTS_EXCEEDED
Bug Check 0xD: MUTEX_LEVEL_NUMBER_VIOLATION
Bug Check 0xE: NO_USER_MODE_CONTEXT
Bug Check 0xF: SPIN_LOCK_ALREADY_OWNED
Bug Check 0x10: SPIN_LOCK_NOT_OWNED
Bug Check 0x11: THREAD_NOT_MUTEX_OWNER
Bug Check 0x12: TRAP_CAUSE_UNKNOWN
Bug Check 0x13: EMPTY_THREAD_REAPER_LIST
Bug Check 0x14: CREATE_DELETE_LOCK_NOT_LOCKED
Bug Check 0x15: LAST_CHANCE_CALLED_FROM_KMODE
Bug Check 0x16: CID_HANDLE_CREATION
Bug Check 0x17: CID_HANDLE_DELETION
Bug Check 0x18: REFERENCE_BY_POINTER
Bug Check 0x19: BAD_POOL_HEADER
Bug Check 0x1A: MEMORY_MANAGEMENT
Bug Check 0x1B: PFN_SHARE_COUNT
Bug Check 0x1C: PFN_REFERENCE_COUNT
Bug Check 0x1D: NO_SPIN_LOCK_AVAILABLE
Bug Check 0x1E: KMODE_EXCEPTION_NOT_HANDLED
Bug Check 0x1F: SHARED_RESOURCE_CONV_ERROR
Bug Check 0x20: KERNEL_APC_PENDING_DURING_EXIT
Bug Check 0x21: QUOTA_UNDERFLOW
Bug Check 0x22: FILE_SYSTEM
Bug Check 0x23: FAT_FILE_SYSTEM
Bug Check 0x24: NTFS_FILE_SYSTEM
Bug Check 0x25: NPFS_FILE_SYSTEM
Bug Check 0x26: CDFS_FILE_SYSTEM
Bug Check 0x27: RDR_FILE_SYSTEM
Bug Check 0x28: CORRUPT_ACCESS_TOKEN
Bug Check 0x29: SECURITY_SYSTEM
Bug Check 0x2A: INCONSISTENT_IRP
Bug Check 0x2B: PANIC_STACK_SWITCH
Bug Check 0x2C: PORT_DRIVER_INTERNAL
Bug Check 0x2D: SCSI_DISK_DRIVER_INTERNAL
Bug Check 0x2E: DATA_BUS_ERROR
Bug Check 0x2F: INSTRUCTION_BUS_ERROR
Bug Check 0x30: SET_OF_INVALID_CONTEXT
Bug Check 0x31: PHASE0_INITIALIZATION_FAILED
Bug Check 0x32: PHASE1_INITIALIZATION_FAILED
Bug Check 0x33: UNEXPECTED_INITIALIZATION_CALL
Bug Check 0x34: CACHE_MANAGER
Bug Check 0x35: NO_MORE_IRP_STACK_LOCATIONS
Bug Check 0x36: DEVICE_REFERENCE_COUNT_NOT_ZERO
Bug Check 0x37: FLOPPY_INTERNAL_ERROR
Bug Check 0x38: SERIAL_DRIVER_INTERNAL
Bug Check 0x39: SYSTEM_EXIT_OWNED_MUTEX
Bug Check 0x3A: SYSTEM_UNWIND_PREVIOUS_USER
Bug Check 0x3B: SYSTEM_SERVICE_EXCEPTION
Bug Check 0x3C: INTERRUPT_UNWIND_ATTEMPTED
Bug Check 0x3D: INTERRUPT_EXCEPTION_NOT_HANDLED
Bug Check 0x3E: MULTIPROCESSOR_CONFIGURATION_NOT_SUPPORTED
Bug Check 0x3F: NO_MORE_SYSTEM_PTES
Bug Check 0x40: TARGET_MDL_TOO_SMALL
Bug Check 0x41: MUST_SUCCEED_POOL_EMPTY
Bug Check 0x42: ATDISK_DRIVER_INTERNAL
Bug Check 0x43: NO_SUCH_PARTITION
Bug Check 0x44: MULTIPLE_IRP_COMPLETE_REQUESTS
Bug Check 0x45: INSUFFICIENT_SYSTEM_MAP_REGS
Bug Check 0x46: DEREF_UNKNOWN_LOGON_SESSION
Bug Check 0x47: REF_UNKNOWN_LOGON_SESSION
Bug Check 0x48: CANCEL_STATE_IN_COMPLETED_IRP
Bug Check 0x49: PAGE_FAULT_WITH_INTERRUPTS_OFF
Bug Check 0x4A: IRQL_GT_ZERO_AT_SYSTEM_SERVICE
Bug Check 0x4B: STREAMS_INTERNAL_ERROR
Bug Check 0x4C: FATAL_UNHANDLED_HARD_ERROR
Bug Check 0x4D: NO_PAGES_AVAILABLE
Bug Check 0x4E: PFN_LIST_CORRUPT
Bug Check 0x4F: NDIS_INTERNAL_ERROR
Bug Check 0x50: PAGE_FAULT_IN_NONPAGED_AREA
Bug Check 0x51: REGISTRY_ERROR
Bug Check 0x52: MAILSLOT_FILE_SYSTEM
Bug Check 0x53: NO_BOOT_DEVICE
Bug Check 0x54: LM_SERVER_INTERNAL_ERROR
Bug Check 0x55: DATA_COHERENCY_EXCEPTION
Bug Check 0x56: INSTRUCTION_COHERENCY_EXCEPTION
Bug Check 0x57: XNS_INTERNAL_ERROR
Bug Check 0x58: FTDISK_INTERNAL_ERROR
Bug Check 0x59: PINBALL_FILE_SYSTEM
Bug Check 0x5A: CRITICAL_SERVICE_FAILED
Bug Check 0x5B: SET_ENV_VAR_FAILED
Bug Check 0x5C: HAL_INITIALIZATION_FAILED
Bug Check 0x5D: UNSUPPORTED_PROCESSOR
Bug Check 0x5E: OBJECT_INITIALIZATION_FAILED
Bug Check 0x5F: SECURITY_INITIALIZATION_FAILED
Bug Check 0x60: PROCESS_INITIALIZATION_FAILED
Bug Check 0x61: HAL1_INITIALIZATION_FAILED
Bug Check 0x62: OBJECT1_INITIALIZATION_FAILED
Bug Check 0x63: SECURITY1_INITIALIZATION_FAILED
Bug Check 0x64: SYMBOLIC_INITIALIZATION_FAILED
Bug Check 0x65: MEMORY1_INITIALIZATION_FAILED
Bug Check 0x66: CACHE_INITIALIZATION_FAILED
Bug Check 0x67: CONFIG_INITIALIZATION_FAILED
Bug Check 0x68: FILE_INITIALIZATION_FAILED
Bug Check 0x69: IO1_INITIALIZATION_FAILED
Bug Check 0x6A: LPC_INITIALIZATION_FAILED
Bug Check 0x6B: PROCESS1_INITIALIZATION_FAILED
Bug Check 0x6C: REFMON_INITIALIZATION_FAILED
Bug Check 0x6D: SESSION1_INITIALIZATION_FAILED
Bug Check 0x6E: SESSION2_INITIALIZATION_FAILED
Bug Check 0x6F: SESSION3_INITIALIZATION_FAILED
Bug Check 0x70: SESSION4_INITIALIZATION_FAILED
Bug Check 0x71: SESSION5_INITIALIZATION_FAILED
Bug Check 0x72: ASSIGN_DRIVE_LETTERS_FAILED
Bug Check 0x73: CONFIG_LIST_FAILED
Bug Check 0x74: BAD_SYSTEM_CONFIG_INFO
Bug Check 0x75: CANNOT_WRITE_CONFIGURATION
Bug Check 0x76: PROCESS_HAS_LOCKED_PAGES
Bug Check 0x77: KERNEL_STACK_INPAGE_ERROR
Bug Check 0x78: PHASE0_EXCEPTION
Bug Check 0x79: MISMATCHED_HAL
Bug Check 0x7A: KERNEL_DATA_INPAGE_ERROR
Bug Check 0x7B: INACCESSIBLE_BOOT_DEVICE
Bug Check 0x7C: BUGCODE_NDIS_DRIVER
Bug Check 0x7D: INSTALL_MORE_MEMORY
Bug Check 0x7E: SYSTEM_THREAD_EXCEPTION_NOT_HANDLED
Bug Check 0x7F: UNEXPECTED_KERNEL_MODE_TRAP
Bug Check 0x80: NMI_HARDWARE_FAILURE
Bug Check 0x81: SPIN_LOCK_INIT_FAILURE
Bug Check 0x82: DFS_FILE_SYSTEM
Bug Check 0x85: SETUP_FAILURE
Bug Check 0x8B: MBR_CHECKSUM_MISMATCH
Bug Check 0x8E: KERNEL_MODE_EXCEPTION_NOT_HANDLED
Bug Check 0x8F: PP0_INITIALIZATION_FAILED
Bug Check 0x90: PP1_INITIALIZATION_FAILED
Bug Check 0x92: UP_DRIVER_ON_MP_SYSTEM
Bug Check 0x93: INVALID_KERNEL_HANDLE
Bug Check 0x94: KERNEL_STACK_LOCKED_AT_EXIT
Bug Check 0x96: INVALID_WORK_QUEUE_ITEM
Bug Check 0x97: BOUND_IMAGE_UNSUPPORTED
Bug Check 0x98: END_OF_NT_EVALUATION_PERIOD
Bug Check 0x99: INVALID_REGION_OR_SEGMENT
Bug Check 0x9A: SYSTEM_LICENSE_VIOLATION
Bug Check 0x9B: UDFS_FILE_SYSTEM
Bug Check 0x9C: MACHINE_CHECK_EXCEPTION
Bug Check 0x9E: USER_MODE_HEALTH_MONITOR
Bug Check 0x9F: DRIVER_POWER_STATE_FAILURE
Bug Check 0xA0: INTERNAL_POWER_ERROR
Bug Check 0xA1: PCI_BUS_DRIVER_INTERNAL
Bug Check 0xA2: MEMORY_IMAGE_CORRUPT
Bug Check 0xA3: ACPI_DRIVER_INTERNAL
Bug Check 0xA4: CNSS_FILE_SYSTEM_FILTER
Bug Check 0xA5: ACPI_BIOS_ERROR
Bug Check 0xA7: BAD_EXHANDLE
Bug Check 0xAC: HAL_MEMORY_ALLOCATION
Bug Check 0xAD: VIDEO_DRIVER_DEBUG_REPORT_REQUEST
Bug Check 0xB1: BGI_DETECTED_VIOLATION
Bug Check 0xB4: VIDEO_DRIVER_INIT_FAILURE
Bug Check 0xB8: ATTEMPTED_SWITCH_FROM_DPC
Bug Check 0xB9: CHIPSET_DETECTED_ERROR
Bug Check 0xBA: SESSION_HAS_VALID_VIEWS_ON_EXIT
Bug Check 0xBB: NETWORK_BOOT_INITIALIZATION_FAILED
Bug Check 0xBC: NETWORK_BOOT_DUPLICATE_ADDRESS
Bug Check 0xBD: INVALID_HIBERNATED_STATE
Bug Check 0xBE: ATTEMPTED_WRITE_TO_READONLY_MEMORY
Bug Check 0xBF: MUTEX_ALREADY_OWNED
Bug Check 0xC1: SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION
 Bug Check 0xC2: BAD_POOL_CALLER
Bug Check 0xC4: DRIVER_VERIFIER_DETECTED_VIOLATION
Bug Check 0xC5: DRIVER_CORRUPTED_EXPOOL
Bug Check 0xC6: DRIVER_CAUGHT_MODIFYING_FREED_POOL
Bug Check 0xC7: TIMER_OR_DPC_INVALID
Bug Check 0xC8: IRQL_UNEXPECTED_VALUE
Bug Check 0xC9: DRIVER_VERIFIER_IOMANAGER_VIOLATION
Bug Check 0xCA: PNP_DETECTED_FATAL_ERROR
Bug Check 0xCB: DRIVER_LEFT_LOCKED_PAGES_IN_PROCESS
Bug Check 0xCC: PAGE_FAULT_IN_FREED_SPECIAL_POOL
Bug Check 0xCD: PAGE_FAULT_BEYOND_END_OF_ALLOCATION
Bug Check 0xCE:
DRIVER_UNLOADED_WITHOUT_CANCELLING_PENDING_OPERATIONS
Bug Check 0xCF:
TERMINAL_SERVER_DRIVER_MADE_INCORRECT_MEMORY_REFERENCE
Bug Check 0xD0: DRIVER_CORRUPTED_MMPOOL
Bug Check 0xD1: DRIVER_IRQL_NOT_LESS_OR_EQUAL
Bug Check 0xD2: BUGCODE_ID_DRIVER
Bug Check 0xD3: DRIVER_PORTION_MUST_BE_NONPAGED
Bug Check 0xD4:
SYSTEM_SCAN_AT_RAISED_IRQL_CAUGHT_IMPROPER_DRIVER_UNLOAD
Bug Check 0xD5: DRIVER_PAGE_FAULT_IN_FREED_SPECIAL_POOL
Bug Check 0xD6: DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION
Bug Check 0xD7: DRIVER_UNMAPPING_INVALID_VIEW
Bug Check 0xD8: DRIVER_USED_EXCESSIVE_PTES
Bug Check 0xD9: LOCKED_PAGES_TRACKER_CORRUPTION
Bug Check 0xDA: SYSTEM_PTE_MISUSE
Bug Check 0xDB: DRIVER_CORRUPTED_SYSPTES
Bug Check 0xDC: DRIVER_INVALID_STACK_ACCESS
Bug Check 0xDE: POOL_CORRUPTION_IN_FILE_AREA
Bug Check 0xDF: IMPERSONATING_WORKER_THREAD
Bug Check 0xE0: ACPI_BIOS_FATAL_ERROR
Bug Check 0xE1: WORKER_THREAD_RETURNED_AT_BAD_IRQL
Bug Check 0xE2: MANUALLY_INITIATED_CRASH
Bug Check 0xE3: RESOURCE_NOT_OWNED
Bug Check 0xE4: WORKER_INVALID
Bug Check 0xE6: DRIVER_VERIFIER_DMA_VIOLATION
Bug Check 0xE7: INVALID_FLOATING_POINT_STATE
Bug Check 0xE8: INVALID_CANCEL_OF_FILE_OPEN
Bug Check 0xE9: ACTIVE_EX_WORKER_THREAD_TERMINATION
Bug Check 0xEA: THREAD_STUCK_IN_DEVICE_DRIVER
Bug Check 0xEB: DIRTY_MAPPED_PAGES_CONGESTION
Bug Check 0xEC: SESSION_HAS_VALID_SPECIAL_POOL_ON_EXIT
Bug Check 0xED: UNMOUNTABLE_BOOT_VOLUME
Bug Check 0xEF: CRITICAL_PROCESS_DIED
Bug Check 0xF0: STORAGE_MINIPORT_ERROR
Bug Check 0xF1: SCSI_VERIFIER_DETECTED_VIOLATION
Bug Check 0xF2: HARDWARE_INTERRUPT_STORM
Bug Check 0xF3: DISORDERLY_SHUTDOWN
Bug Check 0xF4: CRITICAL_OBJECT_TERMINATION
Bug Check 0xF5: FLTMGR_FILE_SYSTEM
Bug Check 0xF6: PCI_VERIFIER_DETECTED_VIOLATION
Bug Check 0xF7: DRIVER_OVERRAN_STACK_BUFFER
Bug Check 0xF8: RAMDISK_BOOT_INITIALIZATION_FAILED
Bug Check 0xF9: DRIVER_RETURNED_STATUS_REPARSE_FOR_VOLUME_OPEN
Bug Check 0xFA: HTTP_DRIVER_CORRUPTED
Bug Check 0xFC: ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY
Bug Check 0xFD: DIRTY_NOWRITE_PAGES_CONGESTION
Bug Check 0xFE: BUGCODE_USB_DRIVER
Bug Check 0xFF: RESERVE_QUEUE_OVERFLOW
Bug Check 0x100: LOADER_BLOCK_MISMATCH
Bug Check 0x101: CLOCK_WATCHDOG_TIMEOUT
Bug Check 0x102: DPC_WATCHDOG_TIMEOUT
Bug Check 0x103: MUP_FILE_SYSTEM
Bug Check 0x104: AGP_INVALID_ACCESS
 Bug Check 0x105: AGP_GART_CORRUPTION
Bug Check 0x106: AGP_ILLEGALLY_REPROGRAMMED
Bug Check 0x108: THIRD_PARTY_FILE_SYSTEM_FAILURE
Bug Check 0x109: CRITICAL_STRUCTURE_CORRUPTION
Bug Check 0x10A: APP_TAGGING_INITIALIZATION_FAILED
Bug Check 0x10C: FSRTL_EXTRA_CREATE_PARAMETER_VIOLATION
Bug Check 0x10D: WDF_VIOLATION
Bug Check 0x10E: VIDEO_MEMORY_MANAGEMENT_INTERNAL
Bug Check 0x10F: RESOURCE_MANAGER_EXCEPTION_NOT_HANDLED
Bug Check 0x111: RECURSIVE_NMI
Bug Check 0x112: MSRPC_STATE_VIOLATION
Bug Check 0x113: VIDEO_DXGKRNL_FATAL_ERROR
Bug Check 0x114: VIDEO_SHADOW_DRIVER_FATAL_ERROR
Bug Check 0x115: AGP_INTERNAL
Bug Check 0x116: VIDEO_TDR_FAILURE
Bug Check 0x117: VIDEO_TDR_TIMEOUT_DETECTED
Bug Check 0x119: VIDEO_SCHEDULER_INTERNAL_ERROR
Bug Check 0x11A: EM_INITIALIZATION_FAILURE
Bug Check 0x11B: DRIVER_RETURNED_HOLDING_CANCEL_LOCK
Bug Check 0x11C: ATTEMPTED_WRITE_TO_CM_PROTECTED_STORAGE
Bug Check 0x11D: EVENT_TRACING_FATAL_ERROR
Bug Check 0x11E: TOO_MANY_RECURSIVE_FAULTS
Bug Check 0x11F: INVALID_DRIVER_HANDLE
Bug Check 0x120: BITLOCKER_FATAL_ERROR
Bug Check 0x121: DRIVER_VIOLATION
Bug Check 0x122: WHEA_INTERNAL_ERROR
Bug Check 0x123: CRYPTO_SELF_TEST_FAILURE
Bug Check 0x125: NMR_INVALID_STATE
Bug Check 0x126: NETIO_INVALID_POOL_CALLER
Bug Check 0x127: PAGE_NOT_ZERO
Bug Check 0x128: WORKER_THREAD_RETURNED_WITH_BAD_IO_PRIORITY
Bug Check 0x129:
WORKER_THREAD_RETURNED_WITH_BAD_PAGING_IO_PRIORITY
Bug Check 0x12A: MUI_NO_VALID_SYSTEM_LANGUAGE
Bug Check 0x12B: FAULTY_HARDWARE_CORRUPTED_PAGE
Bug Check 0x12C: EXFAT_FILE_SYSTEM
Bug Check 0x12D: VOLSNAP_OVERLAPPED_TABLE_ACCESS
Bug Check 0x12E: INVALID_MDL_RANGE
Bug Check 0x12F: VHD_BOOT_INITIALIZATION_FAILED
Bug Check 0x130: DYNAMIC_ADD_PROCESSOR_MISMATCH
Bug Check 0x131: INVALID_EXTENDED_PROCESSOR_STATE
Bug Check 0x132: RESOURCE_OWNER_POINTER_INVALID
Bug Check 0x133 DPC_WATCHDOG_VIOLATION
Bug Check 0x134: DRIVE_EXTENDER
Bug Check 0x135: REGISTRY_FILTER_DRIVER_EXCEPTION
Bug Check 0x136: VHD_BOOT_HOST_VOLUME_NOT_ENOUGH_SPACE
Bug Check 0x137: WIN32K_HANDLE_MANAGER
Bug Check 0x138: GPIO_CONTROLLER_DRIVER_ERROR
Bug Check 0x139: KERNEL_SECURITY_CHECK_FAILURE
Bug Check 0x13A: KERNEL_MODE_HEAP_CORRUPTION
Bug Check 0x13B: PASSIVE_INTERRUPT_ERROR
Bug Check 0x13C: INVALID_IO_BOOST_STATE
Bug Check 0x13D: CRITICAL_INITIALIZATION_FAILURE
Bug Check 0x140: STORAGE_DEVICE_ABNORMALITY_DETECTED
Bug Check 0x143: PROCESSOR_DRIVER_INTERNAL
Bug Check 0x144: BUGCODE_USB3_DRIVER
Bug Check 0x145: SECURE_BOOT_VIOLATION
Bug Check 0x147: ABNORMAL_RESET_DETECTED
Bug Check 0x14B: SOC_SUBSYSTEM_FAILURE
Bug Check 0x149: REFS_FILE_SYSTEM
Bug Check 0x14A: KERNEL_WMI_INTERNAL
Bug Check 0x14C: FATAL_ABNORMAL_RESET_ERROR
Bug Check 0x14D: EXCEPTION_SCOPE_INVALID
Bug Check 0x14E: SOC_CRITICAL_DEVICE_REMOVED
Bug Check 0x14F: PDC_WATCHDOG_TIMEOUT
 Bug Check 0x150: TCPIP_AOAC_NIC_ACTIVE_REFERENCE_LEAK
Bug Check 0x151: UNSUPPORTED_INSTRUCTION_MODE
Bug Check 0x152: INVALID_PUSH_LOCK_FLAGS
Bug Check 0x153: KERNEL_LOCK_ENTRY_LEAKED_ON_THREAD_TERMINATION
Bug Check 0x154: UNEXPECTED_STORE_EXCEPTION
Bug Check 0x155: OS_DATA_TAMPERING
Bug Check 0x157: KERNEL_THREAD_PRIORITY_FLOOR_VIOLATION
Bug Check 0x158: ILLEGAL_IOMMU_PAGE_FAULT
Bug Check 0x159: HAL_ILLEGAL_IOMMU_PAGE_FAULT
Bug Check 0x15A: SDBUS_INTERNAL_ERROR
Bug Check 0x15B:
WORKER_THREAD_RETURNED_WITH_SYSTEM_PAGE_PRIORITY_ACTIVE
Bug Check 0x160: WIN32K_ATOMIC_CHECK_FAILURE
Bug Check 0x162: KERNEL_AUTO_BOOST_INVALID_LOCK_RELEASE
Bug Check 0x163: WORKER_THREAD_TEST_CONDITION
Bug Check 0x16C: INVALID_RUNDOWN_PROTECTION_FLAGS
Bug Check 0x16D: INVALID_SLOT_ALLOCATOR_FLAGS
Bug Check 0x16E: ERESOURCE_INVALID_RELEASE
Bug Check 0x170: CRYPTO_LIBRARY_INTERNAL_ERROR
Bug Check 0x171: CLUSTER_CSV_CLUSSVC_DISCONNECT_WATCHDOG
Bug Check 0x173: COREMSGCALL_INTERNAL_ERROR
Bug Check 0x174: COREMSG_INTERNAL_ERROR
Bug Check 0x178: ELAM_DRIVER_DETECTED_FATAL_ERROR
Bug Check 0x17B PROFILER_CONFIGURATION_ILLEGAL
Bug Check 0x17E MICROCODE_REVISION_MISMATCH
Bug Check 0x189: BAD_OBJECT_HEADER
Bug Check 0x18B: SECURE_KERNEL_ERROR
Bug Check 0x18C: HYPERGUARD_VIOLATION
Bug Check 0x18D: SECURE_FAULT_UNHANDLED
Bug Check 0x18E: KERNEL_PARTITION_REFERENCE_VIOLATION
Bug Check 0x191: PF_DETECTED_CORRUPTION
Bug Check 0x192:
KERNEL_AUTO_BOOST_LOCK_ACQUISITION_WITH_RAISED_IRQL
 Bug Check 0x196: LOADER_ROLLBACK_DETECTED
Bug Check 0x197: WIN32K_SECURITY_FAILURE
Bug Check 0x199: KERNEL_STORAGE_SLOT_IN_USE
Bug Check 0x19A: WORKER_THREAD_RETURNED_WHILE_ATTACHED_TO_SILO
Bug Check 0x19B: TTM_FATAL_ERROR
Bug Check 0x19C: WIN32K_POWER_WATCHDOG_TIMEOUT
Bug Check 0x1A2: WIN32K_CALLOUT_WATCHDOG_BUGCHECK
Bug Check 0x1C6: FAST_ERESOURCE_PRECONDITION_VIOLATION
Bug Check 0x1C7: STORE_DATA_STRUCTURE_CORRUPTION
Bug Check 0x1C8 MANUALLY_INITIATED_POWER_BUTTON_HOLD
Bug Check 0x1CA: SYNTHETIC_WATCHDOG_TIMEOUT
Bug Check 0x1CB: INVALID_SILO_DETACH
Bug Check 0x1CD: INVALID_CALLBACK_STACK_ADDRESS
Bug Check 0x1CE: INVALID_KERNEL_STACK_ADDRESS
Bug Check 0x1CF: HARDWARE_WATCHDOG_TIMEOUT
Bug Check 0x1D0: CPI_FIRMWARE_WATCHDOG_TIMEOUT
Bug Check 0x1D2: WORKER_THREAD_INVALID_STATE
Bug Check 0x1D3: WFP_INVALID_OPERATION
Bug Check 0x1D5: DRIVER_PNP_WATCHDOG
Bug Check 0x1D6:
WORKER_THREAD_RETURNED_WITH_NON_DEFAULT_WORKLOAD_CLASS
Bug Check 0x1D7: EFS_FATAL_ERROR
Bug Check 0x1D8: UCMUCSI_FAILURE
Bug Check 0x1D9: HAL_IOMMU_INTERNAL_ERROR
Bug Check 0x1DA: HAL_BLOCKED_PROCESSOR_INTERNAL_ERROR
Bug Check 0x1DB: IPI_WATCHDOG_TIMEOUT
Bug Check 0x1DC: DMA_COMMON_BUFFER_VECTOR_ERROR
Bug Check 0x356: XBOX_ERACTRL_CS_TIMEOUT
Bug Check 0xBFE: BC_BLUETOOTH_VERIFIER_FAULT
Bug Check 0xBFF: BC_BTHMINI_VERIFIER_FAULT
Bug Check 0x20001: HYPERVISOR_ERROR
Bug Check 0x1000007E: SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M
Bug Check 0x1000007F: UNEXPECTED_KERNEL_MODE_TRAP_M
 Bug Check 0x1000008E: KERNEL_MODE_EXCEPTION_NOT_HANDLED_M
Bug Check 0x100000EA: THREAD_STUCK_IN_DEVICE_DRIVER_M
Bug Check 0x4000008A: THREAD_TERMINATE_HELD_MUTEX
Bug Check 0xC0000218: STATUS_CANNOT_LOAD_REGISTRY_FILE
Bug Check 0xC000021A: WINLOGON_FATAL_ERROR
Bug Check 0xC0000221: STATUS_IMAGE_CHECKSUM_MISMATCH
Bug Check 0xDEADDEAD: MANUALLY_INITIATED_CRASH1
Bug Check Code Reference- Kernel Live Dump
Kernel Live Dump Code Reference
Bug Check 0xAB: SESSION_HAS_VALID_POOL_ON_EXIT
Bug Check 0x124: WHEA_UNCORRECTABLE_ERROR
Bug Check 0x141: VIDEO_ENGINE_TIMEOUT_DETECTED
Bug Check 0x142: VIDEO_TDR_APPLICATION_BLOCKED
Bug Check 0x156: WINSOCK_DETECTED_HUNG_CLOSESOCKET_LIVEDUMP
Bug Check 0x15C: PDC_WATCHDOG_TIMEOUT_LIVEDUMP
Bug Check 0x15D: SOC_SUBSYSTEM_FAILURE_LIVEDUMP
Bug Check 0x15E: BUGCODE_NDIS_DRIVER_LIVE_DUMP
Bug Check 0x15F: CONNECTED_STANDBY_WATCHDOG_TIMEOUT_LIVEDUMP
Bug Check 0x161: LIVE_SYSTEM_DUMP
Bug Check 0x164: WIN32K_CRITICAL_FAILURE
Bug Check 0x165: CLUSTER_CSV_STATUS_IO_TIMEOUT_LIVEDUMP
Bug Check 0x166: CLUSTER_RESOURCE_CALL_TIMEOUT_LIVEDUMP
Bug Check 0x167:
CLUSTER_CSV_SNAPSHOT_DEVICE_INFO_TIMEOUT_LIVEDUMP
Bug Check 0x168: CLUSTER_CSV_STATE_TRANSITION_TIMEOUT_LIVEDUMP
Bug Check 0x169: CLUSTER_CSV_VOLUME_ARRIVAL_LIVEDUMP
Bug Check 0x16A: CLUSTER_CSV_VOLUME_REMOVAL_LIVEDUMP
Bug Check 0x16B: CLUSTER_CSV_CLUSTER_WATCHDOG_LIVEDUMP
Bug Check 0x16F:
CLUSTER_CSV_STATE_TRANSITION_INTERVAL_TIMEOUT_LIVEDUMP
Bug Check 0x175: PREVIOUS_FATAL_ABNORMAL_RESET_ERROR
Bug Check 0x179: CLUSTER_CLUSPORT_STATUS_IO_TIMEOUT_LIVEDUMP
Bug Check 0x17C PDC_LOCK_WATCHDOG_LIVEDUMP
 Bug Check 0x17D PDC_UNEXPECTED_REVOCATION_LIVEDUMP
Bug Check 0x187: VIDEO_DWMINIT_TIMEOUT_FALLBACK_BDD
Bug Check 0x188: CLUSTER_CSVFS_LIVEDUMP
Bug Check 0x190: WIN32K_CRITICAL_FAILURE_LIVEDUMP
Bug Check 0x193: VIDEO_DXGKRNL_LIVEDUMP
Bug Check 0x195: SMB_SERVER_LIVEDUMP
Bug Check 0x198: UFX_LIVEDUMP
Bug Check 0x19D: CLUSTER_SVHDX_LIVEDUMP
Bug Check 0x1A0: TTM_WATCHDOG_TIMEOUT
Bug Check 0x1A1: WIN32K_CALLOUT_WATCHDOG_LIVEDUMP
Bug Check 0x1A3:
CALL_HAS_NOT_RETURNED_WATCHDOG_TIMEOUT_LIVEDUMP
Bug Check 0x1A4: DRIPS_SW_HW_DIVERGENCE_LIVEDUMP
Bug Check 0x1A5: USB_DRIPS_BLOCKER_SURPRISE_REMOVAL_LIVEDUMP
Bug Check 0x1A6: BLUETOOTH_ERROR_RECOVERY_LIVEDUMP
Bug Check 0x1A7: SMB_REDIRECTOR_LIVEDUMP
Bug Check 0x1A8: VIDEO_DXGKRNL_BLACK_SCREEN_LIVEDUMP
Bug Check 0x1B0: VIDEO_MINIPORT_FAILED_LIVEDUMP
Bug Check 0x1B8: VIDEO_MINIPORT_BLACK_SCREEN_LIVEDUMP
Bug Check 0x1C4: DRIVER_VERIFIER_DETECTED_VIOLATION_LIVEDUMP
Bug Check 0x1C5: IO_THREADPOOL_DEADLOCK_LIVEDUMP
Bug Check 0x1C9: USER_MODE_HEALTH_MONITOR_LIVEDUMP
Bug Check 0x1CC: EXRESOURCE_TIMEOUT_LIVEDUMP
Bug Check 0x1D1: TELEMETRY_ASSERTS_LIVEDUMP
Bug Check 0x1D4: UCMUCSI_LIVEDUMP
Debugger Reference
Debugger Reference
Command-Line Options
Command-Line Options
CDB Command-Line Options
KD Command-Line Options
WinDbg Command-Line Options
DbgSrv Command-Line Options
 KdSrv Command-Line Options
DbEngPrx Command-Line Options
KDbgCtrl Command-Line Options
DbgRpc Command-Line Options
SymStore Command-Line Options
Environment Variables
Environment Variables
General Environment Variables
Kernel-Mode Environment Variables
Debugger Commands
Debugger Commands
Syntax Rules
Syntax Rules
Numerical Expression Syntax
Numerical Expression Syntax
MASM Numbers and Operators
C++ Numbers and Operators
MASM Expressions vs. C++ Expressions
Mixed Expression Examples
Sign Extension
String Wildcard Syntax
Register Syntax
Pseudo-Register Syntax
Source Line Syntax
Address and Address Range Syntax
Thread Syntax
Process Syntax
System Syntax
Multiprocessor Syntax
Command Tokens
Command Tokens
; (Command Separator)
 { } (Block Delimiter)
${ } (Alias Interpreter)
$$ (Comment Specifier)
* (Comment Line Specifier)
.block
.break
.catch
.continue
.do
.else
.elsif
.for
.foreach
.if
.leave
.printf
.while
Commands
Commands
ENTER (Repeat Last Command)
$<, $><, $$<, $$><, $$ >a< (Run Script File)
? (Command Help)
? (Evaluate Expression)
?? (Evaluate C++ Expression)
# (Search for Disassembly Pattern)
|| (System Status)
||s (Set Current System)
| (Process Status)
|s (Set Current Process)
~ (Thread Status)
~e (Thread-Specific Command)
~f (Freeze Thread)
~u (Unfreeze Thread)
~n (Suspend Thread)
~m (Resume Thread)
~s (Set Current Thread)
~s (Change Current Processor)
a (Assemble)
ad (Delete Alias)
ah (Assertion Handling)
al (List Aliases)
as, aS (Set Alias)
ba (Break on Access)
bc (Breakpoint Clear)
bd (Breakpoint Disable)
be (Breakpoint Enable)
bl (Breakpoint List)
bp, bu, bm (Set Breakpoint)
br (Breakpoint Renumber)
bs (Update Breakpoint Command)
bsc (Update Conditional Breakpoint)
c (Compare Memory)
d, da, db, dc, dd, dD, df, dp, dq, du, dw, dW, dyb, dyd (Display Memory)
dda, ddp, ddu, dpa, dpp, dpu, dqa, dqp, dqu (Display Referenced Memory)
dds, dps, dqs (Display Words and Symbols)
dg (Display Selector)
dl (Display Linked List)
ds, dS (Display String)
dt (Display Type)
dtx (Display Type - Extended Debugger Object Model Information)
dv (Display Local Variables)
dx (Display Debugger Object Model Expression)
e, ea, eb, ed, eD, ef, ep, eq, eu, ew, eza, ezu (Enter Values)
f, fp (Fill Memory)
g (Go)
gc (Go from Conditional Breakpoint)
gh (Go with Exception Handled)
gn, gN (Go with Exception Not Handled)
gu (Go Up)
ib, iw, id (Input from Port)
j (Execute If - Else)
k, kb, kc, kd, kp, kP, kv (Display Stack Backtrace)
l+, l- (Set Source Options)
ld (Load Symbols)
lm (List Loaded Modules)
ln (List Nearest Symbols)
ls, lsa (List Source Lines)
lsc (List Current Source)
lse (Launch Source Editor)
lsf, lsf- (Load or Unload Source File)
lsp (Set Number of Source Lines)
m (Move Memory)
n (Set Number Base)
ob, ow, od (Output to Port)
p (Step)
pa (Step to Address)
pc (Step to Next Call)
pct (Step to Next Call or Return)
ph (Step to Next Branching Instruction)
pt (Step to Next Return)
q, qq (Quit)
qd (Quit and Detach)
r (Registers)
rdmsr (Read MSR)
rm (Register Mask)
s (Search Memory)
 so (Set Kernel Debugging Options)
sq (Set Quiet Mode)
ss (Set Symbol Suffix)
sx, sxd, sxe, sxi, sxn, sxr, sx- (Set Exceptions)
t (Trace)
ta (Trace to Address)
tb (Trace to Next Branch)
tc (Trace to Next Call)
tct (Trace to Next Call or Return)
th (Trace to Next Branching Instruction)
tt (Trace to Next Return)
u (Unassemble)
uf (Unassemble Function)
up (Unassemble from Physical Memory)
ur (Unassemble Real Mode BIOS)
ux (Unassemble x86 BIOS)
vercommand (Show Debugger Command Line)
version (Show Debugger Version)
vertarget (Show Target Computer Version)
wrmsr (Write MSR)
wt (Trace and Watch Data)
x (Examine Symbols)
z (Execute While)
Meta-Commands
Meta-Commands
.abandon (Abandon Process)
.allow_exec_cmds (Allow Execution Commands)
.allow_image_mapping (Allow Image Mapping)
.apply_dbp (Apply Data Breakpoint to Context)
.asm (Change Disassembly Options)
.attach (Attach to Process)
.beep (Speaker Beep)
.bpcmds (Display Breakpoint Commands)
.bpsync (Synchronize Threads at Breakpoint)
.breakin (Break to the Kernel Debugger)
.browse (Display Command in Browser)
.bugcheck (Display Bug Check Data)
.cache (Set Cache Size)
.call (Call Function)
.chain (List Debugger Extensions)
.childdbg (Debug Child Processes)
.clients (List Debugging Clients)
.closehandle (Close Handle)
.cls (Clear Screen)
.context (Set User-Mode Address Context)
.copysym (Copy Symbol Files)
.cordll (Control CLR Debugging)
.crash (Force System Crash)
.create (Create Process)
.createdir (Set Created Process Directory)
.cxr (Display Context Record)
.dbgdbg (Debug Current Debugger)
.detach (Detach from Process)
.dml_flow (Unassemble with Links)
.dml_start (Display DML Starting Point)
.dump (Create Dump File)
.dumpcab (Create Dump File CAB)
.dvalloc (Allocate Memory)
.dvfree (Free Memory)
.echo (Echo Comment)
.echocpunum (Show CPU Number)
.echotime (Show Current Time)
.echotimestamps (Show Time Stamps)
.ecxr (Display Exception Context Record)
.effmach (Effective Machine)
.enable_long_status (Enable Long Integer Display)
.enable_unicode (Enable Unicode Display)
.endpsrv (End Process Server)
.endsrv (End Debugging Server)
.enumtag (Enumerate Secondary Callback Data)
.event_code (Display Event Code)
.eventlog (Display Recent Events)
.exepath (Set Executable Path)
.expr (Choose Expression Evaluator)
.exptr (Display Exception Pointers)
.exr (Display Exception Record)
.excr (Display Exception Context Record)
.extmatch (Display All Matching Extensions)
.extpath (Set Extension Path)
.f+, .f- (Shift Local Context)
.fiber (Set Fiber Context)
.fiximports (Fix Target Module Imports)
.flash_on_break (Flash on Break)
.fnent (Display Function Data)
.fnret (Display Function Return Value)
.force_radix_output (Use Radix for Integers)
.force_tb (Forcibly Allow Branch Tracing)
.formats (Show Number Formats)
.fpo (Control FPO Overrides)
.frame (Set Local Context)
.help (Meta-Command Help)
.hh (Open HTML Help File)
.hideinjectedcode (Hide Injected Code)
.holdmem (Hold and Compare Memory)
.idle_cmd (Set Idle Command)
.ignore_missing_pages (Suppress Missing Page Errors)
.inline (Toggle Inline Function Debugging)
.imgscan (Find Image Headers)
.jdinfo (Use JIT_DEBUG_INFO)
.kdfiles (Set Driver Replacement Map)
.kdtargetmac (Display Target MAC Address)
.kframes (Set Stack Length)
.kill (Kill Process)
.lastevent (Display Last Event)
.lines (Toggle Source Line Support)
.load, .loadby (Load Extension DLL)
.locale (Set Locale)
.logappend (Append Log File)
.logclose (Close Log File)
.logfile (Display Log File Status)
.logopen (Open Log File)
.netsyms (Disable Network Symbol Loading)
.netuse (Control Network Connections)
.noshell (Prohibit Shell Commands)
.noversion (Disable Version Checking)
.ocommand (Expect Commands from Target)
.nvload (NatVis Load)
.nvlist (NatVis List)
.nvunload (NatVis Unload)
.nvunloadall (NatVis Unload All)
.ofilter (Filter Target Output)
.open (Open Source File)
.opendump (Open Dump File)
.outmask (Control Output Mask)
.pagein (Page In Memory)
.pcmd (Set Prompt Command)
.pop (Restore Debugger State)
.prefer_dml (Prefer Debugger Markup Language)
.process (Set Process Context)
.prompt_allow (Control Prompt Display)
.push (Save Debugger State)
.quit_lock (Prevent Accidental Quit)
.readmem (Read Memory from File)
.reboot (Reboot Target Computer)
.record_branches (Enable Branch Recording)
.reload (Reload Module)
.remote (Create Remote.exe Server)
.remote_exit (Exit Debugging Client)
.restart (Restart Target Application)
.restart (Restart Kernel Connection)
.rrestart (Register for Restart)
.scroll_prefs (Control Source Scrolling Preferences)
.scriptdebug (Debug JavaScript)
.scriptlist (List Loaded Scripts)
.scriptload (Load Script)
.scriptproviders (List Script Providers)
.scriptrun (Run Script)
.scriptunload (Unload Script)
.secure (Activate Secure Mode)
.send_file (Send File)
.server (Create Debugging Server)
.servers (List Debugging Servers)
.setdll (Set Default Extension DLL)
.shell (Command Shell)
.settings (Set Debug Settings)
.show_read_failures
.show_sym_failures
.sleep (Pause Debugger)
.sound_notify (Use Notification Sound)
.srcfix, .lsrcfix (Use Source Server)
 .srcnoisy (Noisy Source Loading)
.srcpath, .lsrcpath (Set Source Path)
.step_filter (Set Step Filter)
.suspend_ui (Suspend WinDbg Interface)
.symfix (Set Symbol Store Path)
.symopt (Set Symbol Options)
.sympath (Set Symbol Path)
.thread (Set Register Context)
.time (Display System Time)
.tlist (List Process IDs)
.trap (Display Trap Frame)
.tss (Display Task State Segment)
.ttime (Display Thread Times)
.typeopt (Set Type Options)
.unload (Unload Extension DLL)
.unloadall (Unload All Extension DLLs)
.urestart (Unregister for Restart)
.wake (Wake Debugger)
.write_cmd_hist (Write Command History)
.writemem (Write Memory to File)
.wtitle (Set Window Title)
Control Keys
Control Keys
CTRL+\ (Debug Current Debugger)
CTRL+ALT+\ (Debug Current Debugger)
CTRL+A (Toggle Baud Rate)
CTRL+B (Quit Local Debugger)
CTRL+C (Break)
CTRL+D (Toggle Debug Info)
CTRL+F (Break to KD)
CTRL+K (Change Post-Reboot Break State)
CTRL+P (Debug Current Debugger)
 CTRL+R (Re-synchronize)
CTRL+V (Toggle Verbose Mode)
CTRL+W (Show Debugger Version)
General Extension Commands
General Extension Commands
!acl
!address
!analyze
!asd
!atom
!bitcount
!blackboxbsd
!blackboxscm
!chksym
!chkimg
!cppexr
!cpuid
!cs
!cxr
!dh
!dlls
!dml_proc
!dumpfa
!envvar
!error
!exchain
!exr
!findxmldata
!for_each_frame
!for_each_function
!for_each_local
!for_each_module
!for_each_register
!gflag
!gle
!gs
!handle
!heap
!help
!homedir
!hstring
!hstring2
!htrace
!imggp
!imgreloc
!kuser
!list
!lmi
!mui
!net_send
!obja
!owner
!peb
!rebase
!rtlavl
!sd
!sid
!slist
!std_map
!stl
!str
!sym
!symsrv
!teb
 !tls
!token
!tp
!triage
!ustr
!version
!winrterr
Kernel-Mode Extension Commands
Kernel-Mode Extension Commands
!ahcache
!alignmentfaults
!analyzebugcheck
!apc
!apicerr
!arbinst
!arbiter
!ate
!bcb
!blockeddrv
!bpid
!btb
!bth
!bugdump
!bushnd
!ca
!callback
!calldata
!can_write_kdump
!cbreg
!cchelp
!chklowmem
!cmreslist
!cpuinfo
!db, !dc, !dd, !dp, !dq, !du, !dw
!dbgprint
!dblink
!dcr
!dcs
!deadlock
!defwrites
!devext
!devhandles
!devnode
!devobj
!devstack
!dflink
!diskspace
!dma
!dpa
!dpcs
!driveinfo
!drivers
!drvobj
!dskheap
!eb, !ed
!ecb, !ecd, !ecw
!ecs
!errlog
!errpkt
!errrec
!exca
!filecache
!filelock
!fileobj
!filetime
!finddata
!findfilelockowner
!findthreads
!for_each_process
!for_each_thread
!fpsearch
!frozen
!fwver
!fxdevice
!gbl
!gentable
!hidppd
!ib, !id, !iw
!icpleak
!idt
!ih
!ihs
!ioresdes
!ioctldecode
!ioreslist
!iovirp
!ipi
!irp
!irpfind
!irpzone
!irql
!isainfo
!isr
!ivt
!job
!kb, !kv
!loadermemorylist
!lockedpages
!locks (!kdext*.locks)
!logonsession
!lookaside
!lpc
!mca
!memlist
!memusage
!mps
!mtrr
!npx
!ob, !od, !ow
!object
!obtrace
!openmaps
!pars
!pat
!pci
!pciir
!pcitree
!pcm
!pcr
!pcrs
!pfn
!pmc
!pmssa
!powertriage
!pnpevent
!pocaps
!pool
!poolfind
!poolused
!poolval
!popolicy
!pplookaside
!ppmidle
!ppmidleaccounting
!ppmidlepolicy
!ppmlpscenarios
!ppmperf
!ppmperfpolicy
!ppmsettings
!ppmstate
!prcb
!process
!processfields
!processirps
!psp
!pte
!pte2va
!ptov
!qlocks
!ready
!reg
!regkcb
!rellist
!ruleinfo
!running
!scm
!search
!searchpte
!sel
!session
!smt
!sprocess
!srb
!stacks
!swd
!sysinfo
!sysptes
!thread
!threadfields
!time
!timer
!tokenfields
!trap
!tss
!tz
!tzinfo
!ubc
!ubd
!ube
!ubl
!ubp
!urb
!vad
!vad_reload
!validatelist
!verifier
!vm
!vpb
!vpdd
!vtop
!wdmaud
!whattime
 !whatperftime
!whea
!wsle
!zombies
User-Mode Extension Commands
User-Mode Extension Commands
!avrf
!critsec
!dp (!ntsdexts.dp)
!dreg
!dt
!findstack
!gatom
!igrep
!locks (!ntsdexts.locks)
!mapped_file
!runaway
!threadtoken
!uniqstack
!vadump
!vprot
Specialized Extension Commands
Specialized Extension Commands
Storage Kernel Debugger Extensions
Storage Kernel Debugger Extensions
!storagekd.storadapter
!storagekd.storclass
!storagekd.storhelp
!storagekd.storlogirp
!storagekd.storloglist
!storagekd.storlogsrb
!storagekd.storsrb
 !storagekd.storunit
Bluetooth Extensions (Bthkd.dll)
Bluetooth Extensions (Bthkd.dll)
!bthkd.bthdevinfo
!bthkd.bthenuminfo
!bthkd.bthinfo
!bthkd.bthhelp
!bthkd.bthtree
!bthkd.bthusbtransfer
!bthkd.dibflags
!bthkd.hcicmd
!bthkd.hciinterface
!bthkd.l2capinterface
!bthkd.rfcomminfo
!bthkd.rfcommconnection
!bthkd.rfcommchannel
!bthkd.sdpinterface
!bthkd.scointerface
!bthkd.sdpnode
!bthkd.sdpstream
GPIO Extensions
GPIO Extensions
!gpiokd.help
!gpiokd.bankinfo
!gpiokd.clientlist
!gpiokd.gpioext
!gpiokd.pininfo
!gpiokd.pinisrvec
!gpiokd.pintable
USB 3.0 Extensions
USB 3.0 Extensions
USB 3.0 Data Structures
 !usb3kd.help
!usb3kd.device_info
!usb3kd.device_info_from_pdo
!usb3kd.dsf
!usb3kd.hub_info
!usb3kd.hub_info_from_fdo
!usb3kd.port_info
!usb3kd.ucx_device
!usb3kd.ucx_endpoint
!usb3kd.ucx_controller
!usb3kd.ucx_controller_list
!usb3kd.usbanalyze
!usb3kd.usbdstatus
!usb3kd.usb_tree
!usb3kd.urb
!usb3kd.xhci_capability
!usb3kd.xhci_commandring
!usb3kd.xhci_deviceslots
!usb3kd.xhci_dumpall
!usb3kd.xhci_eventring
!usb3kd.xhci_findowner
!usb3kd.xhci_info
!usb3kd.xhci_registers
!usb3kd.xhci_resourceusage
!usb3kd.xhci_trb
!usb3kd.xhci_transferring
USB 2.0 Debugger Extensions
USB 2.0 Debugger Extensions
!usbkd.usbhelp
!usbkd._ehcidd
!usbkd._ehciep
!usbkd._ehciframe
!usbkd._ehciqh
!usbkd._ehciregs
!usbkd._ehcisitd
!usbkd._ehcistq
!usbkd._ehcitd
!usbkd._ehcitfer
!usbkd._ehciitd
!usbkd.doesdumphaveusbdata
!usbkd.isthisdumpasyncissue
!usbkd.urbfunc
!usbkd.usb2
!usbkd.usb2tree
!usbkd.usbchain
!usbkd.usbdevobj
!usbkd.usbdpc
!usbkd.ehci_info_from_fdo
!usbkd.usbdevh
!usbkd.usbep
!usbkd.usbfaildata
!usbkd.usbhcdext
!usbkd.usbdstatus
!usbkd.usbhcdhccontext
!usbkd.usbhcdlist
!usbkd.usbhcdlistlogs
!usbkd.usbhcdlog
!usbkd.usbhcdlogex
!usbkd.usbhcdpnp
!usbkd.usbhcdpow
!usbkd.hub2_info_from_fdo
!usbkd.usbhuberr
!usbkd.usbhubext
!usbkd.usbhubinfo
 !usbkd.usbhublog
!usbkd.usbhubmddevext
!usbkd.usbhubmdpd
!usbkd.usbhubpd
!usbkd.usbhubs
!usbkd.usblist
!usbkd.usbpo
!usbkd.usbpdos
!usbkd.usbpdoxls
!usbkd.usbpnp
!usbkd.usbportisasyncadv
!usbkd.usbportmdportlog
!usbkd.usbportmddcontext
!usbkd.usbportmddevext
!usbkd.usbtriage
!usbkd.usbtt
!usbkd.usbtx
!usbkd.usbusb2ep
!usbkd.usbusb2tt
!usbkd.usbver
RCDRKD Extensions
RCDRKD Extensions
!rcdrkd.rcdrhelp
!rcdrkd.rcdrcrashdump
!rcdrkd.rcdrlogdump
!rcdrkd.rcdrloglist
!rcdrkd.rcdrlogsave
!rcdrkd.rcdrsearchpath
!rcdrkd.rcdrsettraceprefix
!rcdrkd.rcdrtmffile
!rcdrkd.rcdrtraceprtdebug
HID Extensions
 HID Extensions
!hidkd.help
!hidkd.hidfdo
!hidkd.hidpdo
!hidkd.hidtree
!hidkd.hidppd
!hidkd.hidrd
Logger Extensions (Logexts.dll)
Logger Extensions (Logexts.dll)
!logexts.help
!logexts.logb
!logexts.logc
!logexts.logd
!logexts.loge
!logexts.logi
!logexts.logm
!logexts.logo
NDIS Extensions (Ndiskd.dll)
NDIS Extensions (Ndiskd.dll)
!ndiskd.help
!ndiskd.netadapter
!ndiskd.minidriver
!ndiskd.rcvqueue
!ndiskd.protocol
!ndiskd.mopen
!ndiskd.filter
!ndiskd.filterdriver
!ndiskd.nbl
!ndiskd.nb
!ndiskd.nblpool
!ndiskd.nbpool
!ndiskd.pendingnbls
!ndiskd.nbllog
!ndiskd.oid
!ndiskd.interfaces
!ndiskd.ifprovider
!ndiskd.ifstacktable
!ndiskd.compartments
!ndiskd.pkt
!ndiskd.pktpools
!ndiskd.findpacket
!ndiskd.vc
!ndiskd.af
!ndiskd.ndisref
!ndiskd.ndisevent
!ndiskd.ndisstack
!ndiskd.wdiadapter
!ndiskd.wdiminidriver
!ndiskd.nwadapter
!ndiskd.ndisrwlock
!ndiskd.ndisslot
!ndiskd.ndis
!ndiskd.dbglevel
!ndiskd.dbgsystems
!ndiskd.ndiskdversion
!ndiskd.netreport
NDIS CX Extensions (Ndiskd.dll)
!ndiskd.cxadapter
!ndiskd.netqueue
!ndiskd.netrb
!ndiskd.netpacket
!ndiskd.netfragment
!ndiskd.nrc
!ndiskd.netring
RPC Extensions (Rpcexts.dll)
RPC Extensions (Rpcexts.dll)
!rpcexts.checkrpcsym
!rpcexts.eeinfo
!rpcexts.eerecord
!rpcexts.getcallinfo
!rpcexts.getclientcallinfo
!rpcexts.getdbgcell
!rpcexts.getendpointinfo
!rpcexts.getthreadinfo
!rpcexts.help
!rpcexts.rpcreadstack
!rpcexts.rpctime
!rpcexts.thread
ACPI Extensions (Acpikd.dll and Kdexts.dll)
ACPI Extensions (Acpikd.dll and Kdexts.dll)
!acpicache
!acpiinf
!acpiirqarb
!acpikd.help
!amli ?
!amli bc
!amli bd
!amli be
!amli bl
!amli bp
!amli cl
!amli debugger
!amli dh
!amli dl
!amli dns
!amli do
 !amli ds
!amli find
!amli lc
!amli ln
!amli r
!amli set
!amli u
!facs
!fadt
!mapic
!nsobj
!nstree
!rsdt
Kernel Streaming Extensions (Ks.dll)
Kernel Streaming Extensions (Ks.dll)
!ks.help
!ks.kshelp
!ks.pchelp
!ks.allstreams
!ks.automation
!ks.devhdr
!ks.dhdr
!ks.dump
!ks.dumpbag
!ks.dumpcircuit
!ks.dumplog
!ks.dumpqueue
!ks.enumdevobj
!ks.enumdrvobj
!ks.eval
!ks.findlive
!ks.forcedump
 !ks.graph
!ks.libexts
!ks.objhdr
!ks.ohdr
!ks.pciaudio
!ks.pciks
!ks.shdr
!ks.topology
SCSI Miniport Extensions (Scsikd.dll and Minipkd.dll)
SCSI Miniport Extensions (Scsikd.dll and Minipkd.dll)
!scsikd.help
!scsikd.classext
!scsikd.scsiext
!scsikd.srbdata
!minipkd.help
!minipkd.adapter
!minipkd.adapters
!minipkd.exports
!minipkd.lun
!minipkd.portconfig
!minipkd.req
!minipkd.srb
Windows Driver Framework Extensions (Wdfkd.dll)
Windows Driver Framework Extensions (Wdfkd.dll)
!wdfkd.help
!wdfkd.wdfchildlist
!wdfkd.wdfcollection
!wdfkd.wdfcommonbuffer
!wdfkd.wdfcrashdump
!wdfkd.wdfdevext
!wdfkd.wdfdevice
!wdfkd.wdfdeviceinterrupts
!wdfkd.wdfdevicequeues
!wdfkd.wdfdmaenabler
!wdfkd.wdfdmaenablers
!wdfkd.wdfdmatransaction
!wdfkd.wdfdriverinfo
!wdfkd.wdfextendwatchdog
!wdfkd.wdffindobjects
!wdfkd.wdfforwardprogress
!wdfkd.wdfgetdriver
!wdfkd.wdfhandle
!wdfkd.wdfhelp
!wdfkd.wdfinterrupt
!wdfkd.wdfiotarget
!wdfkd.wdfldr
!wdfkd.wdflogdump
!wdfkd.wdflogsave
!wdfkd.wdfmemory
!wdfkd.wdfobject
!wdfkd.wdfopenhandles
!wdfkd.wdfpool
!wdfkd.wdfpooltracker
!wdfkd.wdfpoolusage
!wdfkd.wdfqueue
!wdfkd.wdfrequest
!wdfkd.wdfsearchpath
!wdfkd.wdfsettraceprefix
!wdfkd.wdfsetdriver
!wdfkd.wdfspinlock
!wdfkd.wdftagtracker
!wdfkd.wdftmffile
!wdfkd.wdftraceprtdebug
!wdfkd.wdfumdevstack
 !wdfkd.wdfumdevstacks
!wdfkd.wdfumdownirp
!wdfkd.wdfumfile
!wdfkd.wdfumirp
!wdfkd.wdfumirps
!wdfkd_wdfumtriage
!wdfkd.wdfusbdevice
!wdfkd.wdfusbinterface
!wdfkd.wdfusbpipe
!wdfkd.wdfwmi
User-Mode Driver Framework Extensions (Wudfext.dll)
User-Mode Driver Framework Extensions (Wudfext.dll)
!wudfext.help
!wudfext.umdevstack
!wudfext.umdevstacks
!wudfext.umfile
!wudfext.umirp
!wudfext.umirps
!wudfext.wudfdevice
!wudfext.wudfdevicequeues
!wudfext.wudfdownkmirp
!wudfext.wudfdriverinfo
!wudfext.wudfdumpobjects
!wudfext.wudffile
!wudfext.wudffilehandletarget
!wudfext.wudfiotarget
!wudfext.wudfobject
!wudfext.wudfqueue
!wudfext.wudfrefhist
!wudfext.wudfrequest
!wudfext.wudfusbinterface
!wudfext.wudfusbpipe
 !wudfext.wudfusbtarget
WMI Tracing Extensions (Wmitrace.dll)
WMI Tracing Extensions (Wmitrace.dll)
!wmitrace.disable
!wmitrace.dumpmini
!wmitrace.dumpminievent
!wmitrace.dynamicprint
!wmitrace.enable
!wmitrace.eventlogdump
!wmitrace.help
!wmitrace.logdump
!wmitrace.logger
!wmitrace.logsave
!wmitrace.searchpath
!wmitrace.setprefix
!wmitrace.start
!wmitrace.stop
!wmitrace.strdump
!wmitrace.tfp
!wmitrace.tmffile
!wmitrace.traceoperation
Debugger-Related APIs
Debugger-Related APIs
Symbol Server API
The dbgeng.h Header File
The wdbgexts.h Header File
Debugger Error and Warning Messages
Debugger Error and Warning Messages
dbgerr001: PEB is Paged Out
dbgerr002: Bad Pointer
dbgerr003: Mismatched Symbols
dbgerr004: Page Not Present in Dump File
 dbgerr005: Private Symbols Required
Stack Unwind Information Not Available
No Header Information Available
WinDbg Graphical Interface Features
WinDbg Graphical Interface Features
File Menu
File Menu
File | Open Source File
File | Close Current Window
File | Open Executable
File | Attach to a Process
File | Open Crash Dump
File | Connect to Remote Session
File | Connect to Remote Stub
File | Kernel Debug
File | Symbol File Path
File | Source File Path
File | Image File Path
File | Open Workspace
File | Save Workspace
File | Save Workspace As
File | Clear Workspace
File | Delete Workspaces
File | Open Workspace in File
File | Save Workspace to File
File | Map Network Drive
File | Disconnect Network Drive
File | Recent Files
File | Exit
Edit Menu
Edit Menu
Edit | Cut
 Edit | Copy
Edit | Paste
Edit | Select All
Edit | Write Window Text to File
Edit | Add to Command Output
Edit | Clear Command Output
Edit | Evaluate Selection
Edit | Display Selected Type
Edit | Find
Edit | Find Next
Edit | Go to Address
Edit | Go to Line
Edit | Go to Current Instruction
Edit | Set Current Instruction
Edit | Breakpoints
Edit | Open/Close Log File
View Menu
View Menu
View | Command
View | Watch
View | Locals
View | Registers
View | Memory
View | Call Stack
View | Disassembly
View | Scratch Pad
View | Processes and Threads
View | Command Browser
View | Verbose Output
View | Show Version
View | Toolbar
View | Status Bar
 View | Font
View | Options
View | Source language file extensions
View | WinDbg Command Line
Debug Menu
Debug Menu
Debug | Go
Debug | Go Unhandled Exception
Debug | Go Handled Exception
Debug | Restart
Debug | Stop Debugging
Debug | Detach Debuggee
Debug | Break
Debug | Step Into
Debug | Step Over
Debug | Step Out
Debug | Run to Cursor
Debug | Source Mode
Debug | Resolve Unqualified Symbols
Debug | Event Filters
Debug | Modules
Debug | Kernel Connection | Cycle Baud Rate
Debug | Kernel Connection | Cycle Initial Break
Debug | Kernel Connection | Resynchronize
Window Menu
Window Menu
Window | Close All Source Windows
Window | Close All Error Windows
Window | Open Dock
Window | Dock All
Window | Undock All
Window | MDI Emulation
 Window | Automatically Open Disassembly
List of Open Windows
Help Menu
Help Menu
Help | Contents
Help | Index
Help | Search
Help | About
Toolbar Buttons
Keyboard Shortcuts
 Debugging Tools for Windows (WinDbg, KD, CDB,
NTSD)
11/2/2020 • 3 minutes to read • Edit Online

Start here for an overview of Debugging Tools for Windows. This tool set includes WinDbg and other
debuggers.

Install Debugging Tools for Windows

You can get Debugging Tools for Windows as part of a development kit or as a standalone tool set:
As par t of the WDK
Debugging Tools for Windows is included in the Windows Driver Kit (WDK). To get the WDK, see
Download the Windows Driver Kit (WDK).
As par t of the Windows SDK
Debugging Tools for Windows is included in the Windows Software Development Kit (SDK). To download
the installer or an ISO image, see Windows 10 SDK on Windows Dev Center.
As a standalone tool set
You can install the Debugging Tools for Windows alone, without the Windows SDK or WDK, by starting
installation of the Windows SDK and then selecting only Debugging Tools for Windows in the list of
features to install (and clearing the selection of all other features). To download the installer or an ISO
image, see Windows 10 SDK on Windows Dev Center.

Get started with Windows Debugging

To get started with Windows debugging, see Getting Started with Windows Debugging.
To get started with debugging kernel-mode drivers, see Debug Universal Drivers - Step by Step Lab (Echo
Kernel-Mode). This is a step-by-step lab that shows how to use WinDbg to debug Echo, a sample driver that
uses the Kernel-Mode Driver Framework (KMDF).

Debugging environments
If your computer has Visual Studio and the WDK installed, then you have six available debugging environments.
For descriptions of these environments, see Debugging Environments.
All of these debugging environments provide user interfaces for the same underlying debugging engine, which
is implemented in the Windows Symbolic Debugger Engine (Dbgeng.dll). This debugging engine is also called
the Windows debugger, and the six debugging environments are collectively called the Windows debuggers.

NOTE
Visual Studio includes its own debugging environment and debugging engine, which together are called the Visual Studio
debugger. For information on debugging in Visual Studio, see Debugging in Visual Studio. For debugging managed code,
such as C#, using the Visual Studio debugger is often the easiest way to get started.
Windows debuggers
The Windows debuggers can run on x86-based, x64-based, or ARM-based processors, and they can debug code
that is running on those same architectures. Sometimes the debugger and the code being debugged run on the
same computer, but other times the debugger and the code being debugged run on separate computers. In
either case, the computer that is running the debugger is called the host computer, and the computer that is
being debugged is called the target computer. The Windows debuggers support the following versions of
Windows for both the host and target computers.
Windows 10 and Windows Server 2016
Windows 8.1 and Windows Server 2012 R2
Windows 8 and Windows Server 2012
Windows 7 and Windows Server 2008 R2

Symbols and symbol files

Symbol files store a variety of data that are not required when running the executable binaries, but symbol files
are very useful when debugging code. For more information about creating and using symbol files, see Symbols
for Windows debugging (WinDbg, KD, CDB, NTSD).

Blue screens and crash dump files

If Windows stops working and displays a blue screen, the computer has shut down abruptly to protect itself
from data loss and displays a bug check code. For more information, see Bug Checks (Blue Screens). You analyze
crash dump files that are created when Windows shuts down by using WinDbg and other Windows debuggers.
For more information, see Crash dump analysis using the Windows debuggers (WinDbg).

Tools and utilities

In addition to the debuggers, Debugging Tools for Windows includes a set of tools that are useful for debugging.
For a full list of the tools, see Tools Included in Debugging Tools for Windows.

Additional documentation
For additional information related to Debugging Tools for Windows, see Debugging Resources. For information
on what's new in Windows 10, see Debugging Tools for Windows: New for Windows 10.
 Download Debugging Tools for Windows
6/16/2021 • 2 minutes to read • Edit Online

The Windows Debugger (WinDbg) can be used to debug kernel-mode and user-mode code, analyze crash
dumps, and examine the CPU registers while the code executes.
To get started with Windows debugging, see Getting Started with Windows Debugging.

Download WinDbg Preview

WinDbg Preview is a new version of WinDbg with more modern visuals, faster windows, and a full-fledged
scripting experience. It is built with the extensible object-orientated debugger data model front and center.
WinDbg Preview is using the same underlying engine as WinDbg today, so all the commands, extensions, and
workflows still work as they did before.
Download WinDbg Preview from the Microsoft Store: WinDbg Preview.
Learn more about installation and configuration in WinDbg Preview - Installation.

Debugging Tools for Windows 10 (WinDbg)

Get Debugging Tools for Windows (WinDbg) from the SDK: Windows 10 SDK. Use the download link on the
Windows 10 SDK page, as the Debugging Tools for Windows are not available as part of Visual Studio.
If you just need the Debugging Tools for Windows, and not the Windows Driver Kit (WDK) for Windows 10, you
can install the debugging tools as a standalone component from the Windows Software Development Kit (SDK).
In the SDK installation wizard, select Debugging Tools for Windows , and deselect all other components.

Adding the Debugging Tools for Windows if the SDK is already installed
If the Windows SDK is already installed, open Settings , navigate to Apps & features , select Windows
Software Development Kit , and then select Modify to change the installation to add Debugging Tools for
Windows .

Looking for the debugging tools for earlier versions of Windows?

To download the debugger tools for previous versions of Windows, you need to download the Windows SDK for
the version you are debugging from the Windows SDK and emulator archive. In the installation wizard of the
SDK, select Debugging Tools for Windows , and deselect all other components.

Learn more about the debuggers

Learn more about WinDbg and other debuggers in Debugging Tools for Windows (WinDbg, KD, CDB, NTSD).

Looking for related downloads?

Download the Windows Driver Kit (WDK)
Windows Symbol Packages
Windows Hardware Lab Kit
Download and install the Windows Assessment and Deployment Kit (Windows ADK)
Windows Insider - Windows Preview builds
 Windows Symbol Packages
11/2/2020 • 2 minutes to read • Edit Online

Symbol files make it easier to debug your code. The easiest way to get Windows symbols is to use the Microsoft
public symbol server. The symbol server makes symbols available to your debugging tools as needed. After a
symbol file is downloaded from the symbol server it is cached on the local computer for quick access.

Symbol package deprecation

IMPORTANT
We are no longer publishing the offline symbol packages for Windows.
With the cadence that we release updates for Windows, the Windows debugging symbols we publish via the packages on
this page are quickly made out of date. We have made significant improvements to the online Microsoft Symbol Server by
moving this to be an Azure-based symbol store, and symbols for all Windows versions and updates are available there.
You can find more about this in this blog entry.
For information on how to retrieve symbols for a machine that is not connected to the Internet, see Using a Manifest File
with SymChk.

Symbol Resources and Feedback

To learn more about using symbols and debugging, see Symbols and Symbol Files.
For help with debugging issues, see Debugging Resources.
We are interested in your feedback about symbols. Please mail suggestions or bug reports to
[email protected]. Technical support is not available from this address, but your feedback will help us to
plan future changes for symbols and will make them more useful to you in the future.

Looking for related downloads?

Download Windows Debugging Tools
Download the Windows Driver Kit (WDK)
Download the Windows Assessment and Deployment Kit (Windows ADK)
Download the Windows HLK, HCK, or Logo Kit
Download Windows Insider Preview builds
 Getting Started with Windows Debugging
6/16/2021 • 5 minutes to read • Edit Online

This article covers how to get started with Windows Debugging. If your goal is to use the debugger to analyze a
crash dump, see Analyze crash dump files by using WinDbg.
To get started with Windows Debugging, complete the tasks that are described in this article.

1. Determine the host and the target

The debugger runs on the host system, and the code that you want to debug runs on the target system.
Host <--------------------------------------------------> Target

Because it is common to stop instruction execution on the processor during debugging, two computer systems
are typically used. In some situations, you might be able to use a virtual machine as the second system. For
example, you might be able to use a virtual PC that is running on the same PC as the code that you need to
debug. However, if your code is communicating to low-level hardware, using a virtual PC may not be the best
approach. For more information, see Setting up network debugging of a virtual machine - KDNET.

2. Determine the type: kernel-mode or user-mode

Next, you need to determine whether you will do kernel-mode or user-mode debugging.
Kernel mode is the processor-access mode in which the operating system and privileged programs run. Kernel-
mode code has permission to access any part of the system, and it is not restricted like user-mode code. Kernel-
mode code can gain access to any part of any other process running in either user mode or kernel mode. Much
of the core OS functionality and many hardware device drivers run in kernel mode.
User mode is the mode that applications and subsystems on the computer run in. Processes that run in user
mode do so within their own virtual address spaces. They are restricted from gaining direct access to many
parts of the system, including system hardware, memory that was not allocated for their use, and other portions
of the system that might compromise system integrity. Because processes that run in user mode are effectively
isolated from the system and other user-mode processes, they cannot interfere with these resources.
If your goal is to debug a driver, determine if the driver is a kernel-mode driver or a user-mode driver. Windows
Driver Model (WDM) drivers and Kernel-Mode Driver Framework (KMDF) are both kernel-mode drivers. As the
name sugests, User-Mode Driver Framework (UMDF) drivers are user-mode drivers.
For some issues, it can be difficult to determine which mode the code executes in. In that case, you may need to
pick one mode and look to see what information is available in that mode. Some issues require using the
debugger in both user mode and kernel mode.
Depending on what mode you decide to debug in, you will need to configure and use the debuggers in different
ways. Some debugging commands operate the same in both modes, and some commands operate differently in
different modes.
For information about using the debugger in kernel mode, see the following articles:
 Getting started with WinDbg (kernel-mode)
Debug universal drivers - step by step lab (echo kernel-mode)
Debug drivers - step by step lab (Sysvad kernel-mode).
For information about using the debugger in user mode, see Getting started with WinDbg (user-mode).

3. Choose your debugger environment

WinDbg works well in most situations, but there are times when you may want to use another debugger, such as
console debuggers for automation or Visual Studio. For more information, see Debugging environments.

4. Determine how to connect the target and host

Typically, target and host systems are connected by an Ethernet network. If you are doing early bring-up work,
or you don't have an Ethernet connection on a device, other network connection options are available. For more
information, see these articles:
Setting up KDNET network kernel debugging automatically
Setting up kernel-mode debugging
Setting up KDNET network kernel debugging manually
Setting up network debugging of a virtual machine - KDNET

5. Choose either the 32-bit or 64-bit debugging tools

Which debugging tools to choose—32-bit or 64-bit—depends on the version of Windows that is running on the
target and host systems and on whether you are debugging 32-bit or 64-bit code. For more information, see
Choosing the 32-Bit or 64-Bit debugging tools.

6. Configure symbols
To use all of the advanced functionality that WinDbg provides, you must load the proper symbols. If you do not
have symbols properly configured, you will receive messages indicating that symbols are not available when
you attempt to use functionality that is dependent on symbols. For more information, see Symbols for Windows
debugging (WinDbg, KD, CDB, NTSD).

7. Configure source code

If your goal is to debug your own source code, you will need to configure a path to your source code. For more
information, see Source path.

8. Become familiar with debugger operation

The Debugger operation section of this documentation describes debugger operation for various tasks. For
example, Loading debugger extension DLLs explains how to load debugger extensions. To learn more about
working with WinDbg, see Debugging using WinDbg.

9. Become familiar with debugging techniques

Standard debugging techniques apply to most debugging scenarios, and examples include setting breakpoints,
inspecting the call stack, and finding a memory leak. Specialized debugging techniques apply to particular
technologies or types of code. Examples include Plug and Play debugging, KMDF debugging, and RPC
debugging.
10. Use the debugger reference commands
Over time, you will use different debugging commands as you work in the debugger. Use the .hh (open HTML
help file) command in the debugger to display help information about any debugging command. For more
information about the available commands, see Debugger reference.

11. Use debugging extensions for specific technologies

There are multiple debugging extensions that provide parsing of domain-specific data structures. For more
information, see Specialized extensions.

12. Learn about related Windows internals

This documentation assumes a knowledge of Windows internals. To learn more about Windows internals
(including memory usage, context, threads, and processes), review additional resources, such as Windows
Internals by Mark Russinovich, David Solomon, and Alex Ionescu.

13. Review additional debugging resources

Additional resources include the following books and videos:
Inside Windows Debugging: Practical Debugging and Tracing Strategies by Tarik Soulami
Advanced Windows Debugging by Mario Hewardt and Daniel Pravat
Defrag Tools, episodes 13 through 29, about WinDbg

See also
Getting started with WinDbg (kernel-mode)
Getting started with WinDbg (user-mode)
Choosing the 32-Bit or 64-Bit debugging tools
Debugging environments
Setting up debugging (kernel-mode and user-mode)
Debug universal drivers - step by step lab (echo kernel-mode)
Debug drivers - step by step lab (Sysvad kernel-mode)
 Getting Started with WinDbg (User-Mode)
6/16/2021 • 6 minutes to read • Edit Online

WinDbg is a kernel-mode and user-mode debugger that is included in Debugging Tools for Windows. Here we
provide hands-on exercises that will help you get started using WinDbg as a user-mode debugger.
For information about how to get Debugging Tools for Windows, see Debugging Tools for Windows (WinDbg,
KD, CDB, NTSD).
After you have installed the debugging tools, locate the installation directories for 64-bit (x64) and 32-bit (x86)
versions of the tools. For example:
C:\Program Files (x86)\Windows Kits\10\Debuggers\x64
C:\Program Files (x86)\Windows Kits\10\Debuggers\x86

Launch Notepad and attach WinDbg

1. Navigate to your installation directory, and open WinDbg.exe.
2. On the File menu, choose Open Executable . In the Open Executable dialog box, navigate to the folder
that contains notepad.exe (typically, C:\Windows\System32). For File name , enter notepad.exe. Select
Open .
3. Near the bottom of the WinDbg window, in the command line, enter this command:
.sympath srv*
The output is similar to this:

Symbol search path is: srv*

Expanded Symbol search path is: cache*;SRV

The symbol search path tells WinDbg where to look for symbol (PDB) files. The debugger needs symbol
files to obtain information about code modules (function names, variable names, and the like).
Enter this command, which tells WinDbg to do its initial finding and loading of symbol files:
.reload
4. To see the symbols for the Notepad.exe module, enter this command:
x notepad!*
Note If you don't see any output, enter .reload again.
To see symbols in the Notepad.exe module that contain main, use the examine symbols command like
this to list modules that match the mask:
x notepad!wWin*

The output is similar to this:

00007ff6`6e76b0a0 notepad!wWinMain (wWinMain)

00007ff6`6e783db0 notepad!wWinMainCRTStartup (wWinMainCRTStartup)

5. To put a breakpoint at notepad!wWinMain, enter this command:

bu notepad!wWinMain
To verify that your breakpoint was set, enter this command:
bl
The output is similar to this:

0 e Disable Clear 00007ff6`6e76b0a0 0001 (0001) 0:**** notepad!wWinMain

6. To start Notepad running, enter this command:

g
Notepad runs until it comes to the WinMain function, and then breaks in to the debugger.

Breakpoint 0 hit
notepad!wWinMain:
00007ff6`6e76b0a0 488bc4 mov rax,rsp

To see a list of code modules that are loaded in the Notepad process, enter this command:
lm
The output is similar to this:
 0:000> lm
start end module name
00007ff6`6e760000 00007ff6`6e798000 notepad (pdb symbols)
C:\ProgramData\Dbg\sym\notepad.pdb\BC04D9A431EDE299D4625AD6201C8A4A1\notepad.pdb
00007ff8`066a0000 00007ff8`067ab000 gdi32full (deferred)
00007ff8`067b0000 00007ff8`068b0000 ucrtbase (deferred)
00007ff8`06a10000 00007ff8`06aad000 msvcp_win (deferred)
00007ff8`06ab0000 00007ff8`06ad2000 win32u (deferred)
00007ff8`06b40000 00007ff8`06e08000 KERNELBASE (deferred)
00007ff8`07220000 00007ff8`072dd000 KERNEL32 (deferred)
00007ff8`07420000 00007ff8`07775000 combase (deferred)
00007ff8`07820000 00007ff8`079c0000 USER32 (deferred)
00007ff8`079c0000 00007ff8`079f0000 IMM32 (deferred)
00007ff8`07c00000 00007ff8`07c2a000 GDI32 (deferred)
00007ff8`08480000 00007ff8`085ab000 RPCRT4 (deferred)
00007ff8`085b0000 00007ff8`0864e000 msvcrt (deferred)
00007ff8`08c40000 00007ff8`08cee000 shcore (deferred)
00007ff8`08db0000 00007ff8`08fa5000 ntdll (pdb symbols)
C:\ProgramData\Dbg\sym\ntdll.pdb\53F12BFE149A2F50205C8D5D66290B481\ntdll.pdb
00007fff`f8580000 00007fff`f881a000 COMCTL32 (deferred)

To see a stack trace, enter this command:

k
The output is similar to this:

0:000> k
00 000000c8`2647f708 00007ff6`6e783d36 notepad!wWinMain
01 000000c8`2647f710 00007ff8`07237034 notepad!__scrt_common_main_seh+0x106
02 000000c8`2647f750 00007ff8`08e02651 KERNEL32!BaseThreadInitThunk+0x14
03 000000c8`2647f780 00000000`00000000 ntdll!RtlUserThreadStart+0x21

7. To start Notepad running again, enter this command:

g
8. To break in to Notepad, choose Break from the File menu.
9. To set and verify a breakpoint at ZwWriteFile , enter these commands:
bu ntdll!ZwWriteFile
bl
10. Enter g to start Notepad running again. In the Notepad window, enter some text and choose Save from
the File menu. The running code breaks in when it comes to ZwCreateFile . Enter k to see the stack trace.
 In the WinDbg window, just to the left of the command line, notice the processor and thread numbers. In
this example the current processor number is 0, and the current thread number is 11. So we are looking
at the stack trace for thread 11 (which happens to be running on processor 0).
11. To see a list of all threads in the Notepad process, enter this command (the tilde):
~
The output is similar to this:

0:011> ~
0 Id: 5500.34d8 Suspend: 1 Teb: 000000c8`262c4000 Unfrozen
1 Id: 5500.3960 Suspend: 1 Teb: 000000c8`262c6000 Unfrozen
2 Id: 5500.5d68 Suspend: 1 Teb: 000000c8`262c8000 Unfrozen
3 Id: 5500.4c90 Suspend: 1 Teb: 000000c8`262ca000 Unfrozen
4 Id: 5500.4ac4 Suspend: 1 Teb: 000000c8`262cc000 Unfrozen
5 Id: 5500.293c Suspend: 1 Teb: 000000c8`262ce000 Unfrozen
6 Id: 5500.53a0 Suspend: 1 Teb: 000000c8`262d0000 Unfrozen
7 Id: 5500.3ca4 Suspend: 1 Teb: 000000c8`262d4000 Unfrozen
8 Id: 5500.808 Suspend: 1 Teb: 000000c8`262da000 Unfrozen
10 Id: 5500.3940 Suspend: 1 Teb: 000000c8`262dc000 Unfrozen
. 11 Id: 5500.28b0 Suspend: 1 Teb: 000000c8`262de000 Unfrozen
12 Id: 5500.12bc Suspend: 1 Teb: 000000c8`262e0000 Unfrozen
13 Id: 5500.4c34 Suspend: 1 Teb: 000000c8`262e2000 Unfrozen

In this example, there are 14 threads with indexes 0 through 13.

12. To look at the stack trace for thread 0, enter these commands:
~0s
k
The output is similar to this:
 0:011> ~0s
0:011> ~0s
win32u!NtUserGetProp+0x14:
00007ff8`06ab1204 c3 ret
0:000> k
# Child-SP RetAddr Call Site
00 000000c8`2647bd08 00007ff8`07829fe1 win32u!NtUserGetProp+0x14
01 000000c8`2647bd10 00007fff`f86099be USER32!GetPropW+0xd1
02 000000c8`2647bd40 00007ff8`07d12f4d COMCTL32!DefSubclassProc+0x4e
03 000000c8`2647bd90 00007fff`f8609aba SHELL32!CAutoComplete::_EditWndProc+0xb1
04 000000c8`2647bde0 00007fff`f86098b7 COMCTL32!CallNextSubclassProc+0x9a
05 000000c8`2647be60 00007ff8`0782e858 COMCTL32!MasterSubclassProc+0xa7
06 000000c8`2647bf00 00007ff8`0782de1b USER32!UserCallWinProcCheckWow+0x2f8
07 000000c8`2647c090 00007ff8`0782d68a USER32!SendMessageWorker+0x70b
08 000000c8`2647c130 00007ff8`07afa4db USER32!SendMessageW+0xda

13. To quit debugging and detach from the Notepad process, enter this command:
qd

Launch your own application and attach WinDbg

Suppose you have written and built this small console application.

...
void MyFunction(long p1, long p2, long p3)
{
long x = p1 + p2 + p3;
long y = 0;
y = x / p2;
}

void main ()
{
long a = 2;
long b = 0;
MyFunction(a, b, 5);
}

For this exercise, we will assume that the built application (MyApp.exe) and the symbol file (MyApp.pdb) are in
C:\MyApp\x64\Debug. We will also assume that the application source code is in C:\MyApp\MyApp and that the
target machine compiled MyApp.exe.
1. Open WinDbg.
2. On the File menu, choose Open Executable . In the Open Executable dialog box, navigate to
C:\MyApp\x64\Debug. For File name , enter MyApp.exe. Select Open .
3. Enter these commands:
.symfix
.sympath+ C:\MyApp\x64\Debug
Now WinDbg knows where to find symbols and source code for your application. In this case, the source
code location doesn't need to be set with .srcpath because the symbols have fully qualified paths to the
source files.
4. Enter these commands:
.reload
 bu MyApp!main
g
Your application breaks in to the debugger when it comes to its main function.
WinDbg displays your source code and the Command window.

5. On the Debug menu, choose Step Into (or press F11 ). Continue stepping until you have stepped into
MyFunction . When you step into the line y = x / p2 , your application will crash and break in to the
debugger. The output is similar to this:

(1450.1424): Integer divide-by-zero - code c0000094 (first chance)

First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
MyApp!MyFunction+0x44:
00007ff6`3be11064 f77c2428 idiv eax,dword ptr [rsp+28h] ss:00000063`2036f808=00000000

6. Enter this command:

!analyze -v
WinDbg displays an analysis of the problem (division by 0 in this case).
 FAULTING_IP:
MyApp!MyFunction+44 [c:\myapp\myapp\myapp.cpp @ 7]
00007ff6`3be11064 f77c2428 idiv eax,dword ptr [rsp+28h]

EXCEPTION_RECORD: ffffffffffffffff -- (.exr 0xffffffffffffffff)

ExceptionAddress: 00007ff63be11064 (MyApp!MyFunction+0x0000000000000044)
ExceptionCode: c0000094 (Integer divide-by-zero)
ExceptionFlags: 00000000
NumberParameters: 0
...
STACK_TEXT:
00000063`2036f7e0 00007ff6`3be110b8 : ... : MyApp!MyFunction+0x44
00000063`2036f800 00007ff6`3be1141d : ... : MyApp!main+0x38
00000063`2036f840 00007ff6`3be1154e : ... : MyApp!__tmainCRTStartup+0x19d
00000063`2036f8b0 00007ffc`b1cf16ad : ... : MyApp!mainCRTStartup+0xe
00000063`2036f8e0 00007ffc`b1fc4629 : ... : KERNEL32!BaseThreadInitThunk+0xd
00000063`2036f910 00000000`00000000 : ... : ntdll!RtlUserThreadStart+0x1d

STACK_COMMAND: dt ntdll!LdrpLastDllInitializer BaseDllName ;dt ntdll!LdrpFailureData ;.cxr 0x0 ;kb

FOLLOWUP_IP:
MyApp!MyFunction+44 [c:\myapp\myapp\myapp.cpp @ 7]
00007ff6`3be11064 f77c2428 idiv eax,dword ptr [rsp+28h]

FAULTING_SOURCE_LINE: c:\myapp\myapp\myapp.cpp

FAULTING_SOURCE_FILE: c:\myapp\myapp\myapp.cpp

FAULTING_SOURCE_LINE_NUMBER: 7

FAULTING_SOURCE_CODE:
3: void MyFunction(long p1, long p2, long p3)
4: {
5: long x = p1 + p2 + p3;
6: long y = 0;
> 7: y = x / p2;
8: }
9:
10: void main ()
11: {
12: long a = 2;
...

Summary of commands
Contents command on the Help menu
.sympath (Set Symbol Path)
.reload (Reload Module)
x (Examine Symbols)
g (Go)
Break command on the Debug menu
lm (List Loaded Modules)
k (Display Stack Backtrace)
bu (Set Breakpoint)
bl (Breakpoint List)
~ (Thread Status)
~s (Set Current Thread)
.sympath+ (Set Symbol Path) append to existing symbol path
.srcpath (Set Source Path)
 Step Into command on the Debug menu (F11 )
!analyze -v
qd (Quit and Detach)

See also
Getting Started with WinDbg (Kernel-Mode)
Debugger Operation
Debugging Techniques
Debugging Tools for Windows (WinDbg, KD, CDB, NTSD)
Debugging Using WinDbg Preview
 Getting Started with WinDbg (Kernel-Mode)
6/16/2021 • 8 minutes to read • Edit Online

WinDbg is a kernel-mode and user-mode debugger that is included in Debugging Tools for Windows. Here we
provide hands-on exercises that will help you get started using WinDbg as a kernel-mode debugger.
For information about how to get Debugging Tools for Windows, see Debugging Tools for Windows (WinDbg,
KD, CDB, NTSD). After you have installed the debugging tools, locate the installation directories for 64-bit (x64)
and 32-bit (x86) versions of the tools. For example:
C:\Program Files (x86)\Windows Kits\10\Debuggers\x64
C:\Program Files (x86)\Windows Kits\10\Debuggers\x86

Set up a kernel-mode debugging

A kernel-mode debugging environment typically has two computers: the host computer and the target
computer. The debugger runs on the host computer, and the code being debugged runs on the target computer.
The host and target are connected by a debug cable.
The Windows debuggers support these types of cables for debugging:
Ethernet
USB 2.0 / USB 3.0
Serial (also called null modem)
For speed and reliablity, using Ethernet with a local network hub, is recommended. This diagram illustrates a
host and target computer connected for debugging over Ethernet cable.

Another option for older versions of Windows is to use a direct cable such as USB or serial cable.

For details about how to set up the host and target computers, see Setting Up Kernel-Mode Debugging
Manually.
Virtual Machine - VMs
For information on connecting a debugger to a Hyper-V virtual machine, see Setting Up Network Debugging of
a Virtual Machine - KDNET.

Establish a kernel-mode debugging session

After you have set up your host and target computer and connected them with a debug cable, you can establish
a kernel-mode debugging session by following the instructions in the same topic that you used for getting set
up. For example, if you decided to set up your host and target computers for debugging over Ethernet, you can
find instructions for establishing a kernel-mode debugging session is this topic:
Setting Up KDNET Network Kernel Debugging Automatically

Get started using WinDbg

1. On the host computer, open WinDbg and establish a kernel-mode debugging session with the target
computer.
2. In WinDbg, choose Contents from the Help menu. This opens the debugger documentation CHM file.
The debugger documentation is also available on line in Debugging Tools for Windows.
3. When you establish a kernel-mode debugging session, WinDbg might break in to the target computer
automatically. If WinDbg has not already broken in, choose Break from the Debug menu.
4. Near the bottom of the WinDbg window, in the command line, enter this command:
.sympath sr v*
The output is similar to this:

Symbol search path is: srv*

Expanded Symbol search path is: cache*;SRV*https://msdl.microsoft.com/download/symbols

The symbol search path tells WinDbg where to look for symbol (PDB) files. The debugger needs symbol
files to obtain information about code modules (function names, variable names, and the like).
Enter this command, which tells WinDbg to do its initial finding and loading of symbol files:
.reload
5. To see a list of loaded modules, enter this command:
lm
The output is similar to this:

0:000>3: kd> lm
start end module name
fffff800`00000000 fffff800`00088000 CI (deferred)
...
fffff800`01143000 fffff800`01151000 BasicRender (deferred)
fffff800`01151000 fffff800`01163000 BasicDisplay (deferred)
...
fffff800`02a0e000 fffff800`03191000 nt (pdb symbols) C:\...\ntkrnlmp.pdb
fffff800`03191000 fffff800`03200000 hal (deferred)
...

6. To start target computer running, enter this command:

g
7. To break in again, choose Break from the Debug menu.
8. Enter this command to examine the _FILE_OBJECT data type in the nt module:
dt nt!_FILE_OBJECT
The output is similar to this:
 0:000>0: kd> dt nt!_FILE_OBJECT
+0x000 Type : Int2B
+0x002 Size : Int2B
+0x008 DeviceObject : Ptr64 _DEVICE_OBJECT
+0x010 Vpb : Ptr64 _VPB
...
+0x0c0 IrpList : _LIST_ENTRY
+0x0d0 FileObjectExtension : Ptr64 Void

9. Enter this command to examine some of the symbols in the nt module:

x nt!*CreateProcess*
The output is similar to this:

0:000>0: kd> x nt!*CreateProcess*

fffff800`030821cc nt!ViCreateProcessCallbackInternal (<no parameter info>)
...
fffff800`02e03904 nt!MmCreateProcessAddressSpace (<no parameter info>)
fffff800`02cece00 nt!PspCreateProcessNotifyRoutine = <no type information>
...

10. Enter this command to put a breakpoint at MmCreateProcessAddressSpace :

bu nt!MmCreateProcessAddressSpace
To verify that the breakpoint is set, enter this command:
bl
The output is similar to this:

0:000>0: kd> bu nt!MmCreateProcessAddressSpace

0: kd> bl
0 e fffff800`02e03904 0001 (0001) nt!MmCreateProcessAddressSpace

Enter g to let the target computer run.

11. If the target computer doesn't break in to the debugger immediately, perform a few actions on the target
computer (for example, open Notepad). The target computer will break in to the debugger when
MmCreateProcessAddressSpace is called. To see the stack trace, enter these commands:
.reload
k
The output is similar to this:

0:000>2: kd> k
Child-SP RetAddr Call Site
ffffd000`224b4c88 fffff800`02d96834 nt!MmCreateProcessAddressSpace
ffffd000`224b4c90 fffff800`02dfef17 nt!PspAllocateProcess+0x5d4
ffffd000`224b5060 fffff800`02b698b3 nt!NtCreateUserProcess+0x55b
...
000000d7`4167fbb0 00007ffd`14b064ad KERNEL32!BaseThreadInitThunk+0xd
000000d7`4167fbe0 00000000`00000000 ntdll!RtlUserThreadStart+0x1d

12. On the View menu, choose Disassembly .

On the Debug menu, choose Step Over (or press F10 ). Enter step commands a few more times as you
 watch the Disassembly window.
13. Clear your breakpoint by entering this command:
bc *
Enter g to let the target computer run. Break in again by choosing Break from the Debug menu or
pressing CTRL-Break .
14. To see a list of all processes, enter this command:
!process 0 0
The output is similar to this:

0:000>0: kd> !process 0 0

**** NT ACTIVE PROCESS DUMP ****
PROCESS ffffe000002287c0
SessionId: none Cid: 0004 Peb: 00000000 ParentCid: 0000
DirBase: 001aa000 ObjectTable: ffffc00000003000 HandleCount: <Data Not Accessible>
Image: System

PROCESS ffffe00001e5a900
SessionId: none Cid: 0124 Peb: 7ff7809df000 ParentCid: 0004
DirBase: 100595000 ObjectTable: ffffc000002c5680 HandleCount: <Data Not Accessible>
Image: smss.exe
...
PROCESS ffffe00000d52900
SessionId: 1 Cid: 0910 Peb: 7ff669b8e000 ParentCid: 0a98
DirBase: 3fdba000 ObjectTable: ffffc00007bfd540 HandleCount: <Data Not Accessible>
Image: explorer.exe

15. Copy the address of one process, and enter this command:
!process Address 2
For example: !process ffffe00000d5290 2
The output shows the threads in the process.

0:000>0:000>0: kd> !process ffffe00000d52900 2

PROCESS ffffe00000d52900
SessionId: 1 Cid: 0910 Peb: 7ff669b8e000 ParentCid: 0a98
DirBase: 3fdba000 ObjectTable: ffffc00007bfd540 HandleCount:
Image: explorer.exe

THREAD ffffe00000a0d880 Cid 0910.090c Teb: 00007ff669b8c000

ffffe00000d57700 SynchronizationEvent

THREAD ffffe00000e48880 Cid 0910.0ad8 Teb: 00007ff669b8a000

ffffe00000d8e230 NotificationEvent
ffffe00000cf6870 Semaphore Limit 0xffff
ffffe000039c48c0 SynchronizationEvent
...
THREAD ffffe00000e6d080 Cid 0910.0cc0 Teb: 00007ff669a10000
ffffe0000089a300 QueueObject

16. Copy the address of one thread, and enter this command:
!thread Address
For example: !thread ffffe00000e6d080
The output shows information about the individual thread.
 0: kd> !thread ffffe00000e6d080
THREAD ffffe00000e6d080 Cid 0910.0cc0 Teb: 00007ff669a10000 Win32Thread: 0000000000000000 WAIT: ...
ffffe0000089a300 QueueObject
Not impersonating
DeviceMap ffffc000034e7840
Owning Process ffffe00000d52900 Image: explorer.exe
Attached Process N/A Image: N/A
Wait Start TickCount 13777 Ticks: 2 (0:00:00:00.031)
Context Switch Count 2 IdealProcessor: 1
UserTime 00:00:00.000
KernelTime 00:00:00.000
Win32 Start Address ntdll!TppWorkerThread (0x00007ffd14ab2850)
Stack Init ffffd00021bf1dd0 Current ffffd00021bf1580
Base ffffd00021bf2000 Limit ffffd00021bec000 Call 0
Priority 13 BasePriority 13 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5
...

17. To see all the device nodes in the Plug and Play device tree, enter this command:
!devnode 0 1

0:000>0: kd> !devnode 0 1

Dumping IopRootDeviceNode (= 0xffffe000002dbd30)
DevNode 0xffffe000002dbd30 for PDO 0xffffe000002dc9e0
InstancePath is "HTREE\ROOT\0"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
DevNode 0xffffe000002d9d30 for PDO 0xffffe000002daa40
InstancePath is "ROOT\volmgr\0000"
ServiceName is "volmgr"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
DevNode 0xffffe00001d49290 for PDO 0xffffe000002a9a90
InstancePath is "STORAGE\Volume\{3007dfd3-df8d-11e3-824c-806e6f6e6963}#0000000000100000"
ServiceName is "volsnap"
TargetDeviceNotify List - f 0xffffc0000031b520 b 0xffffc0000008d0f0
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeStartPostWork (0x307)
...

18. To see the device nodes along with their hardware resources, enter this command:
!devnode 0 9

0:000>...
DevNode 0xffffe000010fa770 for PDO 0xffffe000010c2060
InstancePath is "PCI\VEN_8086&DEV_2937&SUBSYS_2819103C&REV_02\3&33fd14ca&0&D0"
ServiceName is "usbuhci"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
TranslatedResourceList at 0xffffc00003c78b00 Version 1.1 Interface 0x5 Bus #0
Entry 0 - Port (0x1) Device Exclusive (0x1)
Flags (0x131) - PORT_MEMORY PORT_IO 16_BIT_DECODE POSITIVE_DECODE
Range starts at 0x3120 for 0x20 bytes
Entry 1 - DevicePrivate (0x81) Device Exclusive (0x1)
Flags (0000) -
Data - {0x00000001, 0x00000004, 0000000000}
Entry 2 - Interrupt (0x2) Shared (0x3)
Flags (0000) - LEVEL_SENSITIVE
Level 0x8, Vector 0x81, Group 0, Affinity 0xf
...

19. To see a device node that has a service name of disk, enter this command:
 !devnode 0 1 disk

0: kd> !devnode 0 1 disk

Dumping IopRootDeviceNode (= 0xffffe000002dbd30)
DevNode 0xffffe0000114fd30 for PDO 0xffffe00001159610
InstancePath is "IDE\DiskST3250820AS_____________________________3.CHL___\5&14544e82&0&0.0.0"
ServiceName is "disk"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
...

20. The output of !devnode 0 1 displays the address of the physical device object (PDO) for the node. Copy
the address of a physical device object (PDO), and enter this command:
!devstack PdoAddress
For example: PdoAddress!devstack 0xffffe00001159610

0:000>0: kd> !devstack 0xffffe00001159610

!DevObj !DrvObj !DevExt ObjectName
ffffe00001d50040 \Driver\partmgr ffffe00001d50190
ffffe00001d51450 \Driver\disk ffffe00001d515a0 DR0
ffffe00001156e50 \Driver\ACPI ffffe000010d8bf0

21. To get information about the driver disk.sys, enter this command:
!dr vobj disk 2

0:000>0: kd> !drvobj disk 2

Driver object (ffffe00001d52680) is for:
\Driver\disk
DriverEntry: fffff800006b1270 disk!GsDriverEntry
DriverStartIo: 00000000
DriverUnload: fffff800010b0b5c CLASSPNP!ClassUnload
AddDevice: fffff800010aa110 CLASSPNP!ClassAddDevice

Dispatch routines:
[00] IRP_MJ_CREATE fffff8000106d160 CLASSPNP!ClassGlobalDispatch
[01] IRP_MJ_CREATE_NAMED_PIPE fffff80002b0ab24 nt!IopInvalidDeviceRequest
[02] IRP_MJ_CLOSE fffff8000106d160 CLASSPNP!ClassGlobalDispatch
[03] IRP_MJ_READ fffff8000106d160 CLASSPNP!ClassGlobalDispatch
...
[1b] IRP_MJ_PNP fffff8000106d160 CLASSPNP!ClassGlobalDispatch

22. The output of !drvobj displays addresses of dispatch routines: for example,
CLASSPNP!ClassGlobalDispatch. To set and verify a breakpoint at ClassGlobalDispatch, enter these
commands:
bu CL ASSPNP!ClassGlobalDispatch
bl
Enter g to let the target computer run.
If the target computer doesn't break in to the debugger immediately, perform a few actions on the target
computer (for example, open Notepad and save a file). The target computer will break in to the debugger
when ClassGlobalDispatch is called. To see the stack trace, enter these commands:
.reload
k
 The output is similar to this:

2: kd> k
Child-SP RetAddr Call Site
ffffd000`21d06cf8 fffff800`0056c14e CLASSPNP!ClassGlobalDispatch
ffffd000`21d06d00 fffff800`00f2c31d volmgr!VmReadWrite+0x13e
ffffd000`21d06d40 fffff800`0064515d fvevol!FveFilterRundownReadWrite+0x28d
ffffd000`21d06e20 fffff800`0064578b rdyboost!SmdProcessReadWrite+0x14d
ffffd000`21d06ef0 fffff800`00fb06ad rdyboost!SmdDispatchReadWrite+0x8b
ffffd000`21d06f20 fffff800`0085cef5 volsnap!VolSnapReadFilter+0x5d
ffffd000`21d06f50 fffff800`02b619f7 Ntfs!NtfsStorageDriverCallout+0x16
...

23. To end your debugging session, enter this command:

qd

Summary of commands
Contents command on the Help menu
.sympath (Set Symbol Path)
.reload (Reload Module)
x (Examine Symbols)
g (Go)
dt (Display Type)
Break command on the Debug menu
lm (List Loaded Modules)
k (Display Stack Backtrace)
bu (Set Breakpoint)
bl (Breakpoint List)
bc (Breakpoint Clear)
Step Into command on the Debug menu (F11 )
!process
!thread
!devnode
!devstack
!drvobj
qd (Quit and Detach)

Related topics
Getting Started with WinDbg (User-Mode)
Setting Up KDNET Network Kernel Debugging Automatically
Debugger Operation
Debugging Techniques
Debugging Tools for Windows (WinDbg, KD, CDB, NTSD)
Debugging Using WinDbg Preview
 Debugging Environments
3/5/2021 • 4 minutes to read • Edit Online

There are six available debugging environments:

WinDbg Preview
Windows Debugger (WinDbg)
Kernel Debugger (KD)
NTKD
Console Debugger (CDB)
NT Symbolic Debugger (NTSD)
The following sections describe the debugging environments.
WinDbg Preview
WinDbg Preview is the latest version of WinDbg with more modern visuals, faster windows, a full-fledged
scripting experience, built with the extensible debugger data model front and center. WinDbg Preview is using
the same underlying engine as WinDbg today, so all the commands, extensions, and workflows you're used to
will still work as they did before.
For more information, see Debugging Using WinDbg Preview
WinDbg
Microsoft Windows Debugger (WinDbg) is a Windows-based debugger that is capable of both user-mode and
kernel-mode debugging. WinDbg provides debugging for the Windows kernel, kernel-mode drivers, and system
services, as well as user-mode applications and drivers.
WinDbg uses the Visual Studio debug symbol formats for source-level debugging. It can access any symbol or
variable from a module that has PDB symbol files, and can access any public function's name that is exposed by
modules that were compiled with COFF symbol files (such as Windows .dbg files).
WinDbg can view source code, set breakpoints, view variables (including C++ objects), stack traces, and
memory. Its Debugger Command window allows the user to issue a wide variety of commands.
For kernel-mode debugging, WinDbg typically requires two computers (the host computer and the target
computer). WinDbg also supports various remote debugging options for both user-mode and kernel-mode
targets.
WinDbg is a graphical-interface counterpart to CDB/NTSD and to KD/NTKD.
KD
Microsoft Kernel Debugger (KD) is a character-based console program that enables in-depth analysis of kernel-
mode activity on all NT-based operating systems. You can use KD to debug kernel-mode components and
drivers, or to monitor the behavior of the operating system itself. KD also supports multiprocessor debugging.
Typically, KD does not run on the computer being debugged. You need two computers (the host computer and
the target computer) for kernel-mode debugging.
NTKD
There is a variation of the KD debugger named NTKD. It is identical to KD in every way, except that it spawns a
new text window when it is started, whereas KD inherits the Command Prompt window from which it was
invoked.
CDB
Microsoft Console Debugger (CDB) is a character-based console program that enables low-level analysis of
Windows user-mode memory and constructs. The name Console Debugger is used to indicate the fact that CDB
is classified as a console application; it does not imply that the target application must be a console application.
In fact, CDB is fully capable of debugging both console applications and graphical Windows programs.
CDB is extremely powerful for debugging a program that is currently running or has recently crashed (live
analysis), yet simple to set up. It can be used to investigate the behavior of a working application. In the case of a
failing application, CDB can be used to obtain a stack trace or to look at the guilty parameters. It works well
across a network (using a remote access server), as it is character-based.
With CDB, you can display and execute program code, set breakpoints, and examine and change values in
memory. CDB can analyze binary code by disassembling it and displaying assembly instructions. It can also
analyze source code directly.
Because CDB can access memory locations through addresses or global symbols, you can refer to data and
instructions by name rather than by address, making it easy to locate and debug specific sections of code. CDB
supports debugging multiple threads and processes. It is extensible, and can read and write both paged and
non-paged memory.
If the target application is itself a console application, the target will share the console window with CDB. To
spawn a separate console window for a target console application, use the -2 command-line option.
NTSD
There is a variation of the CDB debugger named Microsoft NT Symbolic Debugger (NTSD). It is identical to CDB
in every way, except that it spawns a new text window when it is started, whereas CDB inherits the Command
Prompt window from which it was invoked.
Since the star t command can also be used to spawn a new console window, the following two constructions
will give the same results:

start cdb parameters

ntsd parameters

It is possible to redirect the input and output from NTSD (or CDB) so that it can be controlled from a kernel
debugger (either Visual Studio, WinDbg, or KD). If this technique is used with NTSD, no console window will
appear at all. Controlling NTSD from the kernel debugger is therefore especially useful, since it results in an
extremely light-weight debugger that places almost no burden on the computer containing the target
application. This combination can be used to debug system processes, shutdown, and the later stages of boot
up. See Controlling the User-Mode Debugger from the Kernel Debugger for details.

Related topics
Windows Debugging
Debugging Using WinDbg Preview
 Choosing the 32-Bit or 64-Bit Debugging Tools
3/5/2021 • 2 minutes to read • Edit Online

When you install Debugging Tools for Windows, you get both a 32-bit set of tools and a 64-bit set of tools.
If you are using one of the other debugging environments (WinDbg, KD, CDB, or NTSD), you have to make the
choice yourself. To determine which set of debugging tools to use, you need to know the type of processor that
is running on your host computer and whether the host computer is running a 32- or 64-bit version of
Windows.
The computer that runs the debugger is called the host computer, and the computer being debugged is called
the target computer.
Host computer running a 32-bit version of Windows
If your host computer is running a 32-bit version of Windows, use the 32-bit debugging tools. (This situation
applies to both x86-based and x64-based targets.)
x64-based host computer running a 64-bit version of Windows
If your host computer uses an x64-based processor and is running a 64-bit version of Windows, the following
rules apply:
If you are analyzing a dump file, you can use either the 32-bit debugging tools or the 64-bit debugging
tools. (It is not important whether the dump file is a user-mode dump file or a kernel-mode dump file,
and it is not important whether the dump file was made on an x86-based or an x64-based platform.)
If you are performing live kernel-mode debugging, you can use either the 32-bit debugging tools or the
x64 debugging tools. (This situation applies to both x86-based and x64-based targets.)
If you are debugging live user-mode code that is running on the same computer as the debugger, use the
64-bit tools for debugging 64-bit code and 32-bit code running on WOW64. To set the debugger for 32-
bit or 64-bit mode, use the .effmach command.
If you are debugging live 32-bit user-mode code that is running on a separate target computer, use the
32-bit debugging tools.

Related topics
Windows Debugging
 Setting Up Debugging (Kernel-Mode and User-
Mode)
3/5/2021 • 2 minutes to read • Edit Online

After you set up kernel-mode debugging, you can use WinDbg, or KD to establish a debugging session. After
you set up user-mode debugging, you can use WinDbg, CDB, or NTSD to establish a debugging session.
Note The Windows debuggers are included in Debugging Tools for Windows. These debuggers are different
from the Visual Studio debugger, which is included with Visual Studio. For more information, see Windows
Debugging.

In this section
Configuring Transports
Setting Up Kernel-Mode Debugging
Supported Target PC NICs
Supported Ethernet NICs for Network Kernel Debugging in Windows 10
Supported Ethernet NICs for Network Kernel Debugging in Windows 8.1
Supported Ethernet NICs for Network Kernel Debugging in Windows 8
Additional Configuration Tools
Configuring tools.ini
Using KDbgCtrl
 Setting Up Kernel-Mode Debugging
3/5/2021 • 2 minutes to read • Edit Online

This section describes how to set up kernel-mode debugging.

TIP
The recommended approach is to use network (KDNET) debugging and use the kdnet utility to configure that
automatically. For more information, see Setting Up KDNET Network Kernel Debugging Automatically .

In this section
KDNET
Setting Up KDNET Network Kernel Debugging Automatically
Setting Up KDNET Network Kernel Debugging Manually
Virtual Machines
Setting Up Kernel-Mode Debugging of a Virtual Machine Host- KDNET
Setting Up Kernel-Mode Debugging of a Virtual Machine Manually using a COM Port
Single PC
Setting Up Local Kernel Debugging of a Single Computer Manually
Cable Connections
Setting Up Kernel-Mode Debugging over a Serial Cable Manually
Setting Up Kernel-Mode Debugging over a USB 3.0 Cable Manually
Setting Up Kernel-Mode Debugging over a USB 2.0 Cable Manually
Setting Up Kernel-Mode Debugging over a 1394 Cable Manually

Related topics
Setting Up Debugging (Kernel-Mode and User-Mode)
Setting Up KDNET Network Kernel Debugging Automatically
 Setting Up KDNET Network Kernel Debugging
Automatically
6/16/2021 • 7 minutes to read • Edit Online

Debugging Tools for Windows supports kernel debugging over a network. This topic describes how to set up
network debugging automatically using the kdnet.exe setup tool.
The computer that runs the debugger is called the host computer, and the computer being debugged is called
the target computer. The host computer must be running Windows 7 or later, and the target computer must be
running Windows 8 or later.

Determining the IP Address of the Host Computer

1. Confirm that the target and host PCs are connected to a network hub or switch using an appropriate
network cable.
2. On the host computer, open a Command Prompt window and enter IPConfig to display the IP
configuration.
3. In the command output, locate the IPv4 address of the Ethernet adapter.

...

Ethernet adapter Ethernet:

...

IPv4 Address. . . . . . . . . . . : <YourHostIPAddress>

...

4.Make a note of the IPv4 address of the network adapter that you intend to use for debugging.

Setting Up the Host and Target Computers

Use the kdnet.exe utility to automatically configure the debugger settings on the target PC, by following these
steps.
1. Confirm that the Windows Debugging Tools are installed on the host system. For information on
downloading and installing the debugger tools, see Download Debugging Tools for Windows.
2. Locate the kdnet.exe and VerifiedNICList.xml files. By default, they are located here.

C:\Program Files (x86)\Windows Kits\10\Debuggers\x64

NOTE
These directions assumes that both PCs are running a 64 bit version of Windows on both the target and host. If
that is not the case, the best approach is to run the same "bitness" of tools on the host that the target is running.
For example, if the target is running 32-bit Windows, run a 32 version of the debugger on the host. For more
information, see Choosing the 32-Bit or 64-Bit Debugging Tools.
3. On the host computer, copy the two files to a network share or thumb drive, so that they will be available
on the target computer.
4. On the target computer, create a C:\KDNET directory and copy the kdnet.exe and VerifiedNICList.xml files
to that directory.

IMPORTANT
Before using kdnet.exe to change boot information you may need to temporarily suspend Windows security
features such as BitLocker and Secure Boot on the test PC. Re-enable these security features when testing is
complete and appropriately manage the test PC, when the security features are disabled.

5. On the target computer, open a Command Prompt window as Administrator. Enter this command to
verify that the target computer has a supported network adapter.

C:\KDNET>kdnet.exe
Network debugging is supported on the following NICs:
busparams=1.0.0, Broadcom NetXtreme Gigabit Ethernet, Plugged in.
This Microsoft hypervisor supports using KDNET in guest VMs.

6. As the output from kdnet.exe indicates that network adapter on the target is supported, we can proceed.
7. Type this command to set the IP address of the host system and generated a unique connection key. Use
the IP address or the name of the host system. Pick a unique port address for each target/host pair that
you work with, within the recommended range of 50000-50039.

C:\>kdnet.exe <HostComputerIPAddress> <YourDebugPort>

Enabling network debugging on Intel(R) 82577LM Gigabit Network Connection.

Key=2steg4fzbj2sz.23418vzkd4ko3.1g34ou07z4pev.1sp3yo9yz874p

8. Copy the returned key into a notepad .txt file.

Connecting WinDbg to the target for kernel debugging

On the host computer, open WinDbg. On the File menu, choose Kernel Debug . In the Kernel Debugging dialog
box, open the Net tab. Paste in your port number and key that you saved to in the notepad .txt file earlier. Select
OK .
You can also start a WinDbg session by opening a Command Prompt window and entering the following
command, where is the port you selected above, and is the key that was returned by kdnet.exe above. Paste in
the key in that you saved to in the notepad .txt file earlier.

windbg -k -d net:port=<YourDebugPort>,key=<YourKey>

The optional -d parameter shown in the example, enables early break in. For more information, see WinDbg
Command-Line Options.
If you are prompted about allowing WinDbg to access the port through the firewall, allow WinDbg to access the
port for all three of the different network types.
At this point the debugger will be waiting for the target to reconnect and text similar to the following will be
displayed in the debugger command window.

Microsoft (R) Windows Debugger Version 1.0.1908.30002 AMD64

Copyright (c) Microsoft Corporation. All rights reserved.

Using NET for debugging

Opened WinSock 2.0
Waiting to reconnect...

Restarting the Target PC

Once the debugger is at the "Waiting to reconnect..." stage, reboot the target computer. One way to do restart
the PC, is to use this command from an administrator's command prompt.

shutdown -r -t 0

After the target PC restarts, the debugger should connect automatically.

Troubleshooting Tips
Debugging application must be allowed through firewall
The debugger must have access through the firewall. Use Control Panel to allow access through the firewall.
1. Open Control Panel > System and Security and select Allow an app through Windows Firewall .
2. In the list of applications, locate Windows GUI Symbolic Debugger and Windows Kernel Debugger.
3. Use the check boxes to allow those two applications all three of the different network types through the
firewall.
4. Scroll down and select OK , to save the firewall changes. Restart the debugger.
Use Ping to test connectivity
If the debugger times out and does not connect, use the ping command on the target PC to verify connectivity.

C:\>Ping <HostComputerIPAddress>

Choosing a Por t for Network Debugging

If the debugger times out and does not connect, it could be because the default port number of 50000 is already
in use or it is blocked.
You can choose any port number from 49152 through 65535. The recommended range is between 50000 and
50039. The port that you choose will be opened for exclusive access by the debugger running on the host
computer.
Note The range of port numbers that can be used for network debugging might be limited by your company's
network policy. To determine whether your company's policy limits the range of ports that can be used for
network debugging, check with your network administrators.
Suppor ted Network Adapters
If "Network debugging is not supported on any of the NICs in this machine" is displayed when you run
kdnet.exe, it means that the network adapter is not supported.
The host computer can use any network adapter, but the target computer must use a network adapter that is
supported by Debugging Tools for Windows. For a list of supported network adapters, see Supported Ethernet
NICs for Network Kernel Debugging in Windows 10 and Supported Ethernet NICs for Network Kernel
Debugging in Windows 8.1.

Enable additional debugging types

Begining with Windows 10 October 2020 Update (20H2), the following options are supported to enable four
types of debugging.
b - enables bootmgr debugging. For more information see BCDEdit /bootdebug.
w - enables winload debugging. For more information see BCDEdit /bootdebug.
h - enables hypervisor debugging. For more information see BCDEdit /hypervisorsettings.
k - enables kernel debugging. For more information see Getting Started with WinDbg (Kernel-Mode).
Any combination of debug types may be specified.
If no debug types are specified then kernel debugging will be enabled.
If both hypervisor and kernel debug are enabled the hypervisor port will be set to the value port+1.
Example usage
Use the - bkw option to enable bootmgr, kernel and winload debugging.

C:\>kdnet.exe <HostComputerIPAddress> <YourDebugPort> -bkw

Enabling network debugging on Intel(R) 82577LM Gigabit Network Connection.

Key=2steg4fzbj2sz.23418vzkd4ko3.1g34ou07z4pev.1sp3yo9yz874p

Summary of debugging type options

K N DET O P T IO N DESC RIP T IO N EQ UIVA L EN T SET C O M M A N D

b enables bootmgr debugging bcdedit /bootdebug {bootmgr} on

h enables hypervisor debugging bcdedit /set hypervisordebug on

k enables kernel debugging bcdedit /debug on

w enables winload debugging bcdedit /bootdebug on

Specify bus parameters

If kdnet is not able to automatically determine the bus parameters for your transport, specify them on the
command line with /busparams option using this syntax.
kdnet.exe /busparams [b.d.f] [host] [port] [-[b][h][k][w]]

[b.d.f] specifies the bus parameters of the device to configure.

Use Device Manager on the target computer to determine the PCI bus, device, and function numbers for the
adapter you want to use for debugging. For bus parameters, enter b.d.f where b, d, and f are the bus number,
device number, and function number of the adapter. These values are displayed in Device Manager under
Location on the General tab.
For example:

C:\>kdnet.exe /busparams 0.29.7 <HostComputerIPAddress> <YourDebugPort> -bkw

Related topics
Supported Ethernet NICs for Network Kernel Debugging in Windows 10
Supported Ethernet NICs for Network Kernel Debugging in Windows 8.1
Setting Up KDNET Network Kernel Debugging Manually
Getting Started with WinDbg (Kernel-Mode)
Debug Universal Drivers - Step by Step Lab (Echo Kernel-Mode)
 Setting Up KDNET Network Kernel Debugging
Manually
3/5/2021 • 16 minutes to read • Edit Online

Debugging Tools for Windows supports kernel debugging over a network. This topic describes how to set up
network debugging manually.

IMPORTANT
Setting up a network debugging manually is a complex and error prone process. To set up network debugging
automatically, see Setting Up KDNET Network Kernel Debugging Automatically . Using the KDNET utility is
strongly recommended for all debugger users.

The computer that runs the debugger is called the host computer, and the computer being debugged is called
the target computer. The host computer must be running Windows 7 or later, and the target computer must be
running Windows 8 or later.
Debugging over a network has the following advantages compared to debugging over other types of
connectivity.
The host and target computers can be anywhere on the local network.
It is easy to debug many target computers from one host computer.
Given any two computers, it is likely that they will both have Ethernet adapters. It is less likely that they will
both have serial ports or both have 1394 ports.
Network debugging is significantly faster than serial port debugging.

Supported Network Adapters

The host computer can use any network adapter, but the target computer must use a network adapter that is
supported by Debugging Tools for Windows. For a list of supported network adapters, see Supported Ethernet
NICs for Network Kernel Debugging in Windows 10 and Supported Ethernet NICs for Network Kernel
Debugging in Windows 8.1.

Install the Debugging Tools for Windows

Confirm that the Debugging Tools for Windows are installed on the host system. For information on
downloading and installing the debugger tools, see Download Debugging Tools for Windows.

Determining the IP Address of the Host Computer

Use one of the following procedures to determine the IP address of the host computer.
1. On the host computer, open a Command Prompt window and enter the following command:

ipconfig

Make a note of the IPv4 address of the network adapter that you intend to use for debugging.
2. On the target computer, open a Command Prompt window and enter the following command, where
 YourIPAddress is the IP address of the host computer:

ping -4 <YourIPAddress>

Choosing a Port for Network Debugging

Choose a port number that will be used for debugging on both the host and target computers. You can choose
any number from 49152 through 65535, the recommended range is 50000 - 50039. The port that you choose
will be opened for exclusive access by the debugger running on the host computer. Take care to choose a port
number that is not used by any other applications that run on the host computer.
Note The range of port numbers that can be used for network debugging might be limited by your company's
network policy. There is no way to tell from the host computer what the limitations are. To determine whether
your company's policy limits the range of ports that can be used for network debugging, check with your
network administrators.
If you connect several target computers to a single host computer, each connection must have a unique port
number. For example, if you connect 100 target computers to a single host computer, you can assign port 50000
to the first connection, port 50001 to the second connection, port 50002 to the third connection, and so on.
Note A different host computer could use the same range of ports (50000 through 50099) to connect to
another 100 target computers.

Setting Up the Target Computer

1. Verify that the target computer has a supported network adapter. See these topics for more information.
Supported Ethernet NICs for Network Kernel Debugging in Windows 8.1
Supported Ethernet NICs for Network Kernel Debugging in Windows 10
2. Connect the supported adapter to a network hub or switch using an appropriate network cable.

IMPORTANT
Before using BCDEdit to change boot information you may need to temporarily suspend Windows security features such
as BitLocker and Secure Boot on the test PC. Re-enable these security features when testing is complete and appropriately
manage the test PC, when the security features are disabled.

3. In an elevated Command Prompt window, enter the following commands, where w.x.y.z is the IP address
of the host computer, and n is a port number of your choice:

bcdedit /debug on

bcdedit /dbgsettings net hostip:w.x.y.z port:n

4. bcdedit will display an automatically generated key. Copy the key and store it on a removable storage
device like a USB flash drive. You will need the key when you start a debugging session on the host
computer.
Note We strongly recommend that you use an automatically generated key. However, you can create
your own key as described later in the "Creating Your Own Key" section.
5. Use Device Manager to determine the PCI bus, device, and function numbers for the adapter you want to
use for debugging. These values are displayed in Device Manager under Location on the General tab.
 Then in an elevated Command Prompt window, enter the following command, where b, d, and f are the
bus number, device number, and function number of the adapter:

bcdedit /set "{dbgsettings}" busparams b.d.f

6. The target PC will be rebooted after a kernel debugger is attached. This is described in the next section.
Note If you intend to install the Hyper-V role on the target computer, see Setting Up Network Debugging of a
Virtual Machine Host.
Caution If your target computer is in a docking station, and you have network debugging enabled for a
network adapter that is part of the docking station, do not remove the computer from the docking station. If you
need to remove the target computer from the docking station, disable kernel debugging first. To disable kernel
debugging on the target computer, open a Command Prompt window as Administrator and enter the command
bcdedit /debug off . Reboot the target computer.

Starting the Debugging Session

Confirm that the network adapter of the host computer to a network hub or switch using an appropriate
network cable.
On the host computer, open WinDbg. On the File menu, choose Kernel Debug . In the Kernel Debugging dialog
box, open the Net tab. Enter your port number and key. Select OK .
You can also start a session with WinDbg by opening a Command Prompt window and entering the following
command, where n is your port number and MyKey is the key that was automatically generated by bcdedit
when you set up the target computer:

windbg -k net:port=<n>,key=<MyKey>

If you are prompted about allowing WinDbg to access the port through the firewall, allow WinDbg to access the
port for all three of the different network types.
Using KD
On the host computer, open a Command Prompt window. Enter the following command, where n is your port
number and MyKey is the key that was automatically generated by bcdedit when you set up the target
computer:

kd -k net:port=<n>,key=<MyKey>

If you are prompted about allowing WinDbg to access the port through the firewall, allow WinDbg to access the
port for all three of the different network types.

Restarting the Target PC

Once the debugger is connected, and waiting to connect, reboot the target computer. One way to do restart the
PC is to use this command, from an administrator's command prompt.

shutdown -r -t 0

When the target is restarted, the debugger in the host OS should connect.
After connecting to the target on the host, hit break on your debugger and you can start debugging.
Allowing the debugger through the firewall
When you first attempt to establish a network debugging connection, you might be prompted to allow the
debugging application (WinDbg or KD) access through the firewall. Client versions of Windows display the
prompt, but Server versions of Windows do not display the prompt. You should respond to the prompt by
checking the boxes for all three network types: domain, private, and public. If you do not get the prompt, or if
you did not check the boxes when the prompt was available, you must use Control Panel to allow access
through the firewall. Open Control Panel > System and Security and select Allow an app through
Windows Firewall . In the list of applications, locate Windows GUI Symbolic Debugger and Windows Kernel
Debugger. Use the check boxes to allow those two applications through the firewall. Restart your debugging
application (WinDbg or KD).

Encryption key
To keep the target computer secure, packets that travel between the host and target computers must be
encrypted. We strongly recommend that you use an automatically generated encryption key (provided by
bcdedit when you configure the target computer). Network debugging uses a 256-bit key that is specified as
four 64-bit values, in base 36, separated by periods. Each 64-bit value is specified by using up to 13 characters.
Valid characters are the letters a through z and the digits 0 through 9. Special characters are not allowed.
To specify your own key, open an elevated Command Prompt window on the target computer. Enter the
following command, where w.x.y.z is the IP address of the host computer, and n is your port number, and Key is
your key:

bcdedit /dbgsettings net hostip:w.x.y.z port:n key:Key

The target computer needs to be rebooted anytime the dbgsettings are changed.

Troubleshooting Tips
Debugging application must be allowed through firewall
When you first attempt to establish a network debugging connection, you might be prompted to allow the
debugging application (WinDbg or KD) access through the firewall. Client versions of Windows display the
prompt, but Server versions of Windows do not display the prompt. You should respond to the prompt by
checking the boxes for all three network types: domain, private, and public. If you do not get the prompt, or if
you did not check the boxes when the prompt was available, you must use Control Panel to allow access
through the firewall. Open Control Panel > System and Security and select Allow an app through
Windows Firewall . In the list of applications, locate Windows GUI Symbolic Debugger and Windows Kernel
Debugger. Use the check boxes to allow those two applications through the firewall. Scroll down and select OK ,
to save the firewall changes. Restart the debugger.
Port number must be in range allowed by network policy
The range of port numbers that can be used for network debugging might be limited by your company's
network policy. To determine whether your company's policy limits the range of ports that can be used for
network debugging, check with your network administrator. On the target computer, open a Command Prompt
window as Administrator and enter the command bcdedit /dbgsettings . The output will be similar to this.

C:\> bcdedit /dbgsettings

key XXXXXX.XXXXX.XXXXX.XXXXX
debugtype NET
hostip 169.168.1.1
port 50085
dhcp Yes
The operation completed successfully.
In the preceding output, the value of port is 50085. If the value of port lies outside the range allowed by your
network administrator, enter the following command, where w.x.y.z is the IP address of the host computer, and
YourDebugPort is a port number in the allowed range.

bcdedit /dbgsettings net hostip:w.x.y.z port:YourDebugPort

After changing the target machine debugger settings, rerun the debugger on the host machine with the new
port setting, and then reboot the target computer.
Use Ping to test connectivity
If the debugger does not connect use the ping command on the target PC to verify connectivity.

C:\>Ping <HostComputerIPAddress>

Note that this may not work if your host computer is not configured to be discoverable on the network, since
the firewall may block ping requests, and because of this, you will not get any responses when you ping the
host.
How the Debugger Obtains an IP Address for the Target Computer
KDNET on the target computer attempts to use Dynamic Host Configuration Protocol (DHCP) to get a routable
IP address for the network adapter that is being used for debugging. If KDNET obtains a DHCP-assigned
address, then the target computer can be debugged by host computers located anywhere on the network. If
KDNET fails to obtain a DHCP-assigned address, it uses Automatic Private IP Addressing (APIPA) to obtain a local
link IP address. Local link IP addresses are not routable, so a host and target cannot use a local link IP address to
communicate through a router. In that case, network debugging will work if you plug the host and target
computers into the same network hub or switch.
Always specify busparams when setting up KDNET on a physical machine with a PCI based NIC
If you are setting up KDNET on a physical machine with a PCI or PCIe based NIC, you should always specify the
busparams for the NIC you want to use for KDNET. To specify the bus parameters, Open Device Manager, and
locate the network adapter that you want to use for debugging. Open the property page for the network adapter
and make a note of the bus number, device number, and function number that are displayed under Location on
the General tab. In an elevated Command Prompt Window, enter the following command, where b, d, and f are
the bus, device and function numbers in decimal format:

bcdedit /set "{dbgsettings}" busparams b.d.f

When the debugger is running on the host machine, and waiting to connect, reboot the target computer, using
this command.

shutdown -r -t 0

Manually delete BCDEdit entries

Manually deleting is not normally required but is provided here as a troubleshooting procedure for unusual
situations.
Manually deleting entries is not necessary when using the kdnet utility. For more information, see Setting Up
KDNET Network Kernel Debugging Automatically.
When you use bcdedit –deletevalue, you must provide a valid bcd element name. For more information, see
BCDEdit /deletevalue.
To manually delete BCDEdit entries, complete these steps.
1. On the target computer, open a Command Prompt window as Administrator.
2. As an example, enter this command to delete the BCDEdit debugging entry for the host IP address.

bcdedit -deletevalue {dbgsettings} hostip

When you delete the hostip, you need to specify target= on the debugger command line.
3. As another example, delete the port entry using this command.

bcdedit -deletevalue {dbgsettings} port

When you delete the port entry, KDNET will use the default ICANN registered debugger port of 5364.

Hyper-V
Setting up Hyper-V
If you intend to install the Hyper-V role on the target computer, see Setting Up Network Debugging of a Virtual
Machine Host.
For information on debugging a hyper-v Virtual Machine (VM), see Setting Up Network Debugging of a Virtual
Machine - KDNET.
Enabling KDNET on a hyper-v host that is running VMs with external network connectivity
There is a specific situation, which is not uncommon, which will cause networking in VMs to stop working:
Hyper-V has been enabled on the PC, an external networking switch has been created and is pointed at a
physical NIC in the machine, and VMs have been configured to use that external switch for their
networking.
KDNET is then enabled on the hyper-v host OS using the same physical NIC that is pointed to by the
external networking switch, and the host is rebooted.
All of the VMs that were using the previously configured external switch, lose their network connectivity
after the reboot.
This is by design, and happens because KDNET takes exclusive control over the NIC it is configured to use, and
the native NDIS miniport for that NIC is not loaded by the OS. When this occurs, the external networking switch
can no longer communicate with the native NDIS miniport driver, and will stop working. To work around this
situation, do the following:
1. Open the Virtual Switch Manager from Hyper-V Manager, select your existing Virtual Switch, and change
the external network NIC to the Microsoft Kernel Debug Network Adapter by selecting it from the drop
down box and then selecting OK in the Virtual Switch Manager dialog box.
2. After updating your Virtual Switch NIC, shutdown and restart your VMs.
When KDNET debugging is turned off, the same procedure will need to be followed to repoint the external
switch back to the native NDIS miniport for the NIC. Otherwise VM connectivity will be lost when the machine is
rebooted after debugging is disabled.

IPv6
IPv6 support was added in Windows version 1809.
To use IPv6 with the debugger complete these steps.
1. Ping your <debughostname> and note the IPv6 address that is reported on the Reply from output
lines.Use this IPv6 address in place of x:y:z:p:d:q:r:n below.
2. Use BCDEdit to delete any existing ip address values in dbgsettings.

bcdedit -deletevalue {dbgsettings} hostip

3. Set the IPv6 address of the host. There must not be any spaces in the hostipv6=s:t:u:v:w:x:y:z string. is
is the network port number to use for this target machine, <YourKey> is the four part security key, and
<b.d.f> are the bus device function location numbers for the NIC you want to use for KDNET.

bcdedit /dbgsettings net hostipv6:s:t:u:v:w:x:y:z port:<YourPort> key:<YourKey> busparams:<b.d.f>

4. Type this command to confirm that the dbgsettings are set properly.

C:\> bcdedit /dbgsettings

busparams 0.25.0
key 2steg4fzbj2sz.23418vzkd4ko3.1g34ou07z4pev.1sp3yo9yz874p
debugtype NET
hostipv6 2001:db8:0:0:ff00:0:42:8329
port 50010
dhcp Yes
The operation completed successfully.

5. On the host machine use this command to start the debugger.

Windbg -k net:port=<yournetworkportnumber>,key=<key_output_from_kdnet>,target=::<YourIPv6Address>

6. When the debugger is running on the host machine, and waiting to connect, reboot the target computer.
7. The debugger should connect to the host debugger early during boot. You will know that KDNET is using
an IPv6 connection because the IP addresses reported in the connected message will be IPv6 addresses
instead of IPv4 addresses.
NOTES
Every debugger bcd setting that allows the hostip to be specified has a corresponding hostipv6 element.
There are three.

IP V4 IP V6 USA GE

hostip hostipv6 For boot and kernel debugging

targethostip targethostipv6 Specific to kernel debugging

hypervisorhostip hypervisorhostipv6 For hyper-v debugging

If you set the hostipv6 style address for any of those kinds of debugging, it means you want and will get
IPv6.
If you set the hostip style address for any of those kinds of debugging, it means you want and will get
IPv4.
 The target will only do IPv4 or IPv6, not both at the same time. Which version of the IP protocol is used is
controlled by the target machine dbgsettings. If hostip is set, the target will use IPv4. If hostipv6 is set, the
target will use IPv6.
The host debugger will normally auto select use of IPv4 or IPv6. By default the debugger listens on both
an IPv4 socket and an IPv6 socket, and connects automatically on either one to the target machine.
If you want to force use of IPv6 in the debugger on the host, but you want the debugger to listen for a
connection from the target, then you can add, target=:: to the debugger command line. :: is an IPv6
address of 0.
If you want to force IPv4 debugging in the debugger on the host, but you want the debugger to listen for
a connection from the target, then you can add, target=0.0.0.0 to the debugger command line. 0.0.0.0 is
an IPv4 address of 0.
If you specify, target= on the debugger command line and use a machine name, the debugger will
convert that machine name into an IPv4 address and an IPv6 address, and will attempt to connect on
both.
If you specify, target= on the debugger command line, and use an IP address, if the IP address contains
any contains any : characters, the debugger will assume it is an IPv6 address, and will force use of IPv6 for
that connection. If the IP address contains any . characters, the debugger will assume it is an IPv4 address,
and will force use of IPv4 for that connection.
If you setup IPv6 on the target, and force use of IPv4 on the debugger command line, you will not get a
connection.
If you setup IPv4 on the target, and force use of IPv6 on the debugger command line, you will also not get
a connection.

Related topics
Setting Up KDNET Network Kernel Debugging Automatically
Supported Ethernet NICs for Network Kernel Debugging in Windows 10
Supported Ethernet NICs for Network Kernel Debugging in Windows 8.1
 Setting Up Network Debugging of a Virtual
Machine - KDNET
3/5/2021 • 6 minutes to read • Edit Online

This topic describes how to configure a kernel debugging connection to a Hyper-V virtual machine (VM).

Hyper-V Virtual Machine Setup

To debug a Gen 2 Hyper-V Virtual Machine (VM) complete the following steps.
1. Create a VM with Windows installed
For information on how to create a VM, see Create a Virtual Machine with Hyper-V.
2. Define an external vir tual switch
To communicate with the VM a virtual external network switch can be used. For information on how to create
external network switch, see Create a virtual network.
When the external network switch is configured the following options must be set.

O P T IO N VA L UE

Connection Type External Network

Allow management operating system to share this network Enabled

adapter

VLAN ID Disabled

3. Disable Secure Boot

To allow the kdnet utility to update BCDEdit boot settings, temporarily disable secure boot on the virtual
machine by following these steps.
1. Load the Hyper-V manager and select the properties for your VM.
2. Select the Security settings.
3. Un-check the Enable Secure Boot checkbox.
4. Select OK to save the settings.
You can re-enable Secure Boot once you’re done debugging and you’ve disabled kernel debugging on the target
VM.
4. Install the Debugging Tools for Windows
The debugging tools are used for the debugger and the kdnet utility and must be installed. For information on
how to download and install the debugging tools, see Download Debugging Tools for Windows.

Setting Up Network Debugging of a Virtual Machine - KDNET

Record the Host IP Address
To run the host debugger on the same PC as the target virtual machine, follow these steps.
1. In the host computer OS, open a Command Prompt window and enter IPConfig to display the IP
configuration.
2. In the command output, locate the Ethernet adapter that you configured as the External Virtual Switch.

...

Ethernet adapter vEthernet (External Virtual Switch):

...

IPv4 Address. . . . . . . . . . . : <YourHostIPAddress>

...

3. Record the IPv4 address of the External Virtual Switch that will be used as the host address for
debugging.
4. To confirm connectivity between the target and the host computer, open an elevated command prompt
window on the target computer, and enter the following command, where YourHostIPAddress is the IP
address of the host computer.

ping -4 <YourHostIPAddress>

Setting Up the VM Target Computer

Use the kdnet.exe utility to automatically configure the debugger settings on the target PC, by following these
steps.
1. Locate the WDK kdnet.exe and VerifiedNICList.xml files. By default they are located here.

C:\Program Files (x86)\Windows Kits\10\Debuggers\x64

NOTE
These directions assumes that both PCs are running a 64 bit version of Windows on both the target and host. If that is
not the case, the best approach is to run the same "bitness" of tools on the host that the target is running. For example, if
the target is running 32 bit Windows, run a 32 version of the debugger on the host. For more information, see Choosing
the 32-Bit or 64-Bit Debugging Tools.

2. To allow the long key that is used to be cut and pasted, enable enhanced session support. In the VM
window, from the View pull down menu, enable Enhanced session.
3. On the target VM computer, create a C:\KDNET directory and copy the kdnet.exe and VerifiedNICList.xml
files to that directory.
4. On the target computer, open a Command Prompt window as Administrator. Enter this command to
verify that the target computer has a supported network adapter.
 C:\KDNET>kdnet

Network debugging is supported on the following NICs:

busparams=0.25.0, Intel(R) 82579LM Gigabit Network Connection, KDNET is running on this NIC.kdnet.exe

5. Type this command to set the IP address of the host system and generated a unique connection key. Use
the IP address of the host system you recorded earlier. Pick a unique port address for each target/host
pair that you work with, with in the range 50000-50039. For this example, we will select 50005.

C:\>kdnet <YourIPAddress> <YourDebugPort>

Enabling network debugging on Microsoft Hypervisor Virtual Machine.

Key=3u8smyv477z20.2owh9gl90gbxx.3sfsihzgq7di4.nh8ugnmzb4l7

To debug this vm, run the following command on your debugger host machine.
windbg -k net:port=50005,key=3u8smyv477z20.2owh9gl90gbxx.3sfsihzgq7di4.nh8ugnmzb4l7

Then restart this VM by running shutdown -r -t 0 from this command prompt.

6. Use CRTL+C to copy the provided windbg output into the command buffer. Doing this avoids attempting
to write down the long key value that is returned.
7. Re-enable BitLocker and secure boot when you're done configuring the debugger settings.
8. Because a VM with enhanced session support can timeout when it is left in a breakpoint, disable
Enhanced session support using the View pull down menu in the VM.
9. The VM will be restarted after the debugger is loaded and running. This process is described next.

Starting the Debugging Session

1. To connect to the target PC, use CTRL+V to paste in the main OS command window the windbg string
that was returned by kdnet that you copied earlier.

C:\Debuggers\windbg -k net:port=<YourDebugPort>,key=<YourKey>

When you first attempt to establish a network debugging connection, you might be prompted to allow the
debugging application (WinDbg or KD) access through the firewall. You should respond to the prompt by
checking the boxes for all three network types: domain, private, and public.

Restarting the Target PC

Once the debugger is connected, reboot the target computer. To force the VM to completely restart, use this
command, from an administrator's command prompt.

shutdown -r -t 0

When the target virtual machine is restarted, the debugger in the host OS should connect.
After connecting to the VM, hit break on your debugger and you can start debugging.
To support the debugging connection a Kernel Debug Network Adapter is added and visible in network
properties, after the VM is rebooted.
Troubleshooting KDNET Virtual Machine Network Debugging
If the debugger does not connect, use the ping command from the target VM to verify connectivity.

C:\>Ping <HostComputerIPAddress>

Something didn't work right and I'm not sure what...

Ensure you've let WinDbg through your firewall.
Confirm that you are using a unique Key that was generated by BCDEdit or kdnet.
My VMs don't have network connectivity
Open Virtual Switch Manager from Hyper-V Manager, select your existing Virtual Switch, and change the
external network NIC to the Microsoft Kernel Debug Network Adapter by selecting it from the drop down box
and then selecting OK in the Virtual Switch Manager dialog box. After updating your Virtual Switch NIC,
make sure to then shutdown and restart your VMs.

Sequence to add Hyper-V role to a Windows PC

If your target computer is a virtual machine host, you can set up network debugging and still have network
access for the virtual machines.
Suppose you want to set up network debugging in the following situation.
The target computer has a single network interface card.
You intend to install the Hyper-V role on the target computer.
You intend to create one or more virtual machines on the target computer.
The best approach is to set up network debugging on the target computer before you install the Hyper-V role.
Then the virtual machines will have access to the network.
If you decide to set up network debugging after the Hyper-V role has been installed on the target computer, you
must change the network settings for your virtual machines to bridge them to the Microsoft Kernel Network
Debug Adapter. Otherwise, the virtual machines will not have access to the network.

Related topics
Setting Up Kernel-Mode Debugging of a Virtual Machine Manually using a Virtual COM Port
Setting Up a Network Connection Manually
 Setting Up Kernel-Mode Debugging of a Virtual
Machine Manually using a Virtual COM Port
3/5/2021 • 5 minutes to read • Edit Online

Debugging Tools for Windows supports kernel debugging of a virtual machine. The virtual machine can be
located on the same physical computer as the debugger or on a different computer that is connected to the
same network. This topic describes how to set up debugging of a virtual machine manually using a virtual COM
Port via KDCOM.
Using KDNET virtual networking is a faster option and is recommended. For more information, see Setting Up
Network Debugging of a Virtual Machine with KDNET.

Setting Up the Target Virtual Machine

The computer that runs the debugger is called the host computer, and the virtual machine being debugged is
called the target virtual machine.

IMPORTANT
Before using BCDEdit to change boot information you may need to temporarily suspend Windows security features such
as BitLocker and Secure Boot on the test PC. Re-enable these security features when testing is complete and appropriately
manage the test PC, when the security features are disabled.

1. In the virtual machine, in an elevated Command Prompt window, enter the following commands.
bcdedit /debug on
bcdedit /dbgsettings serial debugpor t:n baudrate:115200
where n is the number of a COM port on the virtual machine.
2. In the virtual machine, configure the COM port to map to a named pipe. The debugger will connect
through this pipe. For more information about how to create this pipe, see your virtual machine's
documentation.
3. Start the debugger in elevated mode, for example from an administrator command prompt. The
debugger must be running in elevated mode when debugging a VM over a serial pipe. Once the
debugger is attached and running, reboot the target VM.

Starting the Debugging Session Using WinDbg

On the host computer, open WinDbg as an Administrator. The debugger must be running in elevated mode
when debugging a VM over a serial pipe. On the File menu, choose Kernel Debug . In the Kernel Debugging
dialog box, open the COM tab. Check the Pipe box, and check the Reconnect box. For Baud Rate , enter
115200. For Resets , enter 0.
If the debugger is running on the same computer as the virtual machine, enter the following for Por t .
\\.\pipe\ PipeName.
If the debugger is running on a different computer from the virtual machine, enter the following for Por t .
\\ VMHost\pipe\ PipeName
Select OK .
You can also start WinDbg at the command line. If the debugger is running on the same physical computer as
the virtual machine, enter the following command in a Command Prompt window.
windbg -k com:pipe,por t=\\.\pipe\ PipeName,resets=0,reconnect
If the debugger is running on a different physical computer from the virtual machine, enter the following
command in a Command Prompt window.
windbg -k com:pipe,por t=\\ VMHost\pipe\ PipeName,resets=0,reconnect

Starting the Debugging Session Using KD

To debug a virtual machine that is running on the same physical computer as the debugger, enter the following
command in an elevated Command Prompt window.
kd -k com:pipe,por t=\\.\pipe\ PipeName,resets=0,reconnect
To debug a virtual machine that is running on a different physical computer from the debugger, enter the
following command in a Command Prompt window.
kd -k com:pipe,por t=\\ VMHost\pipe\ PipeName,resets=0,reconnect

Parameters
VMHost
Specifies the name of the computer that the virtual machine is running on.
PipeName
Specifies the name of the pipe that you created on the virtual machine.
resets=0
Specifies that an unlimited number of reset packets can be sent to the target when the host and target are
synchronizing. Use the resets=0 parameter for Microsoft Virtual PC and other virtual machines whose pipes
drop excess bytes. Do not use this parameter for VMware or other virtual machines whose pipes do not drop all
excess bytes.
reconnect
Causes the debugger to automatically disconnect and reconnect the pipe if a read/write failure occurs.
Additionally, if the debugger does not find the named pipe when the debugger is started, the reconnect
parameter causes the debugger to wait for a pipe that is named PipeName to appear. Use reconnect for Virtual
PC and other virtual machines that destroy and re-create their pipes during a computer restart. Do not use this
parameter for VMware or other virtual machines that preserve their pipes during a computer restart.
For more information about additional command-line options, see KD Command-Line Options or WinDbg
Command-Line Options .

Generation 2 Virtual Machines

By default, COM ports are not presented in generation 2 virtual machines. You can add COM ports through
PowerShell or WMI. For the COM ports to be displayed in the Hyper-V Manager console, they must be created
with a path.
To enable kernel debugging using a COM port on a generation 2 virtual machine, follow these steps:
1. Disable Secure Boot by entering this PowerShell command:
 Set-VMFirmware –Vmname VmName –EnableSecureBoot Off
where VmName is the name of your virtual machine.
2. Add a COM port to the virtual machine by entering this PowerShell command:
Set-VMComPor t –VMName VmName 1 \\.\pipe\ PipeName
For example, the following command configures the first COM port on virtual machine TestVM to
connect to named pipe TestPipe on the local computer.
Set-VMComPor t –VMName TestVM 1 \\.\pipe\TestPipe
3. Once the debugger is attached and running, stop and cold start the VM to activate the COM ports in the
VM.　The emulated UARTS aren’t available for debugging unless at least one is actually configured with a
pipe name and they cannot be hot-added.
4. Re-enable secure boot, once you are done updating the configuration changes.
For more information about Generation 2 VMs, see Generation 2 Virtual Machine Overview.

Remarks
If the target computer has stopped responding, the target computer is still stopped because of an earlier kernel
debugging action, or you used the -b command-line option, the debugger breaks into the target computer
immediately.
Otherwise, the target computer continues running until the debugger orders it to break.

Troubleshooting Firewalls and Network Access Issues

Your debugger (WinDbg or KD) must have access through the firewall. This can even be the case for virtual
serial ports that are supported by network adapters.
If you are prompted by Windows to turn off the firewall when the debugger is loaded, select all three boxes.
Depending on the specifics of the VM in use, you may need to change the network settings for your virtual
machines to bridge them to the Microsoft Kernel Network Debug Adapter. Otherwise, the virtual machines will
not have access to the network.
Windows Firewall
You can use Control Panel to allow access through the Windows firewall. Open Control Panel > System and
Security, and select Allow an app through Windows Firewall. In the list of applications, locate Windows GUI
Symbolic Debugger and Windows Kernel Debugger. Use the check boxes to allow those two applications
through the firewall. Restart your debugging application (WinDbg or KD).

Third Party VMs

VMWare If you restart the virtual machine by using the VMWare facilities (for example, the reset button), exit
WinDbg, and then restart WinDbg to continue debugging. During virtual machine debugging, VMWare often
consumes 100% of the CPU.

Related topics
Setting Up Network Debugging of a Virtual Machine with KDNET
Setting Up Kernel-Mode Debugging Manually
Setting Up Network Debugging of a Virtual Machine Host
 Setting Up Local Kernel Debugging of a Single
Computer Manually
3/5/2021 • 2 minutes to read • Edit Online

Debugging Tools for Windows supports local kernel debugging. This is kernel-mode debugging on a single
computer. In other words, the debugger runs on the same computer that is being debugged. With local
debugging you can examine state, but not break into kernel mode processes that would cause the OS to stop
running.
The local bcdedit option is available in Windows 8.0 and Windows Server 2012 and later.

Setting Up Local Kernel-Mode Debugging

IMPORTANT
Before using bcdedit to change boot information you may need to temporarily suspend Windows security features such
as BitLocker and Secure Boot on the test PC. You can re-enable Secure Boot once you’re done debugging and you’ve
disabled kernel debugging on the local computer.

1. Open a Command Prompt window as Administrator. Enter bcdedit /debug on

2. If the computer is not already configured as the target of a debug transport, enter bcdedit /dbgsettings
local
3. Reboot the computer.

Starting the Debugging Session

Using WinDbg
Open WinDbg as Administrator. On the File menu, choose Kernel Debug . In the Kernel Debugging dialog box,
open the Local tab. Select OK .
You can also start a session with WinDbg by opening a Command Prompt window as Administrator and
entering the following command:
windbg -kl
Using KD
Open a Command Prompt window as Administrator, and enter the following command:
kd -kl

Related topics
Local Kernel-Mode Debugging
Setting Up Kernel-Mode Debugging Manually
 Setting Up Kernel-Mode Debugging over a Serial
Cable Manually
3/5/2021 • 4 minutes to read • Edit Online

Debugging Tools for Windows supports kernel debugging over a null-modem cable. Null-modem cables are
serial cables that have been configured to send data between two serial ports. Do not confuse null-modem
cables with standard serial cables. Standard serial cables do not connect serial ports to each other. For
information about how null-modem cables are wired, see Null-Modem Cable Wiring.
The computer that runs the debugger is called the host computer, and the computer being debugged is called
the target computer.

Setting Up the Target Computer

IMPORTANT
Before using bcdedit to change boot information you may need to temporarily suspend Windows security features such
as BitLocker and Secure Boot on the test PC. You can re-enable Secure Boot once you’re done debugging and you’ve
disabled kernel debugging.

1. On the target computer, open a Command Prompt window as Administrator, and enter the following
commands, where n is the number of the COM port used for debugging on the target computer, and rate
is the baud rate used for debugging:
bcdedit /debug on
bcdedit /dbgsettings serial debugpor t:n baudrate:rate
Note The baud rate must be the same on the host computer and target computer. The recommended
rate is 115200.
2. Reboot the target computer.

Starting the Debugging Session

Connect the null-modem cable to the COM ports that you have chosen for debugging on the host and target
computers.
Using WinDbg
On the host computer, open WinDbg. On the File menu, choose Kernel Debug . In the Kernel Debugging dialog
box, open the COM tab. In the Baud rate box, enter the rate you have chosen for debugging. In the Por t box,
enter COMn where n is the COM port number you have chosen for debugging on the host computer. Select OK .
You can also start a session with WinDbg by entering the following command in a Command Prompt window; n
is the number of the COM port used for debugging on the host computer, and rate is the baud rate used for
debugging:
windbg -k com:por t=COM n,baud= rate
Using KD
On the host computer, open a Command Prompt window, and enter the following command, where n is the
number of the COM port used for debugging on the host computer, and rate is the baud rate used for
debugging:
kd -k com:por t=COM n,baud= rate

Using Environment Variables

On the host computer, you can use environment variables to specify the COM port and the baud rate. Then you
do not have to specify the port and baud rate each time you start a debugging session. To use environment
variables to specify the COM port and baud rate, open a Command Prompt window and enter the following
commands, where n is the number of the COM port used for debugging on the host computer, and rate is the
baud rate used for debugging:
set _NT_DEBUG_PORT=COM n
set _NT_DEBUG_BAUD_RATE= rate
To start a debugging session, open a Command Prompt window, and enter one of the following commands:
kd
windbg

Troubleshooting Tips for Debugging over a Serial Cable

Specify correct COM port on both host and target
Determine the numbers of the COM ports you are using for debugging on the host and target computers. For
example, suppose you have your null-modem cable connected to COM1 on the host computer and COM2 on
the target computer.
On the target computer, open a Command Prompt window as Administrator, and enter bcdedit /dbgsettings .
If you are using COM2 on the target computer, the output of bcdedit should show debugport 2 .
On the host computer, specify the correct COM port when you start the debugger or when you set environment
variables. If you are using COM1 on the host computer, use one of the following methods to specify the COM
port.
In WinDbg, in the Kernel Debugging dialog box, enter COM1 in the Por t box.
windbg -k com:por t=COM1, ...
kd -k com:por t=COM1, ...
set _NT_DEBUG_PORT=COM1
Baud rate must be the same on host and target
The baud rate used for debugging over a serial cable must be set to the same value on the host and target
computers. For example, suppose you have chosen a baud rate of 115200.
On the target computer, open a Command Prompt window as Administrator, and enter bcdedit /dbgsettings .
The output of bcdedit should show baudrate 115200 .
On the host computer, specify the correct baud rate when you start the debugger or when you set environment
variables. Use one of the following methods to specify a baud rate of 115200.
In WinDbg, in the Kernel Debugging dialog box, enter 115200 in the Baud rate box.
windbg -k ..., baud=115200
kd -k ..., baud=115200
set _NT_DEBUG_BAUD_RATE=115200
Null Modem Cable Wiring
The following tables show how null-modem cables are wired.
9-pin connector
C O N N EC TO R 1 C O N N EC TO R 2 SIGN A L S

2 3 Tx - Rx

3 2 Rx - Tx

7 8 RTS - CTS

8 7 CTS - RTS

4 1+6 DTR - (CD+DSR)

1+6 4 (CD+DSR) - DTR

5 5 Signal ground

25-pin connector
C O N N EC TO R 1 C O N N EC TO R 2 SIGN A L S

2 3 Tx - Rx

3 2 Rx - Tx

4 5 RTS - CTS

5 4 CTS - RTS

6 20 DSR - DTR

20 6 DTR - DSR

7 7 Signal ground

Signal Abbreviations
A B B REVIAT IO N SIGN A L

Tx Transmit data

Rx Receive data

RTS Request to send

CTS Clear to send

DTR Data terminal ready

 A B B REVIAT IO N SIGN A L

DSR Data set ready

CD Carrier detect

Additional Information
For complete documentation of the bcdedit command, see BCDEdit Options Reference.

Related topics
Setting Up Kernel-Mode Debugging Manually
 Setting Up 2PF Kernel-Mode Debugging using
KDNET
6/16/2021 • 13 minutes to read • Edit Online

Debugging Tools for Windows supports kernel debugging over a network cable using multiple Physical
Functions (PFs) on the supported NICs by partitioning the PCI configuration space.
With 2PF debugging, each PF can be connected to a single network port, so it allows the kernel debugging
functionality to be connected to one PF while the standard network stack talks to the other PF. Because of this,
KDNIC doesn't need to route the Windows networking traffic via KDNET, and KDNET will only be responsible to
route the host kernel debugger traffic. This results in a dramatic performance increase.
This topic describes how to set up 2PF debugging using the kdnet.exe utility.
Network card vendors are encouraged to enable support for this feature. For more information, see Debugger
2PF KDNET Miniport Network Driver Support.
Two drivers will run over the partitioned PCI configuration space
The Windows inbox driver will run out of the primary network port at bus.dev.fun0.0 PCI location.
The KDNET-Ext. module will run out of the added PF at bus.dev.fun0.1 , This technique ensures that the
Windows inbox NIC driver does not get impacted by sharing the NIC with KDNET.
The computer that runs the debugger is called the host computer, and the computer being debugged is called
the target computer.

Kernel-Mode 2PF device requirements

The following is required:
On the target computer, a supported 2PF network card.
On the host computer, a network card.
A network connection between the target and host.
Windows 10 Insider Preview Build 21313 and later.

Supported 2PF Network Cards

Vendors such as NVIDIA Mellanox and Cisco provide NICs that support 2PF network debugging. Check with the
network card vendor to see which models of the network card are supported. Note that some vendors support
2PF on a sub set of network cards that share the same PnP ID.

Use kdnet.exe to confirm device support and view the busparams

value
Use the kdnet.exe utility to display the parameter information for controllers that support KDNET 2PF transport
debugging.
1. Confirm that the Windows Debugging Tools are installed on the host system. For information on
downloading and installing the debugger tools, see Download Debugging Tools for Windows.
2. Locate the kdnet.exe and VerifiedNICList.xml files. By default, they are located here.
C:\Program Files (x86)\Windows Kits\10\Debuggers\x64

3. On the host computer, copy the two files to a network share or thumb drive, so that they will be available
on the target computer.
4. On the target computer, create a C:\KDNET directory and copy the kdnet.exe and VerifiedNICList.xml files
to that directory.
5. On the target computer, open a Command Prompt window as Administrator. Enter this command to
verify that the target computer has a supported network adapter and to view the busparams value.

C:\KDNET>kdnet.exe

Network debugging is supported on the following NICs:

busparams=141.0.0, Mellanox ConnectX-4 Lx Ethernet Adapter #2, Plugged in, Primary function, multiple
physical functions are supported.

Network debugging is supported on the following USB controllers:

busparams=128.15.0, Standard USB 3.0 eXtensible Host Controller - 1.0 (Microsoft)
busparams=0.15.0, Standard USB 3.0 eXtensible Host Controller - 1.0 (Microsoft)
busparams=128.15.1, Standard USB 3.0 eXtensible Host Controller - 1.0 (Microsoft)
busparams=0.15.1, Standard USB 3.0 eXtensible Host Controller - 1.0 (Microsoft)

Because the output shown above, does not include "KDNET is running on this NIC.", this indicates that
traditional KDNET debugging is not enabled on any of the adapters.
If the NIC does not support the multiple PF feature, then the PF status notification of "multiple physical
functions are supported" will be omitted (blank) from the displayed information.
If NIC supports multiple PF, then the actual displayed information will depend on the combination of the
Network port (root port/PF added port), as well as cable connected/disconnected status to/from the NIC
physical port.
This table summarizes different PF notifications for the primary NIC.

N IC A DA P T ER B US. DEV. F UN
C O RRESP O N DS TO C A B L E STAT US P F STAT US

original (primary) PF cable connected Primary function, multiple physical

functions are enabled

original (primary) PF cable disconnected Primary function, multiple physical

functions are supported

This table summarizes different PF notifications for the secondary NIC.

N IC A DA P T ER B US. DEV. F UN
C O RRESP O N DS TO C A B L E STAT US P F STAT US

new (secondary) PF port Kdnet is running Secondary function

new (secondary) PF port cable disconnected or unknown Primary function, multiple physical
status functions are enabled, but
secondary function is not used

6. If the output from kdnet.exe indicates that a supported NIC controller is available, we can proceed.
Setting Up the Target Computer for 2PF
Use the kdnet.exe utility to configure the debugger settings on the target PC for 2PF, by following these steps.

IMPORTANT
Before using bcdedit to change boot information you may need to temporarily suspend Windows security features such
as BitLocker and Secure Boot on the test PC. You can re-enable Bit Locker and Secure Boot once you’re done using
BCDEdit to update the boot information. Appropriately manage the test PC, when the security features are disabled.

This process will adds a new physical function (PF) to the a NIC, specified by bus.device.function . The new PF
can be used only by KDNET, since the Windows inbox driver is set up to not run on an added, secondary PF.
Follow these steps to add a new PF that will be used by the debug device.
Confirm that debugging is disabled before adding the new physical function
1. Use the BCDEdit command to confirm that the KD is disabled on the target before adding a new PF on the
NIC. This is needed to make sure the standard vendor NIC driver is loaded so that it can be used to add the
new PF.

C:\> bcdedit /enum

...

debug No

As an alternative, use kdnet.exe with out parameters to see if debugging is enabled. The output below, shows
KDNET running on a system with debugging enabled on one NIC. This is the lower performance legacy setup.

c:\Debuggers>kdnet

Network debugging is supported on the following NICs:

busparams=141.0.0, Mellanox ConnectX-4 Lx Ethernet Adapter #2, KDNET is running on this NIC.

Network debugging is supported on the following USB controllers:

busparams=128.15.0, Standard USB 3.0 eXtensible Host Controller - 1.0 (Microsoft)
busparams=0.15.0, Standard USB 3.0 eXtensible Host Controller - 1.0 (Microsoft)
busparams=128.15.1, Standard USB 3.0 eXtensible Host Controller - 1.0 (Microsoft)
busparams=0.15.1, Standard USB 3.0 eXtensible Host Controller - 1.0 (Microsoft)

2. If the debug value is set to Yes, use the set command to disable debugging.

C:\> bcdedit.exe /debug off

C:\> bcdedit.exe /set {default} bootdebug off
C:\> bcdedit.exe /set {bootmgr} bootdebug off

3. Use the shutdown -r -t 0 command from an administrator's command prompt to reboot.

After the target PC restarts, and debugging is disabled, we can add the new physical function.
Add the new physical function
1. Open an elevated command prompt and run the following command to add a second PF. All values are
provided using decimal values.
 C:\KDNET> kdnet -addpf 141.0.0 198.51.100.1 50001

Succeeded adding a Pci PF on :141.0.1. Please power off or reboot the machine.

Enabling network debugging on Mellanox ConnectX-4 Lx Ethernet Adapter #2.

Manage-bde.exe not present. Bitlocker presumed disabled.

To debug this machine, run the following command on your debugger host machine.
windbg -k net:port=50001,key=2steg4fzbj2sz.23418vzkd4ko3.1g34ou07z4pev.1sp3yo9yz874p

Then reboot this machine by running shutdown -r -t 0 from this command prompt.

bus.dev.fun is the PCI location port of the NIC adapter that supports the multiple PF feature, so the new PF will
be added/attached to this network device.
-addpf option enables automatically kernel debugging over KDNET transport on the added PF port.
[host name/host ip address] is the TCP/IP address of the host computer. Use the ipconfig command on the
host computer to determine this address.
[port number] is the TCP/IP port number. You can choose any port number from 49152 through 65535. The
recommended range is between 50000 and 50039. The port that you choose will be opened for exclusive access
by the debugger running on the host computer. Pick a unique port address for each target/host pair that you
work with, within the recommended range of 50000-50039. 50005 is shown in the example.
Note that -addpf will also add the NO_KDNIC attribute to the OS installation {default} loadoptions. This is because
KDNIC is no longer required to run on top of KDNET.
The loadoptions = NO_KDNIC is added to {default} OS tag to ensure that kdnic.sys won't run out of the new
added pf (141.0.1)
Use the bcdedit command to confirm that NO_KDNIC has been set.
 C:\KDNET> bcdedit /enum {default}

Windows Boot Loader

-------------------
identifier {current}
device partition=C:
path \Windows\system32\winload.efi
description Windows Server
locale en-US
loadoptions NO_KDNIC
inherit {bootloadersettings}
recoverysequence {c23c4005d-12ae-11eb-9399-ac9840c152e7}
displaymessageoverride Recovery
recoveryenabled Yes
bootdebug No
testsigning Yes
isolatedcontext Yes
flightsigning Yes
allowedinmemorysettings 0x15000075
osdevice partition=C:
systemroot \Windows
resumeobject {c23c4005d-12ae-11eb-9399-ac9840c152e7}
nx OptOut
debug Yes
hypervisordebug No

2. Run the bcdedit /enum command to display the generated key.

```console
C:\KDNET> bcdedit /dbgsettings
busparams 141.0.1
key 2steg4fzbj2sz.23418vzkd4ko3.1g34ou07z4pev.1sp3yo9yz874p
debugtype NET
hostip 198.51.100.1
port 50001
dhcp Yes
The operation completed successfully.

3. Copy the returned key into a notepad .txt file. In the example shown, the generated key has a value of:
2steg4fzbj2sz.23418vzkd4ko3.1g34ou07z4pev.1sp3yo9yz874p

4. Optionaly use kdnet.exe to confirm that the multiple physical functions are enabled.

C:\KDNET> kdnet.exe

Network debugging is supported on the following NICs:

busparams=141.0.0, Mellanox ConnectX-4 Lx Ethernet Adapter #2, Plugged in, Primary function, multiple
physical functions are enabled.
busparams=141.0.1, Mellanox ConnectX-4 Lx Ethernet Adapter, KDNET is running on this NIC, Secondary
function.

Network debugging is supported on the following USB controllers:

busparams=128.15.0, Standard USB 3.0 eXtensible Host Controller - 1.0 (Microsoft)
busparams=0.15.0, Standard USB 3.0 eXtensible Host Controller - 1.0 (Microsoft)
busparams=128.15.1, Standard USB 3.0 eXtensible Host Controller - 1.0 (Microsoft)
busparams=0.15.1, Standard USB 3.0 eXtensible Host Controller - 1.0 (Microsoft)

Disable the firewall on the host

On the host, disable the firewall for the debugger port.
Connecting WinDbg to the target for kernel debugging
On the host computer, open WinDbg. On the File menu, choose Kernel Debug . In the Kernel Debugging dialog
box, open the Net tab. Paste in your port number and key that you saved to in the notepad .txt file earlier. Select
OK .
You can also start a WinDbg session by opening a Command Prompt window and entering the following
command, where is the port you selected above, and is the key that was returned by kdnet.exe above. Paste in
the key in that you saved to in the notepad .txt file earlier.
windbg -k -d net:port=<YourDebugPort>,key=<YourKey>

Reboot the target computer

Once the debugger is connected, reboot the target computer. One way to do reboot the PC, is to use the
shutdown -r -t 0 command from an administrator's command prompt.

After the target PC restarts, the debugger should connect automatically.

Once the machine rebooted, then the NIC firmware will assign a new MAC address to the new added KDNET PF,
and dbgsettings::busparams will point to the new added PF.

Finding the MAC address for the 2PF adapter

Since the new added PF is a PCI bus configured port, there will be a new MAC address value assigned to new
added PF by the NIC firmware. The kdnet.exe tool does not currently support displaying the MAC address for
the added 2PF.
There are two ways of finding the new MAC address:
Use WinDbg/KD with a local KD session
Run the local kernel debugger windbg.exe -kl on the target.
Make sure you have access to the kdnet.pdb symbol file by running .reload /f kdnet.dll
Run .kdtargetmac command to get the MAC address.

kd> .kdtargetmac
Force unload of kdnet.dll
ModLoad: fffff800`18510000 fffff800`18557000 kdnet.dll
Loading symbols for fffff800`18510000 kdnet.dll -> kdnet.dll

The target machine MAC address in open-device format is: DC9840C151E8

Run the vendor provided firmware tools

One way to locate the MAC address is to run the vendor provided firmware tools. Refer to the NIC vendor for
information on downloading, installing and using the vendor's tools.

...
Base MAC: 98039baa757c 4

Find the MAC address field. Calculate the KDNET 2PF MAC address value by sequentially adding one to the last
digit of the root MAC device. So for the root device with and address of 98039baa757c , the KDNET 2PF device
would have an address of 98039baa757d .

Restoring the previous configuration state - Removing the second PCI

PF
You can remove the previously added PF from a device by using the kdnet -removepf option and the original
bus.device.function value. The PF will be detached from the NIC and the PF assigned resource will be released by
the NIC firmware.
To remove the KDNET PF from the device, open an elevated command prompt and run the following command.
kdnet -removepf [bus.dev.fun] [host name/host ip address] [port number]

Where bus.dev.fun is the PCI location port of the NIC adapter where the PF was originally attached. This is the
same PCI location originally passed to kdnet -addpf.
Using the -removepf option also re-enables kernel debugging over KDNET on the original bus.dev.fun.

C:\KDNET> kdnet -removepf 141.0.0 198.51.100.1 50001

Succeeded removing a Pci PF on :141.0.0. Please power off or reboot the machine.

Enabling network debugging on Mellanox ConnectX-4 Lx Ethernet Adapter #2.

Manage-bde.exe not present. Bitlocker presumed disabled.

The kdnet.exe -removepf command also will remove the NO_KDNIC attribute from the OS installation {default}
loadoptions, since KDNET will be enabled on the original bus.dev.fun, that is the dbgsettings::busparams will
point to the original network port. This will cause KDNIC to be used again, providing a network connection again
on top of KDNET.
Once the PF is removed the machine needs to be rebooted for the BCD changes to be applied.

shutdown -r -t 0

Troubleshooting host adapter configuration

Verify the 2PF adapter is present in device manager
You can verify that the KDNET PF was added successfully by checking the new NIC adapter has a new
bus.dev.fun port on Windows Device manager adapter list.
This diagram shows three different adapters, with Adapter #2 reserved for use by the kernel debugger.

Common error messages - adding a new PF

 C:\KDNET> kdnet -addpf 28.0.0 192.168.137.1 50005

Device Name:\\.\Mlx5Util

Pci Bus:28.0.0

The PCI PF is already configured on this por t : Error=(0x80004004) Failed PF operation on the debug
device. The debug device is not configured for KDNET.
Do not add/remove again a PF on the root port where it is already added as a PF.
Common error messages - removing a PF

C:\KDNET> kdnet -removepf 28.0.1 192.168.137.1 50005

Adapter is not active: Error=(0x80070002)

Device Name:\\.\Mlx5Util

Pci Bus:28.0.1

Adapter is not active : Error=(0x80070002) Failed PF operation on the debug device. The debug device is not
configured for KDNET
Do not use an added PF port with the “-removepf/-addpf” command line parameter, because any operation
on the added PF port will result in a failure (error: Adapter is not active on port), since the vendor NIC inbox
driver is set up to expressly not run on an added PF.
Both command line options (-addpf/-removepf) must be used only on the root PCI device.

C:\KDNET> kdnet -removepf 28.0.0 192.168.137.1 50005

Device Name:\\.\Mlx5Util

Pci Bus:28.0.0

There is no PCI PF to remove on this por t : Error=(0x80004005) Failed PF operation on the debug device.
The debug device is not configured for KDNET
If you add a new PF and then decide to remove it w/o rebooting it will result in a failure, since the vendor NIC
firmware requires a rebooting/resetting the NIC HW before it can recognize the new added PF.
Common error messages - BCDEdit
NO_KDNIC is not present in the BCD OS {default} installation.
It is not recommended to use bcdedit.exe to modify/change the debug device (dbgsettings) after adding a
new PF. The kdnet -addpf/removepf command line options will configure the debug device and will also
add/remove automatically the NO_KDNIC token to/from the {default}::loadoptions .

Related topics
Setting Up KDNET Network Kernel Debugging Automatically
Setting Up KDNET Network Kernel Debugging Manually
Setting Up Kernel-Mode Debugging over a USB 3.0 Cable Manually
Setting Up Kernel-Mode Debugging Manually
 Setting Up Kernel-Mode Debugging over USB EEM
on an ARM device using KDNET
6/16/2021 • 4 minutes to read • Edit Online

Debugging Tools for Windows supports kernel debugging over a USB cable using EEM on an ARM device. This
topic describes how to set up USB EEM on an ARM device using the kdnet.exe utility.
The computer that runs the debugger is called the host computer, and the computer being debugged is called
the target computer.

Kernel-Mode USB EEM ARM device requirements

The following is required:
On the target computer, a Synopsys USB 3.0 controller connected to an USB type C port.
On the host computer, a USB 2.0 or a USB 3.0 port is required.
A standard USB 3.0 Type C to Type A cable is required to connect the host type A port to the target type C
port.
Windows 10 October 2020 Update (20H2) or later

Confirm that a supported USB controller is available on the target

On the target computer, launch Device Manager.
Confirm that the Synopsys USB 3.0 Dual-Role Controller is listed.

Determine the debugging port when multiple ports are available

After you have identified a port that supports debugging, the next step is to locate the physical USB connector
that is associated with that port.
On the Surface Pro X, use the lower of the two USB C ports is used for KDNET EEM debugging.
Use kdnet.exe to confirm device support and view the busparams
value
To specify the debugging port that will be used, busparm is used. Typically just the first busparam is used and it’s
either 0 or 1 depending on the device.
ARM devices use ACPI DBG2 table for configuring the debugger, where the busparams points to the DBG2 table
entry. Typically, devices don't use busparams=0, since the 0 DBG2 table entry is normally reserved for the serial
device COM.
Use the kdnet.exe utility to display the parameter information for controllers that support KDNET-EEM-USB
transport debugging.
1. Confirm that the Windows Debugging Tools are installed on the host system. For information on
downloading and installing the debugger tools, see Download Debugging Tools for Windows.
2. Locate the kdnet.exe and VerifiedNICList.xml files. By default, they are located here.
C:\Program Files (x86)\Windows Kits\10\Debuggers\x64

3. On the host computer, copy the two files to a network share or thumb drive, so that they will be available
on the target computer.
4. On the target computer, create a C:\KDNET directory and copy the kdnet.exe and VerifiedNICList.xml files
to that directory.
5. On the target computer, open a Command Prompt window as Administrator. Enter this command to
verify that the target computer has a supported network adapter and to view the busparams value.

C:\KDNET>kdnet.exe

Network debugging is not supported on any of the NICs in this machine.

KDNET supports NICs from Intel, Broadcom, Realtek, Atheros, Emulex, Mellanox
and Cisco.

Network debugging is supported on the following USB controllers:

busparams=1, Device-mode USB controller with Vendor ID: 5143 (Default)
busparams=2, Device-mode USB controller with Vendor ID: 5143
busparams=3, Device-mode USB controller with Vendor ID: 5143
busparams=4, Device-mode USB controller with Vendor ID: 5143

This Microsoft hypervisor supports using KDNET in guest VMs.

6. As the output from kdnet.exe indicates that a supported USB controller with a busparams value of 1 is
available, we can proceed.
Setting Up the Target Computer
Use the kdnet.exe utility to configure the debugger settings on the target PC, by following these steps.

IMPORTANT
Before using bcdedit to change boot information you may need to temporarily suspend Windows security features such
as BitLocker and Secure Boot on the test PC. You can re-enable Bit Locker and Secure Boot once you’re done using
BCDEdit to update the boot information. Appropriately manage the test PC, when the security features are disabled.

1. Use the command shown below to set the, busparams value, the IP address and the port of the host
system and generated a unique connection key. The 169.254.255.255 IP address is used for all USB EMM
connections.
2. Pick a unique port address for each target/host pair that you work with, within the recommended range
of 50000-50039. 50005 is shown in the example.

C:\>kdnet.exe 169.254.255.255 50005

Enabling network debugging on Intel(R) 82577LM Gigabit Network Connection.

Key=2steg4fzbj2sz.23418vzkd4ko3.1g34ou07z4pev.1sp3yo9yz874p

3. Copy the returned key into a notepad .txt file. In the example shown, the generated key has a value of:
2steg4fzbj2sz.23418vzkd4ko3.1g34ou07z4pev.1sp3yo9yz874p

4. Use the BCDEdit command to check that the parameters are as expected. For more information, see
BCDEdit /dbgsettings

C:\>bcdedit /dbgsettings

busparams 1
key 2steg4fzbj2sz.23418vzkd4ko3.1g34ou07z4pev.1sp3yo9yz874p
debugtype NET
hostip 169.254.255.255
port 50005
dhcp No
The operation completed successfully.

Disable the firewall on the host

On the host, disable the firewall for the debugger.

Connecting WinDbg to the target for kernel debugging

On the host computer, open WinDbg. On the File menu, choose Kernel Debug . In the Kernel Debugging dialog
box, open the Net tab. Paste in your port number and key that you saved to in the notepad .txt file earlier. Select
OK .
You can also start a WinDbg session by opening a Command Prompt window and entering the following
command, where is the port you selected above, and is the key that was returned by kdnet.exe above. Paste in
the key in that you saved to in the notepad .txt file earlier.
windbg -k -d net:port=<YourDebugPort>,key=<YourKey>
Reboot the target computer
Once the debugger is connected, reboot the target computer. One way to do reboot the PC, is to use the
shutdown -r -t 0 command from an administrator's command prompt.

After the target PC restarts, the debugger should connect automatically.

Troubleshooting Target
Confirm that the Windows KDNET-USB-EMM Network Adapter is present under Network Adapters in Windows
Device Manager.
The device properties show when the controller is reserved for use by the Windows kernel debugger.

Troubleshooting Host
Confirm that the Windows KDNET-USB-EMM Network Adapter is present under Network Adapters in Windows
Device Manager.
On the host the KDNET-EEM connection using the USB Type A port is shown.

Related topics
Setting Up KDNET Network Kernel Debugging Automatically
Setting Up KDNET Network Kernel Debugging Manually
Setting Up Kernel-Mode Debugging over a USB 3.0 Cable Manually
Setting Up Kernel-Mode Debugging Manually
 Setting Up Kernel-Mode Debugging over a USB 3.0
Cable Manually
3/5/2021 • 6 minutes to read • Edit Online

Debugging Tools for Windows supports kernel debugging over a USB 3.0 cable. This topic describes how to set
up USB 3.0 debugging manually.
The computer that runs the debugger is called the host computer, and the computer being debugged is called
the target computer.
Debugging over a USB 3.0 cable requires the following hardware:
A USB 3.0 debug cable. This is an A-A crossover cable that has only the USB 3.0 lines and no Vbus.
On the host computer, an xHCI (USB 3.0) host controller
On the target computer, an xHCI (USB 3.0) host controller that supports debugging

Setting Up the Target Computer

1. On the target computer, launch the UsbView tool. The UsbView tool is included in Debugging Tools for
Windows.
2. In UsbView, locate all of the xHCI host controllers.
3. In UsbView, expand the nodes of the xHCI host controllers. Look for an indication that a port on the host
controller supports debugging.

[Port1]

Is Port User Connectable: yes

Is Port Debug Capable: yes
Companion Port Number: 3
Companion Hub Symbolic Link Name: USB#ROOT_HUB30#5&32bab638&0&0#{...}
Protocols Supported:
USB 1.1: no
USB 2.0: no
USB 3.0: yes

4. Make a note of the bus, device, and function numbers for the xHCI controller that you intend to use for
debugging. UsbView displays these number. In the following example, the bus number is 48, the device
number is 0, and the function number is 0.

USB xHCI Compliant Host Controller

...
DriverKey: {36fc9e60-c465-11cf-8056-444553540000}\0020
...
Bus.Device.Function (in decimal): 48.0.0

5. After you have identified an xHCI controller that supports debugging, the next step is to locate the
physical USB connector that is associated with a port on the xHCI controller. To find the physical
connector, plug any USB 3.0 device into any USB connector on the target computer. Refresh UsbView to
see where your device is located. If UsbView shows your device connected to your chosen xHCI host
 controller, then you have found a physical USB connector that you can use for USB 3.0 debugging.

IMPORTANT
Before using bcdedit to change boot information you may need to temporarily suspend Windows security features such
as BitLocker and Secure Boot on the test PC. You can re-enable Secure Boot once you’re done debugging and you’ve
disabled kernel debugging.

6. On the target computer, open a Command Prompt window as Administrator, and enter these commands:
bcdedit /debug on
bcdedit /dbgsettings usb targetname:TargetName
where TargetName is a name that you create for the target computer. Note that TargetName does not
have to be the official name of the target computer; it can be any string that you create as long as it
meets these restrictions:
The string must not contain “debug” anywhere in the TargetName in any combination of upper or
lower case. For example if you use “DeBuG” or "DEBUG" anywhere in your targetname, debugging will
not work correctly.
The only characters in the string are the hyphen (-), the underscore(_), the digits 0 through 9, and the
letters A through Z (upper or lower case).
The maximum length of the string is 24 characters.
7. In Device Manager locate the USB Controller that you intend to use for debugging. Under Location on the
General tab, the bus, device, and function numbers are displayed. Enter this command:
bcdedit /set "{dbgsettings}" busparams b.d.f
where b, d, and f are the bus, device, and function numbers for the USB host controller. The bus, device,
and function numbers must be in decimal format.
Example:
bcdedit /set "{dbgsettings}" busparams 48.0.0
8. Reboot the target computer.
Disable Power Management
In some cases, power transitions can interfere with debugging over USB 3.0. To avoid these problems, disable
selective suspend for the xHCI host controller (and its root hub) that you are using for debugging.
1. In Device Manager, navigate to the node for the xHCI host controller. Right click the node, and choose
Proper ties . If there is a Power Management tab, open the tab, and clear the Allow the computer to
turn off this device to save power check box.
2. In Device Manager, navigate to the node for the root hub of the xHCI host controller. Right click the node,
and choose Proper ties . If there is a Power Management tab, open the tab, and clear the Allow the
computer to turn off this device to save power check box.
When you have finished using the xHCI host controller for debugging, re-enable selective suspend for the xHCI
host controller.

Starting a Debugging Session for the First Time

1. Connect a Universal Serial Bus (USB) 3.0 debug cable to the USB 3.0 ports that you have chosen for
debugging on the host and target computers.
2. Determine the bitness (32-bit or 64-bit) of Windows running on the host computer.
3. On the host computer, open a version of WinDbg (as Administrator) that matches the bitness of Windows
running on the host computer. For example, if the host computer is running a 64-bit version of Windows,
open the 64-bit version of WinDbg as Administrator.
4. On the File menu, choose Kernel Debug . In the Kernel Debugging dialog box, open the USB tab. Enter the
target name that you created when you set up the target computer. Click OK .
At this point, the USB debug driver gets installed on the host computer. This is why it is important to match the
bitness of WinDbg to the bitness of Windows. After the USB debug driver is installed, you can use either the 32-
bit or 64-bit version of WinDbg for subsequent debugging sessions.

Starting a Debugging Session

Using WinDbg
On the host computer, open WinDbg. On the File menu, choose Kernel Debug . In the Kernel Debugging dialog
box, open the USB tab. Enter the target name that you created when you set up the target computer. Click OK .
You can also start a session with WinDbg by entering the following command in a Command Prompt window,
where TargetName is the target name you created when you set up the target computer:
windbg /k usb:targetname= TargetName
Using KD
On the host computer, open a Command Prompt window and enter the following command, where TargetName
is the target name you created when you set up the target computer:
kd /k usb:targetname= TargetName
Reboot the target computer
Once the debugger is connected, reboot the target computer. One way to do reboot the PC, is to use the
shutdown -r -t 0 command from an administrator's command prompt.

After the target PC restarts, the debugger should connect automatically.

Troubleshooting
USB device not recognized
If a windows notification appears on the host with the text "USB device not recognized" when inserting the
debug cable it is possible that a known USB 3.1 to 3.1 compatibility issue is being hit. This issue affects debug
configurations when the debug cable is connected to a USB 3.1 controller on the host and an Intel (Ice Lake or
Tiger Lake) 3.1 USB controller on the target.
For more information and processor model listings see Ice Lake (microprocessor) - Wikipedia and or Tiger Lake
(microprocessor) - Wikipedia. To find the processor model of the target machine, open the Settings app and go
to "System" then "About". "Processor" will be listed under "Device specifications".
To verify this is the problem occurring, open device manager and look for "USB Debug Connection Device"
under "Universal Serial Bus controllers". If this device cannot be found, check for an "Unknown device" under
"Other devices". Right click on the device to open its properties page. The device status text box will have the text
"Windows has stopped this device because it has reported problems. (Code 43)" and "The USB device returned
an invalid USB BOS descriptor".
To work around this problem, run these commands from an administrator command prompt to make changes
to the registry:
 reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\usbflags\349500E00000 /v SkipBOSDescriptorQuery
/t REG_DWORD /d 1 /f
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\usbflags\045E06560000 /v SkipBOSDescriptorQuery
/t REG_DWORD /d 1 /f

Then, remove and re-insert the debug cable.

Related topics
Setting Up Kernel-Mode Debugging Manually
 Setting Up Kernel-Mode Debugging over a USB 2.0
Cable Manually
6/16/2021 • 7 minutes to read • Edit Online

Debugging Tools for Windows supports kernel debugging over a USB 2.0 cable. This topic describes how to set
up USB 2.0 debugging manually.
The computer that runs the debugger is called the host computer, and the computer being debugged is called
the target computer.
Debugging over a USB 2.0 cable requires the following hardware:
A USB 2.0 debug cable. This cable is not a standard USB 2.0 cable because it has an extra hardware
component that makes it compatible with the USB2 Debug Device Functional Specification. You can find
these cables with an Internet search for the term USB 2.0 debug cable.
On the host computer, an EHCI (USB 2.0) host controller
On the target computer, an EHCI (USB 2.0) host controller that supports debugging

Setting Up the Target Computer

1. On the target computer, launch the UsbView tool. The UsbView tool is included in Debugging Tools for
Windows.
2. In UsbView, locate all of the host controllers that are compatible with the EHCI specification. For example,
you could look for controllers that are listed as Enhanced.
3. In UsbView, expand the nodes of the EHCI host controllers. Look for an indication that a host controller
supports debugging, and look for the number of the debug port. For example, UsbView displays this
output for an EHCI host controller that supports debugging on port 1.

Xxx xxx xxx USB2 Enhanced Host Controller - 293A

...
Debug Port Number: 1
Bus.Device.Function (in decimal): 0.29.7

Note Many EHCI host controllers support debugging on port 1, but some EHCI host controllers support
debugging on port 2.
4. Make a note of the bus, device, and function numbers for the EHCI controller that you intend to use for
debugging. UsbView displays these number. In the preceding example, the bus number is 0, the device
number is 29, and the function number is 7.
5. After you have identified the EHCI controller and the port number that supports debugging, the next step
is to locate the physical USB connector that is associated with the correct port number. To find the
physical connector, plug any USB 2.0 device into any USB connector on the target computer. Refresh
UsbView to see where your device is located. If UsbView shows your device connected to the EHCI host
controller and port that you identified as the debug port, then you have found a physical USB connector
that you can use for debugging. It could be that there is no external physical USB connector that is
associated with a debug port on an EHCI controller. In that case, you can look for a physical USB
connector inside the computer. Perform the same steps to determine whether the internal USB connector
 is suitable for kernel debugging. If you cannot find a physical USB connector (either external or internal)
that is associated with a debug port, then you cannot use the computer as a target for debugging over a
USB 2.0 cable.
Note See this remark for an exception.

IMPORTANT
Before using bcdedit to change boot information you may need to temporarily suspend Windows security features such
as BitLocker and Secure Boot on the test PC. You can re-enable Secure Boot once you’re done debugging and you’ve
disabled kernel debugging.

6. On the target computer, open a Command Prompt window as Administrator, and enter these commands:
bcdedit /debug on
bcdedit /dbgsettings usb targetname:TargetName
where TargetName is a name that you create for the target computer. Note that TargetName does not
have to be the official name of the target computer; it can be any string that you create as long as it
meets these restrictions:
The string must not contain “debug” anywhere in the TargetName in any combination of upper or
lower case. For example if you use “DeBuG” or "DEBUG" anywhere in your targetname, debugging will
not work correctly.
The only characters in the string are the hyphen (-), the underscore(_), the digits 0 through 9, and the
letters A through Z (upper or lower case).
The maximum length of the string is 24 characters.
7. In Device Manager locate the USB Controller that you intend to use for debugging. Under Location on the
General tab, the bus, device, and function numbers are displayed. Enter this command:
bcdedit /set "{dbgsettings}" busparams b.d.f
where b, d, and f are the bus, device, and function numbers for the host controller. The bus, device, and function
numbers must be in decimal format (for example, busparams 0.29.7 ).
8. Reboot the target computer.

Setting Up the Host Computer

1. Verify that the host computer is not configured to be the target of USB debugging. (If necessary, open a
Command Prompt window as Administrator, enter bcdedit /debug off , and reboot.)
2. On the host computer, use UsbView to find the EHCI host controllers and ports that support debugging. If
possible, plug one end of the USB 2.0 debug cable into an EHCI port (on the host computer) that does not
support debugging. Otherwise, plug the cable into any EHCI port on the host computer.
3. Plug the other end of the USB 2.0 debug cable into the connector that you identified previously on the target
computer.

Starting a Debugging Session for the First Time

1. Determine the bitness (32-bit or 64-bit) of Windows running on the host computer.
2. On the host computer, open a version of WinDbg (as Administrator) that matches the bitness of Windows
running on the host computer. For example, if the host computer is running a 64-bit version of Windows,
open the 64-bit version of WinDbg as Administrator.
3. On the File menu, choose Kernel Debug . In the Kernel Debugging dialog box, open the USB tab. Enter the
target name that you created when you set up the target computer. Click OK .
At this point, the USB debug driver gets installed on the host computer. This is why it is important to match the
bitness of WinDbg to the bitness of Windows. After the USB debug driver is installed, you can use either the 32-
bit or 64-bit version of WinDbg for subsequent debugging sessions.
Note The USB 2.0 debug cable is actually two cables with a dongle in the middle. The direction of the dongle is
important; one side powers the device, and the other side does not. If USB debugging doesn’t work, try
swapping the direction of the dongle. That is, unplug both cables from the dongle, and swap the sides that the
cables are connected to.

Starting a Debugging Session

Using WinDbg
On the host computer, open WinDbg. On the File menu, choose Kernel Debug . In the Kernel Debugging dialog
box, open the USB tab. Enter the target name that you created when you set up the target computer. Click OK .
You can also start a session with WinDbg by entering the following command in a Command Prompt window,
where TargetName is the target name you created when you set up the target computer:
windbg /k usb:targetname= TargetName
Using KD
On the host computer, open a Command Prompt window and enter the following command, where TargetName
is the target name you created when you set up the target computer:
kd /k usb:targetname= TargetName

What if USBView shows a debug-capable port, but does not show the
port mapped to any physical connector?
On some computers, USBView shows a debug-capable port, but does not show the port mapped to any physical
USB connector. For example, USBView might show port 2 as the debug port number for an eHCI controller.

... USB Enhanced Host Controller ...

...
Debug Port Number: 2
Bus.Device.Function (in decimal): 0.29.0

Also, when you use USBView to look at the individual port, it is listed as debug-capable.

[Port 2]
Is Port User Connectiable: Yes
Is Port Debug Capable: Yes
...
Protocols Supported
USB 1.1 yes
USB 2.0 yes
USB 3.0 no

But when you plug in a USB 2.0 device (like a flash drive) to all the USB connectors on the computer, USBView
never show your device connected to the debug-capable port (port 2 in this example). USBView might show the
external connector mapped to a port of an xHCI controller when in fact the external connector is mapped to the
debug-capable port of the eHCI controller.
In a case like this, you might still be able to establish kernel-mode debugging over a USB 2.0 cable. In the
example given here, you would plug your USB 2.0 debug cable into the connector that shows as being mapped
to Port 2 of the xHCI controller. Then you would set your bus parameters to the bus, device, and function
numbers of the eHCI controller (in this example, 0.29.0).
bcdedit /set "{dbgsettings}" busparams 0.29.0

Additional Support
For troubleshooting tips and other information see the Microsoft USB Blog.

Related topics
Setting Up Kernel-Mode Debugging Manually
 Setting Up Kernel-Mode Debugging over a 1394
Cable Manually
3/5/2021 • 4 minutes to read • Edit Online

IMPORTANT
The 1394 transport is available for use in Windows 10, version 1607 and earlier. It is not available in later versions of
Windows. You should transition your projects to other transports, such as KDNET using Ethernet. For more information
about that transport, see Setting Up KDNET Network Kernel Debugging Automatically.

Debugging Tools for Windows supports kernel debugging over a 1394 (Firewire) cable. This topic describes how
to set up 1394 debugging manually.
The computer that runs the debugger is called the host computer, and the computer being debugged is called
the target computer. The host and target computers must each have a 1394 adapter and must be running
Windows XP or later. The host and target computers do not have to be running the same version of Windows.

Setting Up the Target Computer

1. Connect a 1394 cable to the 1394 controllers that you have chosen for debugging on the host and target
computers.

IMPORTANT
Before using BCDEdit to change boot information you may need to temporarily suspend Windows security features such
as BitLocker and Secure Boot on the test PC. Re-enable these security features when testing is complete and appropriately
manage the test PC, when the security features are disabled.

2. In an elevated Command Prompt window, enter the following commands, where n is a channel number
of your choice, from 0 through 62:
bcdedit /debug on
bcdedit /dbgsettings 1394 channel:n
3. You must specify the bus, device, and function numbers of the 1394 controller that you intend to use for
debugging. For more information, see Troubleshooting Tips for 1394 Debugging.
4. Do not reboot the target computer yet.

Starting a Debugging Session for the First Time

1. Determine the bitness (32-bit or 64-bit) of Windows running on the host computer.
2. On the host computer, open a version of WinDbg (as Administrator) that matches the bitness of Windows
running on the host computer. For example, if the host computer is running a 64-bit version of Windows,
open the 64-bit version of WinDbg as Administrator.
3. On the File menu, choose Kernel Debug . In the Kernel Debugging dialog box, open the 1394 tab. Enter
your channel number, and click OK .
 At this point, the 1394 debug driver gets installed on the host computer. This is why it is important to
match the bitness of WinDbg to the bitness of Windows. After the 1394 debug driver is installed, you can
use either the 32-bit or 64-bit version of WinDbg for subsequent debugging sessions.
4. Reboot the target computer.

Starting a Debugging Session

Using WinDbg
On the host computer, open WinDbg. On the File menu, choose Kernel Debug . In the Kernel Debugging
dialog box, open the 1394 tab. Enter your channel number, and click OK .
You can also start a session with WinDbg by entering the following command in a Command Prompt
window, where n is your channel number:
windbg /k 1394:channel= n
Using KD
On the host computer, open a Command Prompt window and enter the following command, where n is
your channel number:
kd /k 1394:channel= n

Using Environment Variables

On the host computer, you can use environment variables to specify the 1394 channel. Then you do not have to
specify the channel each time you start a debugging session. To use environment variables to specify the 1394
channel, open a Command Prompt window and enter the following commands, where n is your channel
number:
set _NT_DEBUG_BUS=1394
set _NT_DEBUG_1394_CHANNEL= n
To start a debugging session, open a Command Prompt window and enter one of the following commands:
kd
windbg

Additional Information
For complete documentation of the bcdedit command and the boot.ini file, see Boot Options for Driver Testing
and Debugging in the Windows Driver Kit (WDK) documentation.

Troubleshooting Tips for Debugging over a 1394 Cable

Most 1394 debugging problems are caused by using multiple 1394 controllers in either the host or target
computer. Using multiple 1394 controllers in the host computer is not supported. The 1394 debug driver, which
runs on the host, can communicate only with the first 1394 controller enumerated in the registry. If you have a
1394 controller built into the motherboard and a separate 1394 card, either remove the card or disable the
built-in controller in the BIOS settings of the computer.
The target computer can have multiple 1394 controllers, although this is not recommended. If your target
computer has a 1394 controller on the motherboard, use that controller for debugging, if possible. If there is an
additional 1394 card, you should remove the card and use the onboard controller. Another solution is to disable
the onboard 1394 controller in the BIOS settings of the computer.
If you decide to have multiple 1394 controllers enabled on the target computer, you must specify bus
parameters so that the debugger knows which controller to claim for debugging. To specify the bus parameters,
Open Device Manager on the target computer, and locate the 1394 controller that you want to use for
debugging. Open the property page for the controller, and make a note of the bus number, device number, and
function number. In an elevated Command Prompt Window, enter the following command, where b, d, and f are
the bus, device and function numbers in decimal format:
bcdedit -set "{dbgsettings}" busparams b.d.f.
Reboot the target computer.

Related topics
Setting Up Kernel-Mode Debugging Manually
Setting Up KDNET Network Kernel Debugging Automatically
 Supported Ethernet NICs for Network Kernel
Debugging in Windows 10
6/15/2021 • 7 minutes to read • Edit Online

To do kernel debugging over an Ethernet network cable, the target computer must have a supported network
interface card (NIC).
During kernel debugging, the computer that runs the debugger is called the host computer, and the computer
being debugged is called the target computer. For more information, see Setting Up KDNET Network Kernel
Debugging Automatically.
To do kernel debugging over a network cable, the target computer must have a supported network adapter.
When the target computer is running Windows, the network adapters listed here are supported for kernel
debugging.

Version Information
This topic lists the supported adapters for the following versions of Windows
Windows 10, version 20H2 Build 19042

Adapter Support for Previous Releases of Windows 10

See these topics for information on supported versions of NICs in previous versions of Windows 10.
Supported Ethernet NICs for Network Kernel Debugging in Windows 10 - 2004
Supported Ethernet NICs for Network Kernel Debugging in Windows 10 - 1909
Supported Ethernet NICs for Network Kernel Debugging in Windows 10 - 1903
Supported Ethernet NICs for Network Kernel Debugging in Windows 10 - 1809
Supported Ethernet NICs for Network Kernel Debugging in Windows 10 - 1803
Supported Ethernet NICs for Network Kernel Debugging in Windows 10 - 1709
Supported Ethernet NICs for Network Kernel Debugging in Windows 10 - 1703
Determining NIC suppor t using VerifiedNicList.xml
To determine which set of NICs is supported for any particular release of Windows, examine the
VerifiedNicList.xml file that is in the debuggers directory installed by the WDK that shipped with that
particular release of Windows. For 64 bit Windows, by default, it will be installed in this directory:
C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\VerifiedNicList.xml

Checking the VerifiedNicList.xml that ships in the WDK for a particular release, is required because additional
hardware support is added to new releases of Windows that is not present in previous releases. So you must
check the VerifiedNicLIst.xml file for that particular release.

Finding the vendor ID and device ID

To find the vendor ID and device ID of the network adapter on your target computer.
 On the target computer, open Device Manager (enter devmgmt in a Command Prompt window).
In Device Manager, locate the network adapter that you want to use for debugging.
Select and hold (or right-click) the network adapter node, and choose Proper ties .
In the Details tab, under Proper ty , select Hardware Ids .
The vendor and device IDs are shown as VEN_VendorID and DEV_DeviceID. For example, if you see
PCI\VEN_8086&DEV_104B, the vendor ID is 8086, and the device ID is 104B.
Vendor ID 8086, Intel Corporation
For vendor ID 8086, these device IDs are supported:
0001 0008 000C 000D 0438 043A 043C 0440 0470 0D4E 0D4F 0D4C 0D4D 0D53 0D55 1000 1001 1004 1008
1009 100C 100D 100E 100F 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 101A 101D 101E 1026
1027 1028 1049 104A 104B 104C 104D 105E 105F 1060 1071 1075 1076 1077 1078 1079 107A 107B 107C
107D 107E 107F 108A 108B 108C 1096 1098 1099 109A 10A4 10A5 10A7 10A9 10B5 10B9 10BA 10BB 10BC
10BD 10BF 10C0 10C2 10C3 10C4 10C5 10C6 10C7 10C8 10C9 10CB 10CC 10CD 10CE 10D3 10D5 10D6
10D9 10DA 10DB 10DD 10DE 10DF 10E1 10E5 10E6 10E7 10E8 10EA 10EB 10EC 10EF 10F0 10F1 10F4 10F5
10F6 10F7 10F8 10F9 10FB 10FC 11A9 1501 1502 1503 1507 150A 150B 150C 150D 150E 150F 1510 1511
1514 1516 1517 1518 151C 1521 1522 1523 1524 1525 1526 1527 1528 1529 152A 1533 1534 1535 1536
1537 1538 1539 153A 153B 1546 154A 154D 1557 1558 1559 155A 1560 1563 156F 1570 157B 157C 15A0
15A1 15A2 15A3 15AA 15AB 15AC 15AD 15AE 15B7 15B8 15B9 15BB 15BC 15BD 15BE 15D6 15D7 15D8
15DF 15E0 15E1 15E2 15E3 15F4 15F9 15FA 15FB 15FC 17D0 1F40 1F41 1F45 1F63 1F72 211B 2159 294C
8976
Vendor ID 10EC, Realtek Semiconductor Corp.
For vendor ID 10EC, these device IDs are supported:
2502 2600 3000 8125 8136 8137 8161 8166 8167 8168 8169 8225
Vendor ID 14E4, Broadcom
For vendor ID 14E4, these device IDs are supported:
1600 1601 1614 1639 163A 163B 163C 163D 163E 1641 1642 1643 1644 1645 1646 1647 1648 164A 164C
164D 164E 164F 1650 1653 1654 1655 1656 1657 1659 165A 165B 165C 165D 165E 165F 1662 1663 1665
1668 1669 166A 166B 166D 166E 1672 1673 1674 1676 1677 1678 1679 167A 167B 167C 167D 167F 168A
168D 168E 1680 1681 1682 1683 1684 1686 1687 1688 1690 1691 1692 1693 1694 1696 1698 1699 169A
169B 169D 16A0 16A1 16A2 16A4 16A5 16A6 16A7 16A8 16AA 16AC 16AE 16B0 16B1 16B2 16B3 16B4 16B5
16B6 16B7 16C6 16C7 16C9 16CA 16CE 16CF 16D0 16D1 16D2 16D5 16D6 16D7 16D8 16D9 16DD 16DF
16E0 16E2 16E3 16E4 16E9 16F0 16F1 16F7 16FD 16FE 16FF 170D 170E 170F D802
Vendor ID 1969, Atheros Communications
For vendor ID 1969, these device IDs are supported:
1062 1063 1073 1083 1090 1091 10A0 10A1 10B0 10B1 10C0 10C1 10D0 10D1 10E0 10E1 10F0 10F1 2060
2062 E091 E0A1 E0B1 E0C1 E0D1 E0E1 E0F1
Vendor ID 19A2, ServerEngines (Emulex)
For vendor ID 19A2, these device IDs are supported:
0211 0215 0221 0700 0710
Vendor ID 10DF, Emulex Corporation
For vendor ID 10DF, these device IDs are supported:
0720 E220
Vendor ID 15B3, Mellanox Technology
For vendor ID 15B3, these device IDs are supported:
1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 100A 100B 100C 100D 100E 100F 1010 1013 1015
1017 1019 101B 101D 101F 1021 1023 1025 1027 1029 102B 102F 6340 6341 634A 634B 6354 6368 6369
6372 6732 6733 673C 673D 6746 6750 6751 675A 6764 6765 676E 6778
Vendor ID 1137, Cisco Systems Inc
For vendor ID 1137, these device IDs are supported:
0043

XML Supported NIC List

This is the same information shown above in the XML format.

<?xml version="1.0" encoding="utf-8"?>

<SupportedNetworkInterfaceCards>
<NIC>
<manufacturer>8086</manufacturer>
<deviceid>1000</deviceid>
<deviceid>1001</deviceid>
<deviceid>1004</deviceid>
<deviceid>1008</deviceid>
<deviceid>1009</deviceid>
<deviceid>100C</deviceid>
<deviceid>100D</deviceid>
<deviceid>100E</deviceid>
<deviceid>1015</deviceid>
<deviceid>1016</deviceid>
<deviceid>1017</deviceid>
<deviceid>101E</deviceid>
<deviceid>100F</deviceid>
<deviceid>1011</deviceid>
<deviceid>1026</deviceid>
<deviceid>1027</deviceid>
<deviceid>1028</deviceid>
<deviceid>1010</deviceid>
<deviceid>1012</deviceid>
<deviceid>101D</deviceid>
<deviceid>1079</deviceid>
<deviceid>107A</deviceid>
<deviceid>107B</deviceid>
<deviceid>108A</deviceid>
<deviceid>1099</deviceid>
<deviceid>10B5</deviceid>
<deviceid>1013</deviceid>
<deviceid>1018</deviceid>
<deviceid>1014</deviceid>
<deviceid>1078</deviceid>
<deviceid>1076</deviceid>
<deviceid>107C</deviceid>
<deviceid>1077</deviceid>
<deviceid>1019</deviceid>
<deviceid>101A</deviceid>
<deviceid>1075</deviceid>
<deviceid>105E</deviceid>
<deviceid>105F</deviceid>
<deviceid>1060</deviceid>
<deviceid>10D9</deviceid>
<deviceid>10DA</deviceid>
<deviceid>10A4</deviceid>
<deviceid>10D5</deviceid>
<deviceid>10A5</deviceid>
<deviceid>10BC</deviceid>
<deviceid>107D</deviceid>
<deviceid>107E</deviceid>
<deviceid>107F</deviceid>
<deviceid>10B9</deviceid>
<deviceid>108B</deviceid>
<deviceid>108C</deviceid>
<deviceid>109A</deviceid>
<deviceid>10D3</deviceid>
<deviceid>10F6</deviceid>
<deviceid>150C</deviceid>
<deviceid>1096</deviceid>
<deviceid>1098</deviceid>
<deviceid>10BA</deviceid>
<deviceid>10BB</deviceid>
<deviceid>1501</deviceid>
<deviceid>1049</deviceid>
<deviceid>104A</deviceid>
<deviceid>104B</deviceid>
<deviceid>104C</deviceid>
<deviceid>10C4</deviceid>
<deviceid>10C5</deviceid>
<deviceid>104D</deviceid>
<deviceid>10BF</deviceid>
<deviceid>10F5</deviceid>
<deviceid>10CB</deviceid>
<deviceid>10BD</deviceid>
<deviceid>10E5</deviceid>
<deviceid>294C</deviceid>
<deviceid>10C0</deviceid>
<deviceid>10C3</deviceid>
<deviceid>10C2</deviceid>
<deviceid>10CC</deviceid>
<deviceid>10CD</deviceid>
<deviceid>10CE</deviceid>
<deviceid>10DE</deviceid>
<deviceid>10DF</deviceid>
<deviceid>1525</deviceid>
<deviceid>10EA</deviceid>
<deviceid>10EB</deviceid>
<deviceid>10EF</deviceid>
<deviceid>10F0</deviceid>
<deviceid>1502</deviceid>
<deviceid>1503</deviceid>
<deviceid>153A</deviceid>
<deviceid>153B</deviceid>
<deviceid>155A</deviceid>
<deviceid>1559</deviceid>
<deviceid>15A0</deviceid>
<deviceid>15A1</deviceid>
<deviceid>15A2</deviceid>
<deviceid>15A3</deviceid>
<deviceid>156F</deviceid>
<deviceid>1570</deviceid>
<deviceid>15B7</deviceid>
<deviceid>15B8</deviceid>
<deviceid>15B9</deviceid>
<deviceid>15D7</deviceid>
<deviceid>15D8</deviceid>
<deviceid>15E3</deviceid>
<deviceid>15D6</deviceid>
<deviceid>15BD</deviceid>
<deviceid>15BE</deviceid>
<deviceid>15BB</deviceid>
<deviceid>15BC</deviceid>
<deviceid>15DF</deviceid>
<deviceid>15E0</deviceid>
<deviceid>15E1</deviceid>
<deviceid>15E2</deviceid>
<deviceid>10C9</deviceid>
<deviceid>10C9</deviceid>
<deviceid>10E6</deviceid>
<deviceid>10E7</deviceid>
<deviceid>10E8</deviceid>
<deviceid>1526</deviceid>
<deviceid>150A</deviceid>
<deviceid>1518</deviceid>
<deviceid>150D</deviceid>
<deviceid>10A7</deviceid>
<deviceid>10A9</deviceid>
<deviceid>10D6</deviceid>
<deviceid>150E</deviceid>
<deviceid>150F</deviceid>
<deviceid>1510</deviceid>
<deviceid>1511</deviceid>
<deviceid>1516</deviceid>
<deviceid>1527</deviceid>
<deviceid>1521</deviceid>
<deviceid>1522</deviceid>
<deviceid>1523</deviceid>
<deviceid>1524</deviceid>
<deviceid>1546</deviceid>
<deviceid>1533</deviceid>
<deviceid>1534</deviceid>
<deviceid>1535</deviceid>
<deviceid>1536</deviceid>
<deviceid>1537</deviceid>
<deviceid>1538</deviceid>
<deviceid>157B</deviceid>
<deviceid>157C</deviceid>
<deviceid>1539</deviceid>
<deviceid>1F40</deviceid>
<deviceid>1F41</deviceid>
<deviceid>1F45</deviceid>
<deviceid>0438</deviceid>
<deviceid>043A</deviceid>
<deviceid>043C</deviceid>
<deviceid>0440</deviceid>
<deviceid>10C6</deviceid>
<deviceid>10C7</deviceid>
<deviceid>10C8</deviceid>
<deviceid>150B</deviceid>
<deviceid>10DB</deviceid>
<deviceid>10DD</deviceid>
<deviceid>10EC</deviceid>
<deviceid>10F1</deviceid>
<deviceid>10E1</deviceid>
<deviceid>10F4</deviceid>
<deviceid>10F7</deviceid>
<deviceid>1514</deviceid>
<deviceid>1517</deviceid>
<deviceid>10F8</deviceid>
<deviceid>000C</deviceid>
<deviceid>1F63</deviceid>
<deviceid>10F9</deviceid>
<deviceid>10FB</deviceid>
<deviceid>11A9</deviceid>
<deviceid>1071</deviceid>
<deviceid>1F72</deviceid>
<deviceid>17D0</deviceid>
<deviceid>0470</deviceid>
<deviceid>211B</deviceid>
<deviceid>8976</deviceid>
<deviceid>2159</deviceid>
<deviceid>000D</deviceid>
<deviceid>0008</deviceid>
<deviceid>152A</deviceid>
<deviceid>1529</deviceid>
<deviceid>1507</deviceid>
<deviceid>154D</deviceid>
 <deviceid>154D</deviceid>
<deviceid>154A</deviceid>
<deviceid>1558</deviceid>
<deviceid>1557</deviceid>
<deviceid>0001</deviceid>
<deviceid>10FC</deviceid>
<deviceid>151C</deviceid>
<deviceid>1528</deviceid>
<deviceid>1560</deviceid>
<deviceid>1563</deviceid>
<deviceid>ABCD</deviceid>
<deviceid>15AA</deviceid>
<deviceid>15AB</deviceid>
<deviceid>15AC</deviceid>
<deviceid>15AD</deviceid>
<deviceid>15AE</deviceid>
<deviceid>0D4E</deviceid>
<deviceid>0D4F</deviceid>
<deviceid>0D4C</deviceid>
<deviceid>0D4D</deviceid>
<deviceid>0D53</deviceid>
<deviceid>0D55</deviceid>
<deviceid>15FB</deviceid>
<deviceid>15FC</deviceid>
<deviceid>15F9</deviceid>
<deviceid>15FA</deviceid>
<deviceid>15F4</deviceid>
<deviceid>15F5</deviceid>
<deviceid>1A1E</deviceid>
<deviceid>1A1F</deviceid>
<deviceid>1A1C</deviceid>
<deviceid>1A1D</deviceid>
<deviceid>550A</deviceid>
<deviceid>550B</deviceid>
<deviceid>550C</deviceid>
<deviceid>550D</deviceid>
<deviceid>1572</deviceid>
<deviceid>1574</deviceid>
<deviceid>1580</deviceid>
<deviceid>1581</deviceid>
<deviceid>1583</deviceid>
<deviceid>1584</deviceid>
<deviceid>1585</deviceid>
<deviceid>1586</deviceid>
<deviceid>1587</deviceid>
<deviceid>1588</deviceid>
<deviceid>1589</deviceid>
<deviceid>158A</deviceid>
<deviceid>158B</deviceid>
<deviceid>37D0</deviceid>
<deviceid>37CC</deviceid>
<deviceid>37D2</deviceid>
<deviceid>37CE</deviceid>
<deviceid>37CF</deviceid>
<deviceid>37D0</deviceid>
<deviceid>37D1</deviceid>
<deviceid>37D2</deviceid>
<deviceid>37D3</deviceid>
<deviceid>37D4</deviceid>
</NIC>

<NIC>
<manufacturer>10EC</manufacturer>
<deviceid>8136</deviceid>
<deviceid>8137</deviceid>
<deviceid>8168</deviceid>
<deviceid>8167</deviceid>
<deviceid>8169</deviceid>
<deviceid>8166</deviceid>
<deviceid>8161</deviceid>
 <deviceid>8161</deviceid>
<deviceid>8125</deviceid>
<deviceid>8225</deviceid>
<deviceid>2502</deviceid>
<deviceid>2600</deviceid>
<deviceid>3000</deviceid>
</NIC>

<NIC>
<manufacturer>14E4</manufacturer>
<deviceid>1644</deviceid>
<deviceid>1645</deviceid>
<deviceid>1646</deviceid>
<deviceid>16A6</deviceid>
<deviceid>16C6</deviceid>
<deviceid>1647</deviceid>
<deviceid>16A7</deviceid>
<deviceid>16C7</deviceid>
<deviceid>164D</deviceid>
<deviceid>1648</deviceid>
<deviceid>16A8</deviceid>
<deviceid>1653</deviceid>
<deviceid>166E</deviceid>
<deviceid>1654</deviceid>
<deviceid>165D</deviceid>
<deviceid>165E</deviceid>
<deviceid>166D</deviceid>
<deviceid>170D</deviceid>
<deviceid>170E</deviceid>
<deviceid>1696</deviceid>
<deviceid>1676</deviceid>
<deviceid>1677</deviceid>
<deviceid>1659</deviceid>
<deviceid>167C</deviceid>
<deviceid>167D</deviceid>
<deviceid>169D</deviceid>
<deviceid>16F7</deviceid>
<deviceid>16FD</deviceid>
<deviceid>16FE</deviceid>
<deviceid>16DD</deviceid>
<deviceid>1668</deviceid>
<deviceid>1669</deviceid>
<deviceid>1678</deviceid>
<deviceid>1679</deviceid>
<deviceid>1600</deviceid>
<deviceid>1601</deviceid>
<deviceid>166A</deviceid>
<deviceid>166B</deviceid>
<deviceid>16FF</deviceid>
<deviceid>170F</deviceid>
<deviceid>169B</deviceid>
<deviceid>1693</deviceid>
<deviceid>167F</deviceid>
<deviceid>169A</deviceid>
<deviceid>1698</deviceid>
<deviceid>1692</deviceid>
<deviceid>1694</deviceid>
<deviceid>1690</deviceid>
<deviceid>1691</deviceid>
<deviceid>1699</deviceid>
<deviceid>16A0</deviceid>
<deviceid>167B</deviceid>
<deviceid>1673</deviceid>
<deviceid>165A</deviceid>
<deviceid>1674</deviceid>
<deviceid>1681</deviceid>
<deviceid>1680</deviceid>
<deviceid>1688</deviceid>
<deviceid>167A</deviceid>
<deviceid>1672</deviceid>
<deviceid>1672</deviceid>
<deviceid>1684</deviceid>
<deviceid>165B</deviceid>
<deviceid>16B1</deviceid>
<deviceid>16B5</deviceid>
<deviceid>16B0</deviceid>
<deviceid>16B4</deviceid>
<deviceid>16B2</deviceid>
<deviceid>16B6</deviceid>
<deviceid>1682</deviceid>
<deviceid>1686</deviceid>
<deviceid>16B3</deviceid>
<deviceid>16B7</deviceid>
<deviceid>1655</deviceid>
<deviceid>1665</deviceid>
<deviceid>1656</deviceid>
<deviceid>1657</deviceid>
<deviceid>165F</deviceid>
<deviceid>165C</deviceid>
<deviceid>1683</deviceid>
<deviceid>1641</deviceid>
<deviceid>1642</deviceid>
<deviceid>1643</deviceid>
<deviceid>1687</deviceid>
<deviceid>164A</deviceid>
<deviceid>16AA</deviceid>
<deviceid>164C</deviceid>
<deviceid>16AC</deviceid>
<deviceid>1639</deviceid>
<deviceid>163A</deviceid>
<deviceid>163B</deviceid>
<deviceid>163C</deviceid>
<deviceid>164E</deviceid>
<deviceid>164F</deviceid>
<deviceid>1650</deviceid>
<deviceid>1662</deviceid>
<deviceid>1663</deviceid>
<deviceid>168A</deviceid>
<deviceid>168D</deviceid>
<deviceid>16A1</deviceid>
<deviceid>16A2</deviceid>
<deviceid>168E</deviceid>
<deviceid>163D</deviceid>
<deviceid>16A5</deviceid>
<deviceid>16A4</deviceid>
<deviceid>16AE</deviceid>
<deviceid>163E</deviceid>
<deviceid>16C0</deviceid>
<deviceid>16C9</deviceid>
<deviceid>16CA</deviceid>
<deviceid>16CC</deviceid>
<deviceid>16CD</deviceid>
<deviceid>16CE</deviceid>
<deviceid>16CF</deviceid>
<deviceid>16D0</deviceid>
<deviceid>16D1</deviceid>
<deviceid>16D2</deviceid>
<deviceid>16D4</deviceid>
<deviceid>16D5</deviceid>
<deviceid>16D6</deviceid>
<deviceid>16D7</deviceid>
<deviceid>16D8</deviceid>
<deviceid>16D9</deviceid>
<deviceid>16DA</deviceid>
<deviceid>16DB</deviceid>
<deviceid>16DC</deviceid>
<deviceid>16DE</deviceid>
<deviceid>16DF</deviceid>
<deviceid>16E0</deviceid>
 <deviceid>16E2</deviceid>
<deviceid>16E3</deviceid>
<deviceid>16E4</deviceid>
<deviceid>16E7</deviceid>
<deviceid>16E8</deviceid>
<deviceid>16E9</deviceid>
<deviceid>16EA</deviceid>
<deviceid>16EB</deviceid>
<deviceid>16EC</deviceid>
<deviceid>16ED</deviceid>
<deviceid>16EE</deviceid>
<deviceid>16EF</deviceid>
<deviceid>16F0</deviceid>
<deviceid>16F1</deviceid>
<deviceid>1614</deviceid>
<deviceid>D802</deviceid>
<deviceid>1604</deviceid>
<deviceid>1605</deviceid>
<deviceid>1606</deviceid>
<deviceid>1607</deviceid>
<deviceid>1608</deviceid>
<deviceid>1609</deviceid>
<deviceid>D804</deviceid>
<deviceid>D812</deviceid>
<deviceid>D814</deviceid>
<deviceid>D818</deviceid>
<deviceid>D82A</deviceid>
<deviceid>D82B</deviceid>
<deviceid>D82C</deviceid>
<deviceid>D82D</deviceid>
<deviceid>D82E</deviceid>
<deviceid>D82F</deviceid>
<deviceid>1902</deviceid>
<deviceid>1903</deviceid>
<deviceid>1906</deviceid>
<deviceid>1907</deviceid>
<deviceid>190A</deviceid>
<deviceid>190B</deviceid>
<deviceid>1799</deviceid>
<deviceid>1041</deviceid>
<deviceid>1042</deviceid>
<deviceid>1043</deviceid>
<deviceid>1750</deviceid>
<deviceid>1751</deviceid>
<deviceid>1752</deviceid>
<deviceid>1800</deviceid>
<deviceid>1801</deviceid>
<deviceid>1802</deviceid>
<deviceid>1803</deviceid>
<deviceid>1804</deviceid>
<deviceid>1805</deviceid>
<deviceid>1806</deviceid>
<deviceid>1807</deviceid>
<deviceid>1808</deviceid>
<deviceid>1809</deviceid>
<deviceid>16C1</deviceid>
<deviceid>16C5</deviceid>
<deviceid>16BD</deviceid>
</NIC>

<NIC>
<manufacturer>1969</manufacturer>
<deviceid>1062</deviceid>
<deviceid>1063</deviceid>
<deviceid>2060</deviceid>
<deviceid>2062</deviceid>
<deviceid>1073</deviceid>
<deviceid>1083</deviceid>
<deviceid>1090</deviceid>
 <deviceid>1091</deviceid>
<deviceid>E091</deviceid>
<deviceid>10A0</deviceid>
<deviceid>10A1</deviceid>
<deviceid>E0A1</deviceid>
<deviceid>10B0</deviceid>
<deviceid>10B1</deviceid>
<deviceid>E0B1</deviceid>
<deviceid>10C0</deviceid>
<deviceid>10C1</deviceid>
<deviceid>E0C1</deviceid>
<deviceid>10D0</deviceid>
<deviceid>10D1</deviceid>
<deviceid>E0D1</deviceid>
<deviceid>10E0</deviceid>
<deviceid>10E1</deviceid>
<deviceid>E0E1</deviceid>
<deviceid>10F0</deviceid>
<deviceid>10F1</deviceid>
<deviceid>E0F1</deviceid>
</NIC>

<NIC>
<manufacturer>19A2</manufacturer>
<deviceid>0211</deviceid>
<deviceid>0215</deviceid>
<deviceid>0221</deviceid>
<deviceid>0700</deviceid>
<deviceid>0710</deviceid>
</NIC>

<NIC>
<manufacturer>10DF</manufacturer>
<deviceid>0720</deviceid>
<deviceid>E220</deviceid>
</NIC>

<NIC>
<manufacturer>15B3</manufacturer>
<deviceid>1000</deviceid>
<deviceid>1001</deviceid>
<deviceid>1002</deviceid>
<deviceid>1003</deviceid>
<deviceid>1004</deviceid>
<deviceid>1005</deviceid>
<deviceid>1006</deviceid>
<deviceid>1007</deviceid>
<deviceid>1008</deviceid>
<deviceid>1009</deviceid>
<deviceid>100A</deviceid>
<deviceid>100B</deviceid>
<deviceid>100C</deviceid>
<deviceid>100D</deviceid>
<deviceid>100E</deviceid>
<deviceid>100F</deviceid>
<deviceid>1010</deviceid>
<deviceid>6340</deviceid>
<deviceid>6341</deviceid>
<deviceid>634A</deviceid>
<deviceid>634B</deviceid>
<deviceid>6354</deviceid>
<deviceid>6368</deviceid>
<deviceid>6369</deviceid>
<deviceid>6372</deviceid>
<deviceid>6732</deviceid>
<deviceid>6733</deviceid>
<deviceid>673C</deviceid>
<deviceid>673D</deviceid>
<deviceid>6746</deviceid>
 <deviceid>6746</deviceid>
<deviceid>6750</deviceid>
<deviceid>6751</deviceid>
<deviceid>675A</deviceid>
<deviceid>6764</deviceid>
<deviceid>6765</deviceid>
<deviceid>676E</deviceid>
<deviceid>6778</deviceid>
<deviceid>1013</deviceid>
<deviceid>1015</deviceid>
<deviceid>1017</deviceid>
<deviceid>1019</deviceid>
<deviceid>101B</deviceid>
<deviceid>101D</deviceid>
<deviceid>101F</deviceid>
<deviceid>1021</deviceid>
<deviceid>1023</deviceid>
<deviceid>1025</deviceid>
<deviceid>1027</deviceid>
<deviceid>1029</deviceid>
<deviceid>102B</deviceid>
<deviceid>102F</deviceid>
</NIC>

<NIC>
<manufacturer>1137</manufacturer>
<deviceid>0043</deviceid>
</NIC>

</SupportedNetworkInterfaceCards>

Related topics
Setting Up Kernel-Mode Debugging over a Network Cable in Visual Studio
Setting Up KDNET Network Kernel Debugging Automatically
Setting Up KDNET Network Kernel Debugging Manually
Supported Ethernet NICs for Network Kernel Debugging in Windows 8
Supported Ethernet NICs for Network Kernel Debugging in Windows 8.1
 Supported Ethernet NICs for Network Kernel
Debugging in Windows 10 version 2004 (20H1) Build
19041
6/15/2021 • 3 minutes to read • Edit Online

To do kernel debugging over an Ethernet network cable, the target computer must have a supported network
interface card (NIC).
During kernel debugging, the computer that runs the debugger is called the host computer, and the computer
being debugged is called the target computer. For more information, see Setting Up KDNET Network Kernel
Debugging Automatically.
To do kernel debugging over a network cable, the target computer must have a supported network adapter.
When the target computer is running Windows, the network adapters listed here are supported for kernel
debugging.

Version Information
This topic lists the supported adapters for the following versions of Windows
Windows 10, version 2004 (20H1) Build 19041

XML Supported NIC List

This is the same information shown above in the XML format.

<?xml version="1.0" encoding="utf-8"?>

<SupportedNetworkInterfaceCards>
<NIC>
<manufacturer>8086</manufacturer>
<deviceid>1000</deviceid>
<deviceid>1001</deviceid>
<deviceid>1004</deviceid>
<deviceid>1008</deviceid>
<deviceid>1009</deviceid>
<deviceid>100C</deviceid>
<deviceid>100D</deviceid>
<deviceid>100E</deviceid>
<deviceid>1015</deviceid>
<deviceid>1016</deviceid>
<deviceid>1017</deviceid>
<deviceid>101E</deviceid>
<deviceid>100F</deviceid>
<deviceid>1011</deviceid>
<deviceid>1026</deviceid>
<deviceid>1027</deviceid>
<deviceid>1028</deviceid>
<deviceid>1010</deviceid>
<deviceid>1012</deviceid>
<deviceid>101D</deviceid>
<deviceid>1079</deviceid>
<deviceid>107A</deviceid>
<deviceid>107B</deviceid>
<deviceid>108A</deviceid>
<deviceid>1099</deviceid>
<deviceid>10B5</deviceid>
<deviceid>10B5</deviceid>
<deviceid>1013</deviceid>
<deviceid>1018</deviceid>
<deviceid>1014</deviceid>
<deviceid>1078</deviceid>
<deviceid>1076</deviceid>
<deviceid>107C</deviceid>
<deviceid>1077</deviceid>
<deviceid>1019</deviceid>
<deviceid>101A</deviceid>
<deviceid>1075</deviceid>
<deviceid>105E</deviceid>
<deviceid>105F</deviceid>
<deviceid>1060</deviceid>
<deviceid>10D9</deviceid>
<deviceid>10DA</deviceid>
<deviceid>10A4</deviceid>
<deviceid>10D5</deviceid>
<deviceid>10A5</deviceid>
<deviceid>10BC</deviceid>
<deviceid>107D</deviceid>
<deviceid>107E</deviceid>
<deviceid>107F</deviceid>
<deviceid>10B9</deviceid>
<deviceid>108B</deviceid>
<deviceid>108C</deviceid>
<deviceid>109A</deviceid>
<deviceid>10D3</deviceid>
<deviceid>10F6</deviceid>
<deviceid>150C</deviceid>
<deviceid>1096</deviceid>
<deviceid>1098</deviceid>
<deviceid>10BA</deviceid>
<deviceid>10BB</deviceid>
<deviceid>1501</deviceid>
<deviceid>1049</deviceid>
<deviceid>104A</deviceid>
<deviceid>104B</deviceid>
<deviceid>104C</deviceid>
<deviceid>10C4</deviceid>
<deviceid>10C5</deviceid>
<deviceid>104D</deviceid>
<deviceid>10BF</deviceid>
<deviceid>10F5</deviceid>
<deviceid>10CB</deviceid>
<deviceid>10BD</deviceid>
<deviceid>10E5</deviceid>
<deviceid>294C</deviceid>
<deviceid>10C0</deviceid>
<deviceid>10C3</deviceid>
<deviceid>10C2</deviceid>
<deviceid>10CC</deviceid>
<deviceid>10CD</deviceid>
<deviceid>10CE</deviceid>
<deviceid>10DE</deviceid>
<deviceid>10DF</deviceid>
<deviceid>1525</deviceid>
<deviceid>10EA</deviceid>
<deviceid>10EB</deviceid>
<deviceid>10EF</deviceid>
<deviceid>10F0</deviceid>
<deviceid>1502</deviceid>
<deviceid>1503</deviceid>
<deviceid>153A</deviceid>
<deviceid>153B</deviceid>
<deviceid>155A</deviceid>
<deviceid>1559</deviceid>
<deviceid>15A0</deviceid>
<deviceid>15A1</deviceid>
<deviceid>15A2</deviceid>
<deviceid>15A2</deviceid>
<deviceid>15A3</deviceid>
<deviceid>156F</deviceid>
<deviceid>1570</deviceid>
<deviceid>15B7</deviceid>
<deviceid>15B8</deviceid>
<deviceid>15B9</deviceid>
<deviceid>15D7</deviceid>
<deviceid>15D8</deviceid>
<deviceid>15E3</deviceid>
<deviceid>15D6</deviceid>
<deviceid>15BD</deviceid>
<deviceid>15BE</deviceid>
<deviceid>15BB</deviceid>
<deviceid>15BC</deviceid>
<deviceid>15DF</deviceid>
<deviceid>15E0</deviceid>
<deviceid>15E1</deviceid>
<deviceid>15E2</deviceid>
<deviceid>10C9</deviceid>
<deviceid>10E6</deviceid>
<deviceid>10E7</deviceid>
<deviceid>10E8</deviceid>
<deviceid>1526</deviceid>
<deviceid>150A</deviceid>
<deviceid>1518</deviceid>
<deviceid>150D</deviceid>
<deviceid>10A7</deviceid>
<deviceid>10A9</deviceid>
<deviceid>10D6</deviceid>
<deviceid>150E</deviceid>
<deviceid>150F</deviceid>
<deviceid>1510</deviceid>
<deviceid>1511</deviceid>
<deviceid>1516</deviceid>
<deviceid>1527</deviceid>
<deviceid>1521</deviceid>
<deviceid>1522</deviceid>
<deviceid>1523</deviceid>
<deviceid>1524</deviceid>
<deviceid>1546</deviceid>
<deviceid>1533</deviceid>
<deviceid>1534</deviceid>
<deviceid>1535</deviceid>
<deviceid>1536</deviceid>
<deviceid>1537</deviceid>
<deviceid>1538</deviceid>
<deviceid>157B</deviceid>
<deviceid>157C</deviceid>
<deviceid>1539</deviceid>
<deviceid>1F40</deviceid>
<deviceid>1F41</deviceid>
<deviceid>1F45</deviceid>
<deviceid>0438</deviceid>
<deviceid>043A</deviceid>
<deviceid>043C</deviceid>
<deviceid>0440</deviceid>
<deviceid>10C6</deviceid>
<deviceid>10C7</deviceid>
<deviceid>10C8</deviceid>
<deviceid>150B</deviceid>
<deviceid>10DB</deviceid>
<deviceid>10DD</deviceid>
<deviceid>10EC</deviceid>
<deviceid>10F1</deviceid>
<deviceid>10E1</deviceid>
<deviceid>10F4</deviceid>
<deviceid>10F7</deviceid>
<deviceid>1514</deviceid>
<deviceid>1517</deviceid>
 <deviceid>1517</deviceid>
<deviceid>10F8</deviceid>
<deviceid>000C</deviceid>
<deviceid>1F63</deviceid>
<deviceid>10F9</deviceid>
<deviceid>10FB</deviceid>
<deviceid>11A9</deviceid>
<deviceid>1071</deviceid>
<deviceid>1F72</deviceid>
<deviceid>17D0</deviceid>
<deviceid>0470</deviceid>
<deviceid>211B</deviceid>
<deviceid>8976</deviceid>
<deviceid>2159</deviceid>
<deviceid>000D</deviceid>
<deviceid>0008</deviceid>
<deviceid>152A</deviceid>
<deviceid>1529</deviceid>
<deviceid>1507</deviceid>
<deviceid>154D</deviceid>
<deviceid>154A</deviceid>
<deviceid>1558</deviceid>
<deviceid>1557</deviceid>
<deviceid>0001</deviceid>
<deviceid>10FC</deviceid>
<deviceid>151C</deviceid>
<deviceid>1528</deviceid>
<deviceid>1560</deviceid>
<deviceid>1563</deviceid>
<deviceid>ABCD</deviceid>
<deviceid>15AA</deviceid>
<deviceid>15AB</deviceid>
<deviceid>15AC</deviceid>
<deviceid>15AD</deviceid>
<deviceid>15AE</deviceid>
</NIC>

<NIC>
<manufacturer>10EC</manufacturer>
<deviceid>8136</deviceid>
<deviceid>8137</deviceid>
<deviceid>8168</deviceid>
<deviceid>8167</deviceid>
<deviceid>8169</deviceid>
<deviceid>8166</deviceid>
<deviceid>8161</deviceid>
<deviceid>8125</deviceid>
<deviceid>8225</deviceid>
<deviceid>2502</deviceid>
<deviceid>2600</deviceid>
<deviceid>3000</deviceid>
</NIC>

<NIC>
<manufacturer>14E4</manufacturer>
<deviceid>1644</deviceid>
<deviceid>1645</deviceid>
<deviceid>1646</deviceid>
<deviceid>16A6</deviceid>
<deviceid>16C6</deviceid>
<deviceid>1647</deviceid>
<deviceid>16A7</deviceid>
<deviceid>16C7</deviceid>
<deviceid>164D</deviceid>
<deviceid>1648</deviceid>
<deviceid>16A8</deviceid>
<deviceid>1653</deviceid>
<deviceid>166E</deviceid>
<deviceid>1654</deviceid>
<deviceid>165D</deviceid>
<deviceid>165D</deviceid>
<deviceid>165E</deviceid>
<deviceid>166D</deviceid>
<deviceid>170D</deviceid>
<deviceid>170E</deviceid>
<deviceid>1696</deviceid>
<deviceid>1676</deviceid>
<deviceid>1677</deviceid>
<deviceid>1659</deviceid>
<deviceid>167C</deviceid>
<deviceid>167D</deviceid>
<deviceid>169D</deviceid>
<deviceid>16F7</deviceid>
<deviceid>16FD</deviceid>
<deviceid>16FE</deviceid>
<deviceid>16DD</deviceid>
<deviceid>1668</deviceid>
<deviceid>1669</deviceid>
<deviceid>1678</deviceid>
<deviceid>1679</deviceid>
<deviceid>1600</deviceid>
<deviceid>1601</deviceid>
<deviceid>166A</deviceid>
<deviceid>166B</deviceid>
<deviceid>16FF</deviceid>
<deviceid>170F</deviceid>
<deviceid>169B</deviceid>
<deviceid>1693</deviceid>
<deviceid>167F</deviceid>
<deviceid>169A</deviceid>
<deviceid>1698</deviceid>
<deviceid>1692</deviceid>
<deviceid>1694</deviceid>
<deviceid>1690</deviceid>
<deviceid>1691</deviceid>
<deviceid>1699</deviceid>
<deviceid>16A0</deviceid>
<deviceid>167B</deviceid>
<deviceid>1673</deviceid>
<deviceid>165A</deviceid>
<deviceid>1674</deviceid>
<deviceid>1681</deviceid>
<deviceid>1680</deviceid>
<deviceid>1688</deviceid>
<deviceid>167A</deviceid>
<deviceid>1672</deviceid>
<deviceid>1684</deviceid>
<deviceid>165B</deviceid>
<deviceid>16B1</deviceid>
<deviceid>16B5</deviceid>
<deviceid>16B0</deviceid>
<deviceid>16B4</deviceid>
<deviceid>16B2</deviceid>
<deviceid>16B6</deviceid>
<deviceid>1682</deviceid>
<deviceid>1686</deviceid>
<deviceid>16B3</deviceid>
<deviceid>16B7</deviceid>
<deviceid>1655</deviceid>
<deviceid>1665</deviceid>
<deviceid>1656</deviceid>
<deviceid>1657</deviceid>
<deviceid>165F</deviceid>
<deviceid>165C</deviceid>
<deviceid>1683</deviceid>
<deviceid>1641</deviceid>
<deviceid>1642</deviceid>
<deviceid>1643</deviceid>
<deviceid>1687</deviceid>
 <deviceid>164A</deviceid>
<deviceid>16AA</deviceid>
<deviceid>164C</deviceid>
<deviceid>16AC</deviceid>
<deviceid>1639</deviceid>
<deviceid>163A</deviceid>
<deviceid>163B</deviceid>
<deviceid>163C</deviceid>
<deviceid>164E</deviceid>
<deviceid>164F</deviceid>
<deviceid>1650</deviceid>
<deviceid>1662</deviceid>
<deviceid>1663</deviceid>
<deviceid>168A</deviceid>
<deviceid>168D</deviceid>
<deviceid>16A1</deviceid>
<deviceid>16A2</deviceid>
<deviceid>168E</deviceid>
<deviceid>163D</deviceid>
<deviceid>16A5</deviceid>
<deviceid>16A4</deviceid>
<deviceid>16AE</deviceid>
<deviceid>163E</deviceid>
<deviceid>16C0</deviceid>
<deviceid>16C9</deviceid>
<deviceid>16CA</deviceid>
<deviceid>16CC</deviceid>
<deviceid>16CD</deviceid>
<deviceid>16CE</deviceid>
<deviceid>16CF</deviceid>
<deviceid>16D0</deviceid>
<deviceid>16D1</deviceid>
<deviceid>16D2</deviceid>
<deviceid>16D4</deviceid>
<deviceid>16D5</deviceid>
<deviceid>16D6</deviceid>
<deviceid>16D7</deviceid>
<deviceid>16D8</deviceid>
<deviceid>16D9</deviceid>
<deviceid>16DA</deviceid>
<deviceid>16DB</deviceid>
<deviceid>16DC</deviceid>
<deviceid>16DE</deviceid>
<deviceid>16DF</deviceid>
<deviceid>16E0</deviceid>
<deviceid>16E2</deviceid>
<deviceid>16E3</deviceid>
<deviceid>16E4</deviceid>
<deviceid>16E7</deviceid>
<deviceid>16E8</deviceid>
<deviceid>16E9</deviceid>
<deviceid>16EA</deviceid>
<deviceid>16EB</deviceid>
<deviceid>16EC</deviceid>
<deviceid>16ED</deviceid>
<deviceid>16EE</deviceid>
<deviceid>16EF</deviceid>
<deviceid>16F0</deviceid>
<deviceid>16F1</deviceid>
<deviceid>1614</deviceid>
<deviceid>D802</deviceid>
</NIC>

<NIC>
<manufacturer>1969</manufacturer>
<deviceid>1062</deviceid>
<deviceid>1063</deviceid>
<deviceid>2060</deviceid>
<deviceid>2062</deviceid>
 <deviceid>1073</deviceid>
<deviceid>1083</deviceid>
<deviceid>1090</deviceid>
<deviceid>1091</deviceid>
<deviceid>E091</deviceid>
<deviceid>10A0</deviceid>
<deviceid>10A1</deviceid>
<deviceid>E0A1</deviceid>
<deviceid>10B0</deviceid>
<deviceid>10B1</deviceid>
<deviceid>E0B1</deviceid>
<deviceid>10C0</deviceid>
<deviceid>10C1</deviceid>
<deviceid>E0C1</deviceid>
<deviceid>10D0</deviceid>
<deviceid>10D1</deviceid>
<deviceid>E0D1</deviceid>
<deviceid>10E0</deviceid>
<deviceid>10E1</deviceid>
<deviceid>E0E1</deviceid>
<deviceid>10F0</deviceid>
<deviceid>10F1</deviceid>
<deviceid>E0F1</deviceid>
</NIC>

<NIC>
<manufacturer>19A2</manufacturer>
<deviceid>0211</deviceid>
<deviceid>0215</deviceid>
<deviceid>0221</deviceid>
<deviceid>0700</deviceid>
<deviceid>0710</deviceid>
</NIC>

<NIC>
<manufacturer>10DF</manufacturer>
<deviceid>0720</deviceid>
<deviceid>E220</deviceid>
</NIC>

<NIC>
<manufacturer>15B3</manufacturer>
<deviceid>1000</deviceid>
<deviceid>1001</deviceid>
<deviceid>1002</deviceid>
<deviceid>1003</deviceid>
<deviceid>1004</deviceid>
<deviceid>1005</deviceid>
<deviceid>1006</deviceid>
<deviceid>1007</deviceid>
<deviceid>1008</deviceid>
<deviceid>1009</deviceid>
<deviceid>100A</deviceid>
<deviceid>100B</deviceid>
<deviceid>100C</deviceid>
<deviceid>100D</deviceid>
<deviceid>100E</deviceid>
<deviceid>100F</deviceid>
<deviceid>1010</deviceid>
<deviceid>6340</deviceid>
<deviceid>6341</deviceid>
<deviceid>634A</deviceid>
<deviceid>634B</deviceid>
<deviceid>6354</deviceid>
<deviceid>6368</deviceid>
<deviceid>6369</deviceid>
<deviceid>6372</deviceid>
<deviceid>6732</deviceid>
<deviceid>6733</deviceid>
 <deviceid>6733</deviceid>
<deviceid>673C</deviceid>
<deviceid>673D</deviceid>
<deviceid>6746</deviceid>
<deviceid>6750</deviceid>
<deviceid>6751</deviceid>
<deviceid>675A</deviceid>
<deviceid>6764</deviceid>
<deviceid>6765</deviceid>
<deviceid>676E</deviceid>
<deviceid>6778</deviceid>
<deviceid>1013</deviceid>
<deviceid>1015</deviceid>
<deviceid>1017</deviceid>
<deviceid>1019</deviceid>
<deviceid>101B</deviceid>
<deviceid>101D</deviceid>
<deviceid>101F</deviceid>
<deviceid>1021</deviceid>
<deviceid>1023</deviceid>
<deviceid>1025</deviceid>
<deviceid>1027</deviceid>
<deviceid>1029</deviceid>
<deviceid>102B</deviceid>
<deviceid>102F</deviceid>
</NIC>

<NIC>
<manufacturer>1137</manufacturer>
<deviceid>0043</deviceid>
</NIC>

</SupportedNetworkInterfaceCards>

Related topics
Setting Up Kernel-Mode Debugging over a Network Cable in Visual Studio
Setting Up KDNET Network Kernel Debugging Automatically
Setting Up KDNET Network Kernel Debugging Manually
Supported Ethernet NICs for Network Kernel Debugging in Windows 8
Supported Ethernet NICs for Network Kernel Debugging in Windows 8.1
 Supported Ethernet NICs for Network Kernel
Debugging in Windows 10, version 1909 (19H2) Build
18363
3/5/2021 • 2 minutes to read • Edit Online

To do kernel debugging over an Ethernet network cable, the target computer must have a supported network
interface card (NIC).
During kernel debugging, the computer that runs the debugger is called the host computer, and the computer
being debugged is called the target computer. For more information, see Setting Up KDNET Network Kernel
Debugging Automatically.
For general information on supported network adapters see Supported Ethernet NICs for Network Kernel
Debugging in Windows 10.
Version Information
The list of supported adapters is for the following versions of Windows
Windows 10, version 1909 (19H2) Build 18363

<?xml version="1.0" encoding="utf-8"?>

<SupportedNetworkInterfaceCards>
<NIC>
<manufacturer>8086</manufacturer>
<deviceid>1000</deviceid>
<deviceid>1001</deviceid>
<deviceid>1004</deviceid>
<deviceid>1008</deviceid>
<deviceid>1009</deviceid>
<deviceid>100C</deviceid>
<deviceid>100D</deviceid>
<deviceid>100E</deviceid>
<deviceid>1015</deviceid>
<deviceid>1016</deviceid>
<deviceid>1017</deviceid>
<deviceid>101E</deviceid>
<deviceid>100F</deviceid>
<deviceid>1011</deviceid>
<deviceid>1026</deviceid>
<deviceid>1027</deviceid>
<deviceid>1028</deviceid>
<deviceid>1010</deviceid>
<deviceid>1012</deviceid>
<deviceid>101D</deviceid>
<deviceid>1079</deviceid>
<deviceid>107A</deviceid>
<deviceid>107B</deviceid>
<deviceid>108A</deviceid>
<deviceid>1099</deviceid>
<deviceid>10B5</deviceid>
<deviceid>1013</deviceid>
<deviceid>1018</deviceid>
<deviceid>1014</deviceid>
<deviceid>1078</deviceid>
<deviceid>1076</deviceid>
<deviceid>107C</deviceid>
<deviceid>1077</deviceid>
<deviceid>1077</deviceid>
<deviceid>1019</deviceid>
<deviceid>101A</deviceid>
<deviceid>1075</deviceid>
<deviceid>105E</deviceid>
<deviceid>105F</deviceid>
<deviceid>1060</deviceid>
<deviceid>10D9</deviceid>
<deviceid>10DA</deviceid>
<deviceid>10A4</deviceid>
<deviceid>10D5</deviceid>
<deviceid>10A5</deviceid>
<deviceid>10BC</deviceid>
<deviceid>107D</deviceid>
<deviceid>107E</deviceid>
<deviceid>107F</deviceid>
<deviceid>10B9</deviceid>
<deviceid>108B</deviceid>
<deviceid>108C</deviceid>
<deviceid>109A</deviceid>
<deviceid>10D3</deviceid>
<deviceid>10F6</deviceid>
<deviceid>150C</deviceid>
<deviceid>1096</deviceid>
<deviceid>1098</deviceid>
<deviceid>10BA</deviceid>
<deviceid>10BB</deviceid>
<deviceid>1501</deviceid>
<deviceid>1049</deviceid>
<deviceid>104A</deviceid>
<deviceid>104B</deviceid>
<deviceid>104C</deviceid>
<deviceid>10C4</deviceid>
<deviceid>10C5</deviceid>
<deviceid>104D</deviceid>
<deviceid>10BF</deviceid>
<deviceid>10F5</deviceid>
<deviceid>10CB</deviceid>
<deviceid>10BD</deviceid>
<deviceid>10E5</deviceid>
<deviceid>294C</deviceid>
<deviceid>10C0</deviceid>
<deviceid>10C3</deviceid>
<deviceid>10C2</deviceid>
<deviceid>10CC</deviceid>
<deviceid>10CD</deviceid>
<deviceid>10CE</deviceid>
<deviceid>10DE</deviceid>
<deviceid>10DF</deviceid>
<deviceid>1525</deviceid>
<deviceid>10EA</deviceid>
<deviceid>10EB</deviceid>
<deviceid>10EF</deviceid>
<deviceid>10F0</deviceid>
<deviceid>1502</deviceid>
<deviceid>1503</deviceid>
<deviceid>153A</deviceid>
<deviceid>153B</deviceid>
<deviceid>155A</deviceid>
<deviceid>1559</deviceid>
<deviceid>15A0</deviceid>
<deviceid>15A1</deviceid>
<deviceid>15A2</deviceid>
<deviceid>15A3</deviceid>
<deviceid>156F</deviceid>
<deviceid>1570</deviceid>
<deviceid>15B7</deviceid>
<deviceid>15B8</deviceid>
<deviceid>15B9</deviceid>
<deviceid>15D7</deviceid>
<deviceid>15D7</deviceid>
<deviceid>15D8</deviceid>
<deviceid>15E3</deviceid>
<deviceid>15D6</deviceid>
<deviceid>15BD</deviceid>
<deviceid>15BE</deviceid>
<deviceid>15BB</deviceid>
<deviceid>15BC</deviceid>
<deviceid>15DF</deviceid>
<deviceid>15E0</deviceid>
<deviceid>15E1</deviceid>
<deviceid>15E2</deviceid>
<deviceid>10C9</deviceid>
<deviceid>10E6</deviceid>
<deviceid>10E7</deviceid>
<deviceid>10E8</deviceid>
<deviceid>1526</deviceid>
<deviceid>150A</deviceid>
<deviceid>1518</deviceid>
<deviceid>150D</deviceid>
<deviceid>10A7</deviceid>
<deviceid>10A9</deviceid>
<deviceid>10D6</deviceid>
<deviceid>150E</deviceid>
<deviceid>150F</deviceid>
<deviceid>1510</deviceid>
<deviceid>1511</deviceid>
<deviceid>1516</deviceid>
<deviceid>1527</deviceid>
<deviceid>1521</deviceid>
<deviceid>1522</deviceid>
<deviceid>1523</deviceid>
<deviceid>1524</deviceid>
<deviceid>1546</deviceid>
<deviceid>1533</deviceid>
<deviceid>1534</deviceid>
<deviceid>1535</deviceid>
<deviceid>1536</deviceid>
<deviceid>1537</deviceid>
<deviceid>1538</deviceid>
<deviceid>157B</deviceid>
<deviceid>157C</deviceid>
<deviceid>1539</deviceid>
<deviceid>1F40</deviceid>
<deviceid>1F41</deviceid>
<deviceid>1F45</deviceid>
<deviceid>0438</deviceid>
<deviceid>043A</deviceid>
<deviceid>043C</deviceid>
<deviceid>0440</deviceid>
<deviceid>10C6</deviceid>
<deviceid>10C7</deviceid>
<deviceid>10C8</deviceid>
<deviceid>150B</deviceid>
<deviceid>10DB</deviceid>
<deviceid>10DD</deviceid>
<deviceid>10EC</deviceid>
<deviceid>10F1</deviceid>
<deviceid>10E1</deviceid>
<deviceid>10F4</deviceid>
<deviceid>10F7</deviceid>
<deviceid>1514</deviceid>
<deviceid>1517</deviceid>
<deviceid>10F8</deviceid>
<deviceid>000C</deviceid>
<deviceid>1F63</deviceid>
<deviceid>10F9</deviceid>
<deviceid>10FB</deviceid>
<deviceid>11A9</deviceid>
<deviceid>1071</deviceid>
 <deviceid>1071</deviceid>
<deviceid>1F72</deviceid>
<deviceid>17D0</deviceid>
<deviceid>0470</deviceid>
<deviceid>211B</deviceid>
<deviceid>8976</deviceid>
<deviceid>2159</deviceid>
<deviceid>000D</deviceid>
<deviceid>0008</deviceid>
<deviceid>152A</deviceid>
<deviceid>1529</deviceid>
<deviceid>1507</deviceid>
<deviceid>154D</deviceid>
<deviceid>154A</deviceid>
<deviceid>1558</deviceid>
<deviceid>1557</deviceid>
<deviceid>0001</deviceid>
<deviceid>10FC</deviceid>
<deviceid>151C</deviceid>
<deviceid>1528</deviceid>
<deviceid>1560</deviceid>
<deviceid>1563</deviceid>
<deviceid>ABCD</deviceid>
<deviceid>15AA</deviceid>
<deviceid>15AB</deviceid>
<deviceid>15AC</deviceid>
<deviceid>15AD</deviceid>
<deviceid>15AE</deviceid>
</NIC>

<NIC>
<manufacturer>10EC</manufacturer>
<deviceid>8136</deviceid>
<deviceid>8137</deviceid>
<deviceid>8168</deviceid>
<deviceid>8167</deviceid>
<deviceid>8169</deviceid>
<deviceid>8166</deviceid>
<deviceid>8161</deviceid>
<deviceid>8125</deviceid>
<deviceid>8225</deviceid>
<deviceid>2502</deviceid>
<deviceid>2600</deviceid>
<deviceid>3000</deviceid>
</NIC>

<NIC>
<manufacturer>14E4</manufacturer>
<deviceid>1644</deviceid>
<deviceid>1645</deviceid>
<deviceid>1646</deviceid>
<deviceid>16A6</deviceid>
<deviceid>16C6</deviceid>
<deviceid>1647</deviceid>
<deviceid>16A7</deviceid>
<deviceid>16C7</deviceid>
<deviceid>164D</deviceid>
<deviceid>1648</deviceid>
<deviceid>16A8</deviceid>
<deviceid>1653</deviceid>
<deviceid>166E</deviceid>
<deviceid>1654</deviceid>
<deviceid>165D</deviceid>
<deviceid>165E</deviceid>
<deviceid>166D</deviceid>
<deviceid>170D</deviceid>
<deviceid>170E</deviceid>
<deviceid>1696</deviceid>
<deviceid>1676</deviceid>
<deviceid>1677</deviceid>
<deviceid>1677</deviceid>
<deviceid>1659</deviceid>
<deviceid>167C</deviceid>
<deviceid>167D</deviceid>
<deviceid>169D</deviceid>
<deviceid>16F7</deviceid>
<deviceid>16FD</deviceid>
<deviceid>16FE</deviceid>
<deviceid>16DD</deviceid>
<deviceid>1668</deviceid>
<deviceid>1669</deviceid>
<deviceid>1678</deviceid>
<deviceid>1679</deviceid>
<deviceid>1600</deviceid>
<deviceid>1601</deviceid>
<deviceid>166A</deviceid>
<deviceid>166B</deviceid>
<deviceid>16FF</deviceid>
<deviceid>170F</deviceid>
<deviceid>169B</deviceid>
<deviceid>1693</deviceid>
<deviceid>167F</deviceid>
<deviceid>169A</deviceid>
<deviceid>1698</deviceid>
<deviceid>1692</deviceid>
<deviceid>1694</deviceid>
<deviceid>1690</deviceid>
<deviceid>1691</deviceid>
<deviceid>1699</deviceid>
<deviceid>16A0</deviceid>
<deviceid>167B</deviceid>
<deviceid>1673</deviceid>
<deviceid>165A</deviceid>
<deviceid>1674</deviceid>
<deviceid>1681</deviceid>
<deviceid>1680</deviceid>
<deviceid>1688</deviceid>
<deviceid>167A</deviceid>
<deviceid>1672</deviceid>
<deviceid>1684</deviceid>
<deviceid>165B</deviceid>
<deviceid>16B1</deviceid>
<deviceid>16B5</deviceid>
<deviceid>16B0</deviceid>
<deviceid>16B4</deviceid>
<deviceid>16B2</deviceid>
<deviceid>16B6</deviceid>
<deviceid>1682</deviceid>
<deviceid>1686</deviceid>
<deviceid>16B3</deviceid>
<deviceid>16B7</deviceid>
<deviceid>1655</deviceid>
<deviceid>1665</deviceid>
<deviceid>1656</deviceid>
<deviceid>1657</deviceid>
<deviceid>165F</deviceid>
<deviceid>165C</deviceid>
<deviceid>1683</deviceid>
<deviceid>1641</deviceid>
<deviceid>1642</deviceid>
<deviceid>1643</deviceid>
<deviceid>1687</deviceid>
<deviceid>164A</deviceid>
<deviceid>16AA</deviceid>
<deviceid>164C</deviceid>
<deviceid>16AC</deviceid>
<deviceid>1639</deviceid>
<deviceid>163A</deviceid>
<deviceid>163B</deviceid>
<deviceid>163C</deviceid>
 <deviceid>163C</deviceid>
<deviceid>164E</deviceid>
<deviceid>164F</deviceid>
<deviceid>1650</deviceid>
<deviceid>1662</deviceid>
<deviceid>1663</deviceid>
<deviceid>168A</deviceid>
<deviceid>168D</deviceid>
<deviceid>16A1</deviceid>
<deviceid>16A2</deviceid>
<deviceid>168E</deviceid>
<deviceid>163D</deviceid>
<deviceid>16A5</deviceid>
<deviceid>16A4</deviceid>
<deviceid>16AE</deviceid>
<deviceid>163E</deviceid>
</NIC>

<NIC>
<manufacturer>1969</manufacturer>
<deviceid>1062</deviceid>
<deviceid>1063</deviceid>
<deviceid>2060</deviceid>
<deviceid>2062</deviceid>
<deviceid>1073</deviceid>
<deviceid>1083</deviceid>
<deviceid>1090</deviceid>
<deviceid>1091</deviceid>
<deviceid>E091</deviceid>
<deviceid>10A0</deviceid>
<deviceid>10A1</deviceid>
<deviceid>E0A1</deviceid>
<deviceid>10B0</deviceid>
<deviceid>10B1</deviceid>
<deviceid>E0B1</deviceid>
<deviceid>10C0</deviceid>
<deviceid>10C1</deviceid>
<deviceid>E0C1</deviceid>
<deviceid>10D0</deviceid>
<deviceid>10D1</deviceid>
<deviceid>E0D1</deviceid>
<deviceid>10E0</deviceid>
<deviceid>10E1</deviceid>
<deviceid>E0E1</deviceid>
<deviceid>10F0</deviceid>
<deviceid>10F1</deviceid>
<deviceid>E0F1</deviceid>
</NIC>

<NIC>
<manufacturer>19A2</manufacturer>
<deviceid>0211</deviceid>
<deviceid>0215</deviceid>
<deviceid>0221</deviceid>
<deviceid>0700</deviceid>
<deviceid>0710</deviceid>
</NIC>

<NIC>
<manufacturer>10DF</manufacturer>
<deviceid>0720</deviceid>
<deviceid>E220</deviceid>
</NIC>

<NIC>
<manufacturer>15B3</manufacturer>
<deviceid>1000</deviceid>
<deviceid>1001</deviceid>
<deviceid>1002</deviceid>
 <deviceid>1003</deviceid>
<deviceid>1004</deviceid>
<deviceid>1005</deviceid>
<deviceid>1006</deviceid>
<deviceid>1007</deviceid>
<deviceid>1008</deviceid>
<deviceid>1009</deviceid>
<deviceid>100A</deviceid>
<deviceid>100B</deviceid>
<deviceid>100C</deviceid>
<deviceid>100D</deviceid>
<deviceid>100E</deviceid>
<deviceid>100F</deviceid>
<deviceid>1010</deviceid>
<deviceid>6340</deviceid>
<deviceid>6341</deviceid>
<deviceid>634A</deviceid>
<deviceid>634B</deviceid>
<deviceid>6354</deviceid>
<deviceid>6368</deviceid>
<deviceid>6369</deviceid>
<deviceid>6372</deviceid>
<deviceid>6732</deviceid>
<deviceid>6733</deviceid>
<deviceid>673C</deviceid>
<deviceid>673D</deviceid>
<deviceid>6746</deviceid>
<deviceid>6750</deviceid>
<deviceid>6751</deviceid>
<deviceid>675A</deviceid>
<deviceid>6764</deviceid>
<deviceid>6765</deviceid>
<deviceid>676E</deviceid>
<deviceid>6778</deviceid>
<deviceid>1013</deviceid>
<deviceid>1015</deviceid>
<deviceid>1017</deviceid>
<deviceid>1019</deviceid>
<deviceid>101B</deviceid>
<deviceid>101D</deviceid>
<deviceid>101F</deviceid>
<deviceid>1021</deviceid>
<deviceid>1023</deviceid>
<deviceid>1025</deviceid>
<deviceid>1027</deviceid>
<deviceid>1029</deviceid>
<deviceid>102B</deviceid>
<deviceid>102F</deviceid>
</NIC>

<NIC>
<manufacturer>1137</manufacturer>
<deviceid>0043</deviceid>
</NIC>

</SupportedNetworkInterfaceCards>

Related topics
Setting Up Kernel-Mode Debugging over a Network Cable in Visual Studio
Setting Up KDNET Network Kernel Debugging Automatically
Setting Up KDNET Network Kernel Debugging Manually
Supported Ethernet NICs for Network Kernel Debugging in Windows 8
Supported Ethernet NICs for Network Kernel Debugging in Windows 8.1
 Supported Ethernet NICs for Network Kernel
Debugging in Windows 10 version 1903 (19H1) Build
18362
3/5/2021 • 2 minutes to read • Edit Online

To do kernel debugging over an Ethernet network cable, the target computer must have a supported network
interface card (NIC).
During kernel debugging, the computer that runs the debugger is called the host computer, and the computer
being debugged is called the target computer. For more information, see Setting Up KDNET Network Kernel
Debugging Automatically.
For general information on supported network adapters see Supported Ethernet NICs for Network Kernel
Debugging in Windows 10.
Version Information
The list of supported adapters is for the following versions of Windows
Windows 10, version 1903 (19H1) Build 18362

<?xml version="1.0" encoding="utf-8"?>

<SupportedNetworkInterfaceCards>
<NIC>
<manufacturer>8086</manufacturer>
<deviceid>1000</deviceid>
<deviceid>1001</deviceid>
<deviceid>1004</deviceid>
<deviceid>1008</deviceid>
<deviceid>1009</deviceid>
<deviceid>100C</deviceid>
<deviceid>100D</deviceid>
<deviceid>100E</deviceid>
<deviceid>1015</deviceid>
<deviceid>1016</deviceid>
<deviceid>1017</deviceid>
<deviceid>101E</deviceid>
<deviceid>100F</deviceid>
<deviceid>1011</deviceid>
<deviceid>1026</deviceid>
<deviceid>1027</deviceid>
<deviceid>1028</deviceid>
<deviceid>1010</deviceid>
<deviceid>1012</deviceid>
<deviceid>101D</deviceid>
<deviceid>1079</deviceid>
<deviceid>107A</deviceid>
<deviceid>107B</deviceid>
<deviceid>108A</deviceid>
<deviceid>1099</deviceid>
<deviceid>10B5</deviceid>
<deviceid>1013</deviceid>
<deviceid>1018</deviceid>
<deviceid>1014</deviceid>
<deviceid>1078</deviceid>
<deviceid>1076</deviceid>
<deviceid>107C</deviceid>
<deviceid>1077</deviceid>
<deviceid>1077</deviceid>
<deviceid>1019</deviceid>
<deviceid>101A</deviceid>
<deviceid>1075</deviceid>
<deviceid>105E</deviceid>
<deviceid>105F</deviceid>
<deviceid>1060</deviceid>
<deviceid>10D9</deviceid>
<deviceid>10DA</deviceid>
<deviceid>10A4</deviceid>
<deviceid>10D5</deviceid>
<deviceid>10A5</deviceid>
<deviceid>10BC</deviceid>
<deviceid>107D</deviceid>
<deviceid>107E</deviceid>
<deviceid>107F</deviceid>
<deviceid>10B9</deviceid>
<deviceid>108B</deviceid>
<deviceid>108C</deviceid>
<deviceid>109A</deviceid>
<deviceid>10D3</deviceid>
<deviceid>10F6</deviceid>
<deviceid>150C</deviceid>
<deviceid>1096</deviceid>
<deviceid>1098</deviceid>
<deviceid>10BA</deviceid>
<deviceid>10BB</deviceid>
<deviceid>1501</deviceid>
<deviceid>1049</deviceid>
<deviceid>104A</deviceid>
<deviceid>104B</deviceid>
<deviceid>104C</deviceid>
<deviceid>10C4</deviceid>
<deviceid>10C5</deviceid>
<deviceid>104D</deviceid>
<deviceid>10BF</deviceid>
<deviceid>10F5</deviceid>
<deviceid>10CB</deviceid>
<deviceid>10BD</deviceid>
<deviceid>10E5</deviceid>
<deviceid>294C</deviceid>
<deviceid>10C0</deviceid>
<deviceid>10C3</deviceid>
<deviceid>10C2</deviceid>
<deviceid>10CC</deviceid>
<deviceid>10CD</deviceid>
<deviceid>10CE</deviceid>
<deviceid>10DE</deviceid>
<deviceid>10DF</deviceid>
<deviceid>1525</deviceid>
<deviceid>10EA</deviceid>
<deviceid>10EB</deviceid>
<deviceid>10EF</deviceid>
<deviceid>10F0</deviceid>
<deviceid>1502</deviceid>
<deviceid>1503</deviceid>
<deviceid>153A</deviceid>
<deviceid>153B</deviceid>
<deviceid>155A</deviceid>
<deviceid>1559</deviceid>
<deviceid>15A0</deviceid>
<deviceid>15A1</deviceid>
<deviceid>15A2</deviceid>
<deviceid>15A3</deviceid>
<deviceid>156F</deviceid>
<deviceid>1570</deviceid>
<deviceid>15B7</deviceid>
<deviceid>15B8</deviceid>
<deviceid>15B9</deviceid>
<deviceid>15D7</deviceid>
<deviceid>15D7</deviceid>
<deviceid>15D8</deviceid>
<deviceid>15E3</deviceid>
<deviceid>15D6</deviceid>
<deviceid>15BD</deviceid>
<deviceid>15BE</deviceid>
<deviceid>15BB</deviceid>
<deviceid>15BC</deviceid>
<deviceid>15DF</deviceid>
<deviceid>15E0</deviceid>
<deviceid>15E1</deviceid>
<deviceid>15E2</deviceid>
<deviceid>10C9</deviceid>
<deviceid>10E6</deviceid>
<deviceid>10E7</deviceid>
<deviceid>10E8</deviceid>
<deviceid>1526</deviceid>
<deviceid>150A</deviceid>
<deviceid>1518</deviceid>
<deviceid>150D</deviceid>
<deviceid>10A7</deviceid>
<deviceid>10A9</deviceid>
<deviceid>10D6</deviceid>
<deviceid>150E</deviceid>
<deviceid>150F</deviceid>
<deviceid>1510</deviceid>
<deviceid>1511</deviceid>
<deviceid>1516</deviceid>
<deviceid>1527</deviceid>
<deviceid>1521</deviceid>
<deviceid>1522</deviceid>
<deviceid>1523</deviceid>
<deviceid>1524</deviceid>
<deviceid>1546</deviceid>
<deviceid>1533</deviceid>
<deviceid>1534</deviceid>
<deviceid>1535</deviceid>
<deviceid>1536</deviceid>
<deviceid>1537</deviceid>
<deviceid>1538</deviceid>
<deviceid>157B</deviceid>
<deviceid>157C</deviceid>
<deviceid>1539</deviceid>
<deviceid>1F40</deviceid>
<deviceid>1F41</deviceid>
<deviceid>1F45</deviceid>
<deviceid>0438</deviceid>
<deviceid>043A</deviceid>
<deviceid>043C</deviceid>
<deviceid>0440</deviceid>
<deviceid>10C6</deviceid>
<deviceid>10C7</deviceid>
<deviceid>10C8</deviceid>
<deviceid>150B</deviceid>
<deviceid>10DB</deviceid>
<deviceid>10DD</deviceid>
<deviceid>10EC</deviceid>
<deviceid>10F1</deviceid>
<deviceid>10E1</deviceid>
<deviceid>10F4</deviceid>
<deviceid>10F7</deviceid>
<deviceid>1514</deviceid>
<deviceid>1517</deviceid>
<deviceid>10F8</deviceid>
<deviceid>000C</deviceid>
<deviceid>1F63</deviceid>
<deviceid>10F9</deviceid>
<deviceid>10FB</deviceid>
<deviceid>11A9</deviceid>
<deviceid>1071</deviceid>
 <deviceid>1071</deviceid>
<deviceid>1F72</deviceid>
<deviceid>17D0</deviceid>
<deviceid>0470</deviceid>
<deviceid>211B</deviceid>
<deviceid>8976</deviceid>
<deviceid>2159</deviceid>
<deviceid>000D</deviceid>
<deviceid>0008</deviceid>
<deviceid>152A</deviceid>
<deviceid>1529</deviceid>
<deviceid>1507</deviceid>
<deviceid>154D</deviceid>
<deviceid>154A</deviceid>
<deviceid>1558</deviceid>
<deviceid>1557</deviceid>
<deviceid>0001</deviceid>
<deviceid>10FC</deviceid>
<deviceid>151C</deviceid>
<deviceid>1528</deviceid>
<deviceid>1560</deviceid>
<deviceid>1563</deviceid>
<deviceid>ABCD</deviceid>
<deviceid>15AA</deviceid>
<deviceid>15AB</deviceid>
<deviceid>15AC</deviceid>
<deviceid>15AD</deviceid>
<deviceid>15AE</deviceid>
</NIC>

<NIC>
<manufacturer>10EC</manufacturer>
<deviceid>8136</deviceid>
<deviceid>8137</deviceid>
<deviceid>8168</deviceid>
<deviceid>8167</deviceid>
<deviceid>8169</deviceid>
<deviceid>8166</deviceid>
<deviceid>8161</deviceid>
<deviceid>8125</deviceid>
<deviceid>8225</deviceid>
<deviceid>2502</deviceid>
<deviceid>2600</deviceid>
<deviceid>3000</deviceid>
</NIC>

<NIC>
<manufacturer>14E4</manufacturer>
<deviceid>1644</deviceid>
<deviceid>1645</deviceid>
<deviceid>1646</deviceid>
<deviceid>16A6</deviceid>
<deviceid>16C6</deviceid>
<deviceid>1647</deviceid>
<deviceid>16A7</deviceid>
<deviceid>16C7</deviceid>
<deviceid>164D</deviceid>
<deviceid>1648</deviceid>
<deviceid>16A8</deviceid>
<deviceid>1653</deviceid>
<deviceid>166E</deviceid>
<deviceid>1654</deviceid>
<deviceid>165D</deviceid>
<deviceid>165E</deviceid>
<deviceid>166D</deviceid>
<deviceid>170D</deviceid>
<deviceid>170E</deviceid>
<deviceid>1696</deviceid>
<deviceid>1676</deviceid>
<deviceid>1677</deviceid>
<deviceid>1677</deviceid>
<deviceid>1659</deviceid>
<deviceid>167C</deviceid>
<deviceid>167D</deviceid>
<deviceid>169D</deviceid>
<deviceid>16F7</deviceid>
<deviceid>16FD</deviceid>
<deviceid>16FE</deviceid>
<deviceid>16DD</deviceid>
<deviceid>1668</deviceid>
<deviceid>1669</deviceid>
<deviceid>1678</deviceid>
<deviceid>1679</deviceid>
<deviceid>1600</deviceid>
<deviceid>1601</deviceid>
<deviceid>166A</deviceid>
<deviceid>166B</deviceid>
<deviceid>16FF</deviceid>
<deviceid>170F</deviceid>
<deviceid>169B</deviceid>
<deviceid>1693</deviceid>
<deviceid>167F</deviceid>
<deviceid>169A</deviceid>
<deviceid>1698</deviceid>
<deviceid>1692</deviceid>
<deviceid>1694</deviceid>
<deviceid>1690</deviceid>
<deviceid>1691</deviceid>
<deviceid>1699</deviceid>
<deviceid>16A0</deviceid>
<deviceid>167B</deviceid>
<deviceid>1673</deviceid>
<deviceid>165A</deviceid>
<deviceid>1674</deviceid>
<deviceid>1681</deviceid>
<deviceid>1680</deviceid>
<deviceid>1688</deviceid>
<deviceid>167A</deviceid>
<deviceid>1672</deviceid>
<deviceid>1684</deviceid>
<deviceid>165B</deviceid>
<deviceid>16B1</deviceid>
<deviceid>16B5</deviceid>
<deviceid>16B0</deviceid>
<deviceid>16B4</deviceid>
<deviceid>16B2</deviceid>
<deviceid>16B6</deviceid>
<deviceid>1682</deviceid>
<deviceid>1686</deviceid>
<deviceid>16B3</deviceid>
<deviceid>16B7</deviceid>
<deviceid>1655</deviceid>
<deviceid>1665</deviceid>
<deviceid>1656</deviceid>
<deviceid>1657</deviceid>
<deviceid>165F</deviceid>
<deviceid>165C</deviceid>
<deviceid>1683</deviceid>
<deviceid>1641</deviceid>
<deviceid>1642</deviceid>
<deviceid>1643</deviceid>
<deviceid>1687</deviceid>
<deviceid>164A</deviceid>
<deviceid>16AA</deviceid>
<deviceid>164C</deviceid>
<deviceid>16AC</deviceid>
<deviceid>1639</deviceid>
<deviceid>163A</deviceid>
<deviceid>163B</deviceid>
<deviceid>163C</deviceid>
 <deviceid>163C</deviceid>
<deviceid>164E</deviceid>
<deviceid>164F</deviceid>
<deviceid>1650</deviceid>
<deviceid>1662</deviceid>
<deviceid>1663</deviceid>
<deviceid>168A</deviceid>
<deviceid>168D</deviceid>
<deviceid>16A1</deviceid>
<deviceid>16A2</deviceid>
<deviceid>168E</deviceid>
<deviceid>163D</deviceid>
<deviceid>16A5</deviceid>
<deviceid>16A4</deviceid>
<deviceid>16AE</deviceid>
<deviceid>163E</deviceid>
</NIC>

<NIC>
<manufacturer>1969</manufacturer>
<deviceid>1062</deviceid>
<deviceid>1063</deviceid>
<deviceid>2060</deviceid>
<deviceid>2062</deviceid>
<deviceid>1073</deviceid>
<deviceid>1083</deviceid>
<deviceid>1090</deviceid>
<deviceid>1091</deviceid>
<deviceid>E091</deviceid>
<deviceid>10A0</deviceid>
<deviceid>10A1</deviceid>
<deviceid>E0A1</deviceid>
<deviceid>10B0</deviceid>
<deviceid>10B1</deviceid>
<deviceid>E0B1</deviceid>
<deviceid>10C0</deviceid>
<deviceid>10C1</deviceid>
<deviceid>E0C1</deviceid>
<deviceid>10D0</deviceid>
<deviceid>10D1</deviceid>
<deviceid>E0D1</deviceid>
<deviceid>10E0</deviceid>
<deviceid>10E1</deviceid>
<deviceid>E0E1</deviceid>
<deviceid>10F0</deviceid>
<deviceid>10F1</deviceid>
<deviceid>E0F1</deviceid>
</NIC>

<NIC>
<manufacturer>19A2</manufacturer>
<deviceid>0211</deviceid>
<deviceid>0215</deviceid>
<deviceid>0221</deviceid>
<deviceid>0700</deviceid>
<deviceid>0710</deviceid>
</NIC>

<NIC>
<manufacturer>10DF</manufacturer>
<deviceid>0720</deviceid>
<deviceid>E220</deviceid>
</NIC>

<NIC>
<manufacturer>15B3</manufacturer>
<deviceid>1000</deviceid>
<deviceid>1001</deviceid>
<deviceid>1002</deviceid>
 <deviceid>1003</deviceid>
<deviceid>1004</deviceid>
<deviceid>1005</deviceid>
<deviceid>1006</deviceid>
<deviceid>1007</deviceid>
<deviceid>1008</deviceid>
<deviceid>1009</deviceid>
<deviceid>100A</deviceid>
<deviceid>100B</deviceid>
<deviceid>100C</deviceid>
<deviceid>100D</deviceid>
<deviceid>100E</deviceid>
<deviceid>100F</deviceid>
<deviceid>1010</deviceid>
<deviceid>6340</deviceid>
<deviceid>6341</deviceid>
<deviceid>634A</deviceid>
<deviceid>634B</deviceid>
<deviceid>6354</deviceid>
<deviceid>6368</deviceid>
<deviceid>6369</deviceid>
<deviceid>6372</deviceid>
<deviceid>6732</deviceid>
<deviceid>6733</deviceid>
<deviceid>673C</deviceid>
<deviceid>673D</deviceid>
<deviceid>6746</deviceid>
<deviceid>6750</deviceid>
<deviceid>6751</deviceid>
<deviceid>675A</deviceid>
<deviceid>6764</deviceid>
<deviceid>6765</deviceid>
<deviceid>676E</deviceid>
<deviceid>6778</deviceid>
<deviceid>1013</deviceid>
<deviceid>1015</deviceid>
<deviceid>1017</deviceid>
<deviceid>1019</deviceid>
<deviceid>101B</deviceid>
<deviceid>101D</deviceid>
<deviceid>101F</deviceid>
<deviceid>1021</deviceid>
<deviceid>1023</deviceid>
<deviceid>1025</deviceid>
<deviceid>1027</deviceid>
<deviceid>1029</deviceid>
<deviceid>102B</deviceid>
<deviceid>102F</deviceid>
</NIC>

<NIC>
<manufacturer>1137</manufacturer>
<deviceid>0043</deviceid>
</NIC>

</SupportedNetworkInterfaceCards>

Related topics
Setting Up Kernel-Mode Debugging over a Network Cable in Visual Studio
Setting Up KDNET Network Kernel Debugging Automatically
Setting Up KDNET Network Kernel Debugging Manually
Supported Ethernet NICs for Network Kernel Debugging in Windows 8
Supported Ethernet NICs for Network Kernel Debugging in Windows 8.1
 Supported Ethernet NICs for Network Kernel
Debugging in Windows 10, version 1809 (Redstone
5) Build 17763
3/5/2021 • 2 minutes to read • Edit Online

To do kernel debugging over an Ethernet network cable, the target computer must have a supported network
interface card (NIC).
During kernel debugging, the computer that runs the debugger is called the host computer, and the computer
being debugged is called the target computer. For more information, see Setting Up KDNET Network Kernel
Debugging Automatically.
For general information on supported network adapters see Supported Ethernet NICs for Network Kernel
Debugging in Windows 10.
Version Information
The list of supported adapters is for the following versions of Windows
Windows 10, version 1809 (Redstone 5) Build 17763

<?xml version="1.0" encoding="utf-8"?>

<SupportedNetworkInterfaceCards>
<NIC>
<manufacturer>8086</manufacturer>
<deviceid>1000</deviceid>
<deviceid>1001</deviceid>
<deviceid>1004</deviceid>
<deviceid>1008</deviceid>
<deviceid>1009</deviceid>
<deviceid>100C</deviceid>
<deviceid>100D</deviceid>
<deviceid>100E</deviceid>
<deviceid>1015</deviceid>
<deviceid>1016</deviceid>
<deviceid>1017</deviceid>
<deviceid>101E</deviceid>
<deviceid>100F</deviceid>
<deviceid>1011</deviceid>
<deviceid>1026</deviceid>
<deviceid>1027</deviceid>
<deviceid>1028</deviceid>
<deviceid>1010</deviceid>
<deviceid>1012</deviceid>
<deviceid>101D</deviceid>
<deviceid>1079</deviceid>
<deviceid>107A</deviceid>
<deviceid>107B</deviceid>
<deviceid>108A</deviceid>
<deviceid>1099</deviceid>
<deviceid>10B5</deviceid>
<deviceid>1013</deviceid>
<deviceid>1018</deviceid>
<deviceid>1014</deviceid>
<deviceid>1078</deviceid>
<deviceid>1076</deviceid>
<deviceid>107C</deviceid>
<deviceid>1077</deviceid>
<deviceid>1077</deviceid>
<deviceid>1019</deviceid>
<deviceid>101A</deviceid>
<deviceid>1075</deviceid>
<deviceid>105E</deviceid>
<deviceid>105F</deviceid>
<deviceid>1060</deviceid>
<deviceid>10D9</deviceid>
<deviceid>10DA</deviceid>
<deviceid>10A4</deviceid>
<deviceid>10D5</deviceid>
<deviceid>10A5</deviceid>
<deviceid>10BC</deviceid>
<deviceid>107D</deviceid>
<deviceid>107E</deviceid>
<deviceid>107F</deviceid>
<deviceid>10B9</deviceid>
<deviceid>108B</deviceid>
<deviceid>108C</deviceid>
<deviceid>109A</deviceid>
<deviceid>10D3</deviceid>
<deviceid>10F6</deviceid>
<deviceid>150C</deviceid>
<deviceid>1096</deviceid>
<deviceid>1098</deviceid>
<deviceid>10BA</deviceid>
<deviceid>10BB</deviceid>
<deviceid>1501</deviceid>
<deviceid>1049</deviceid>
<deviceid>104A</deviceid>
<deviceid>104B</deviceid>
<deviceid>104C</deviceid>
<deviceid>10C4</deviceid>
<deviceid>10C5</deviceid>
<deviceid>104D</deviceid>
<deviceid>10BF</deviceid>
<deviceid>10F5</deviceid>
<deviceid>10CB</deviceid>
<deviceid>10BD</deviceid>
<deviceid>10E5</deviceid>
<deviceid>294C</deviceid>
<deviceid>10C0</deviceid>
<deviceid>10C3</deviceid>
<deviceid>10C2</deviceid>
<deviceid>10CC</deviceid>
<deviceid>10CD</deviceid>
<deviceid>10CE</deviceid>
<deviceid>10DE</deviceid>
<deviceid>10DF</deviceid>
<deviceid>1525</deviceid>
<deviceid>10EA</deviceid>
<deviceid>10EB</deviceid>
<deviceid>10EF</deviceid>
<deviceid>10F0</deviceid>
<deviceid>1502</deviceid>
<deviceid>1503</deviceid>
<deviceid>153A</deviceid>
<deviceid>153B</deviceid>
<deviceid>155A</deviceid>
<deviceid>1559</deviceid>
<deviceid>15A0</deviceid>
<deviceid>15A1</deviceid>
<deviceid>15A2</deviceid>
<deviceid>15A3</deviceid>
<deviceid>156F</deviceid>
<deviceid>1570</deviceid>
<deviceid>15B7</deviceid>
<deviceid>15B8</deviceid>
<deviceid>15B9</deviceid>
<deviceid>15D7</deviceid>
<deviceid>15D7</deviceid>
<deviceid>15D8</deviceid>
<deviceid>15E3</deviceid>
<deviceid>15D6</deviceid>
<deviceid>15BD</deviceid>
<deviceid>15BE</deviceid>
<deviceid>15BB</deviceid>
<deviceid>15BC</deviceid>
<deviceid>15DF</deviceid>
<deviceid>15E0</deviceid>
<deviceid>15E1</deviceid>
<deviceid>15E2</deviceid>
<deviceid>10C9</deviceid>
<deviceid>10E6</deviceid>
<deviceid>10E7</deviceid>
<deviceid>10E8</deviceid>
<deviceid>1526</deviceid>
<deviceid>150A</deviceid>
<deviceid>1518</deviceid>
<deviceid>150D</deviceid>
<deviceid>10A7</deviceid>
<deviceid>10A9</deviceid>
<deviceid>10D6</deviceid>
<deviceid>150E</deviceid>
<deviceid>150F</deviceid>
<deviceid>1510</deviceid>
<deviceid>1511</deviceid>
<deviceid>1516</deviceid>
<deviceid>1527</deviceid>
<deviceid>1521</deviceid>
<deviceid>1522</deviceid>
<deviceid>1523</deviceid>
<deviceid>1524</deviceid>
<deviceid>1546</deviceid>
<deviceid>1533</deviceid>
<deviceid>1534</deviceid>
<deviceid>1535</deviceid>
<deviceid>1536</deviceid>
<deviceid>1537</deviceid>
<deviceid>1538</deviceid>
<deviceid>157B</deviceid>
<deviceid>157C</deviceid>
<deviceid>1539</deviceid>
<deviceid>1F40</deviceid>
<deviceid>1F41</deviceid>
<deviceid>1F45</deviceid>
<deviceid>0438</deviceid>
<deviceid>043A</deviceid>
<deviceid>043C</deviceid>
<deviceid>0440</deviceid>
<deviceid>10C6</deviceid>
<deviceid>10C7</deviceid>
<deviceid>10C8</deviceid>
<deviceid>150B</deviceid>
<deviceid>10DB</deviceid>
<deviceid>10DD</deviceid>
<deviceid>10EC</deviceid>
<deviceid>10F1</deviceid>
<deviceid>10E1</deviceid>
<deviceid>10F4</deviceid>
<deviceid>10F7</deviceid>
<deviceid>1514</deviceid>
<deviceid>1517</deviceid>
<deviceid>10F8</deviceid>
<deviceid>000C</deviceid>
<deviceid>1F63</deviceid>
<deviceid>10F9</deviceid>
<deviceid>10FB</deviceid>
<deviceid>11A9</deviceid>
<deviceid>1071</deviceid>
 <deviceid>1071</deviceid>
<deviceid>1F72</deviceid>
<deviceid>17D0</deviceid>
<deviceid>0470</deviceid>
<deviceid>211B</deviceid>
<deviceid>8976</deviceid>
<deviceid>2159</deviceid>
<deviceid>000D</deviceid>
<deviceid>0008</deviceid>
<deviceid>152A</deviceid>
<deviceid>1529</deviceid>
<deviceid>1507</deviceid>
<deviceid>154D</deviceid>
<deviceid>154A</deviceid>
<deviceid>1558</deviceid>
<deviceid>1557</deviceid>
<deviceid>0001</deviceid>
<deviceid>10FC</deviceid>
<deviceid>151C</deviceid>
<deviceid>1528</deviceid>
<deviceid>1560</deviceid>
<deviceid>1563</deviceid>
<deviceid>ABCD</deviceid>
<deviceid>15AA</deviceid>
<deviceid>15AB</deviceid>
<deviceid>15AC</deviceid>
<deviceid>15AD</deviceid>
<deviceid>15AE</deviceid>
</NIC>

<NIC>
<manufacturer>10EC</manufacturer>
<deviceid>8136</deviceid>
<deviceid>8137</deviceid>
<deviceid>8168</deviceid>
<deviceid>8167</deviceid>
<deviceid>8169</deviceid>
<deviceid>8166</deviceid>
</NIC>

<NIC>
<manufacturer>14E4</manufacturer>
<deviceid>1644</deviceid>
<deviceid>1645</deviceid>
<deviceid>1646</deviceid>
<deviceid>16A6</deviceid>
<deviceid>16C6</deviceid>
<deviceid>1647</deviceid>
<deviceid>16A7</deviceid>
<deviceid>16C7</deviceid>
<deviceid>164D</deviceid>
<deviceid>1648</deviceid>
<deviceid>16A8</deviceid>
<deviceid>1653</deviceid>
<deviceid>166E</deviceid>
<deviceid>1654</deviceid>
<deviceid>165D</deviceid>
<deviceid>165E</deviceid>
<deviceid>166D</deviceid>
<deviceid>170D</deviceid>
<deviceid>170E</deviceid>
<deviceid>1696</deviceid>
<deviceid>1676</deviceid>
<deviceid>1677</deviceid>
<deviceid>1659</deviceid>
<deviceid>167C</deviceid>
<deviceid>167D</deviceid>
<deviceid>169D</deviceid>
<deviceid>16F7</deviceid>
<deviceid>16FD</deviceid>
<deviceid>16FD</deviceid>
<deviceid>16FE</deviceid>
<deviceid>16DD</deviceid>
<deviceid>1668</deviceid>
<deviceid>1669</deviceid>
<deviceid>1678</deviceid>
<deviceid>1679</deviceid>
<deviceid>1600</deviceid>
<deviceid>1601</deviceid>
<deviceid>166A</deviceid>
<deviceid>166B</deviceid>
<deviceid>16FF</deviceid>
<deviceid>170F</deviceid>
<deviceid>169B</deviceid>
<deviceid>1693</deviceid>
<deviceid>167F</deviceid>
<deviceid>169A</deviceid>
<deviceid>1698</deviceid>
<deviceid>1692</deviceid>
<deviceid>1694</deviceid>
<deviceid>1690</deviceid>
<deviceid>1691</deviceid>
<deviceid>1699</deviceid>
<deviceid>16A0</deviceid>
<deviceid>167B</deviceid>
<deviceid>1673</deviceid>
<deviceid>165A</deviceid>
<deviceid>1674</deviceid>
<deviceid>1681</deviceid>
<deviceid>1680</deviceid>
<deviceid>1688</deviceid>
<deviceid>167A</deviceid>
<deviceid>1672</deviceid>
<deviceid>1684</deviceid>
<deviceid>165B</deviceid>
<deviceid>16B1</deviceid>
<deviceid>16B5</deviceid>
<deviceid>16B0</deviceid>
<deviceid>16B4</deviceid>
<deviceid>16B2</deviceid>
<deviceid>16B6</deviceid>
<deviceid>1682</deviceid>
<deviceid>1686</deviceid>
<deviceid>16B3</deviceid>
<deviceid>16B7</deviceid>
<deviceid>1655</deviceid>
<deviceid>1665</deviceid>
<deviceid>1656</deviceid>
<deviceid>1657</deviceid>
<deviceid>165F</deviceid>
<deviceid>165C</deviceid>
<deviceid>1683</deviceid>
<deviceid>1641</deviceid>
<deviceid>1642</deviceid>
<deviceid>1643</deviceid>
<deviceid>1687</deviceid>
<deviceid>164A</deviceid>
<deviceid>16AA</deviceid>
<deviceid>164C</deviceid>
<deviceid>16AC</deviceid>
<deviceid>1639</deviceid>
<deviceid>163A</deviceid>
<deviceid>163B</deviceid>
<deviceid>163C</deviceid>
<deviceid>164E</deviceid>
<deviceid>164F</deviceid>
<deviceid>1650</deviceid>
<deviceid>1662</deviceid>
<deviceid>1663</deviceid>
<deviceid>168A</deviceid>
 <deviceid>168A</deviceid>
<deviceid>168D</deviceid>
<deviceid>16A1</deviceid>
<deviceid>16A2</deviceid>
<deviceid>168E</deviceid>
<deviceid>163D</deviceid>
<deviceid>16A5</deviceid>
<deviceid>16A4</deviceid>
<deviceid>16AE</deviceid>
<deviceid>163E</deviceid>
</NIC>

<NIC>
<manufacturer>1969</manufacturer>
<deviceid>1062</deviceid>
<deviceid>1063</deviceid>
<deviceid>2060</deviceid>
<deviceid>2062</deviceid>
<deviceid>1073</deviceid>
<deviceid>1083</deviceid>
<deviceid>1090</deviceid>
<deviceid>1091</deviceid>
<deviceid>E091</deviceid>
<deviceid>10A0</deviceid>
<deviceid>10A1</deviceid>
<deviceid>E0A1</deviceid>
<deviceid>10B0</deviceid>
<deviceid>10B1</deviceid>
<deviceid>E0B1</deviceid>
<deviceid>10C0</deviceid>
<deviceid>10C1</deviceid>
<deviceid>E0C1</deviceid>
<deviceid>10D0</deviceid>
<deviceid>10D1</deviceid>
<deviceid>E0D1</deviceid>
<deviceid>10E0</deviceid>
<deviceid>10E1</deviceid>
<deviceid>E0E1</deviceid>
<deviceid>10F0</deviceid>
<deviceid>10F1</deviceid>
<deviceid>E0F1</deviceid>
</NIC>

<NIC>
<manufacturer>19A2</manufacturer>
<deviceid>0211</deviceid>
<deviceid>0215</deviceid>
<deviceid>0221</deviceid>
<deviceid>0700</deviceid>
<deviceid>0710</deviceid>
</NIC>

<NIC>
<manufacturer>10DF</manufacturer>
<deviceid>0720</deviceid>
<deviceid>E220</deviceid>
</NIC>

<NIC>
<manufacturer>15B3</manufacturer>
<deviceid>1000</deviceid>
<deviceid>1001</deviceid>
<deviceid>1002</deviceid>
<deviceid>1003</deviceid>
<deviceid>1004</deviceid>
<deviceid>1005</deviceid>
<deviceid>1006</deviceid>
<deviceid>1007</deviceid>
<deviceid>1008</deviceid>
 <deviceid>1009</deviceid>
<deviceid>100A</deviceid>
<deviceid>100B</deviceid>
<deviceid>100C</deviceid>
<deviceid>100D</deviceid>
<deviceid>100E</deviceid>
<deviceid>100F</deviceid>
<deviceid>1010</deviceid>
<deviceid>6340</deviceid>
<deviceid>6341</deviceid>
<deviceid>634A</deviceid>
<deviceid>634B</deviceid>
<deviceid>6354</deviceid>
<deviceid>6368</deviceid>
<deviceid>6369</deviceid>
<deviceid>6372</deviceid>
<deviceid>6732</deviceid>
<deviceid>6733</deviceid>
<deviceid>673C</deviceid>
<deviceid>673D</deviceid>
<deviceid>6746</deviceid>
<deviceid>6750</deviceid>
<deviceid>6751</deviceid>
<deviceid>675A</deviceid>
<deviceid>6764</deviceid>
<deviceid>6765</deviceid>
<deviceid>676E</deviceid>
<deviceid>6778</deviceid>
<deviceid>1013</deviceid>
<deviceid>1015</deviceid>
<deviceid>1017</deviceid>
<deviceid>1019</deviceid>
<deviceid>101B</deviceid>
<deviceid>101D</deviceid>
<deviceid>101F</deviceid>
<deviceid>1021</deviceid>
<deviceid>1023</deviceid>
<deviceid>1025</deviceid>
<deviceid>1027</deviceid>
<deviceid>1029</deviceid>
<deviceid>102B</deviceid>
<deviceid>102F</deviceid>
</NIC>

<NIC>
<manufacturer>1137</manufacturer>
<deviceid>0043</deviceid>
</NIC>

</SupportedNetworkInterfaceCards>

Related topics
Setting Up Kernel-Mode Debugging over a Network Cable in Visual Studio
Setting Up KDNET Network Kernel Debugging Automatically
Setting Up KDNET Network Kernel Debugging Manually
Supported Ethernet NICs for Network Kernel Debugging in Windows 8
Supported Ethernet NICs for Network Kernel Debugging in Windows 8.1
 Supported Ethernet NICs for Network Kernel
Debugging in Windows 10, version 1803 (Redstone
4) Build 17134
3/5/2021 • 2 minutes to read • Edit Online

To do kernel debugging over an Ethernet network cable, the target computer must have a supported network
interface card (NIC).
During kernel debugging, the computer that runs the debugger is called the host computer, and the computer
being debugged is called the target computer. For more information, see Setting Up KDNET Network Kernel
Debugging Automatically.
For general information on supported network adapters see Supported Ethernet NICs for Network Kernel
Debugging in Windows 10.
Version Information
The list of supported adapters is for the following versions of Windows.
Windows 10, version 1803 (Redstone 4) Build 17134

<?xml version="1.0" encoding="utf-8"?>

<SupportedNetworkInterfaceCards>
<NIC>
<manufacturer>8086</manufacturer>
<deviceid>1000</deviceid>
<deviceid>1001</deviceid>
<deviceid>1004</deviceid>
<deviceid>1008</deviceid>
<deviceid>1009</deviceid>
<deviceid>100C</deviceid>
<deviceid>100D</deviceid>
<deviceid>100E</deviceid>
<deviceid>1015</deviceid>
<deviceid>1016</deviceid>
<deviceid>1017</deviceid>
<deviceid>101E</deviceid>
<deviceid>100F</deviceid>
<deviceid>1011</deviceid>
<deviceid>1026</deviceid>
<deviceid>1027</deviceid>
<deviceid>1028</deviceid>
<deviceid>1010</deviceid>
<deviceid>1012</deviceid>
<deviceid>101D</deviceid>
<deviceid>1079</deviceid>
<deviceid>107A</deviceid>
<deviceid>107B</deviceid>
<deviceid>108A</deviceid>
<deviceid>1099</deviceid>
<deviceid>10B5</deviceid>
<deviceid>1013</deviceid>
<deviceid>1018</deviceid>
<deviceid>1014</deviceid>
<deviceid>1078</deviceid>
<deviceid>1076</deviceid>
<deviceid>107C</deviceid>
<deviceid>1077</deviceid>
<deviceid>1077</deviceid>
<deviceid>1019</deviceid>
<deviceid>101A</deviceid>
<deviceid>1075</deviceid>
<deviceid>105E</deviceid>
<deviceid>105F</deviceid>
<deviceid>1060</deviceid>
<deviceid>10D9</deviceid>
<deviceid>10DA</deviceid>
<deviceid>10A4</deviceid>
<deviceid>10D5</deviceid>
<deviceid>10A5</deviceid>
<deviceid>10BC</deviceid>
<deviceid>107D</deviceid>
<deviceid>107E</deviceid>
<deviceid>107F</deviceid>
<deviceid>10B9</deviceid>
<deviceid>108B</deviceid>
<deviceid>108C</deviceid>
<deviceid>109A</deviceid>
<deviceid>10D3</deviceid>
<deviceid>10F6</deviceid>
<deviceid>150C</deviceid>
<deviceid>1096</deviceid>
<deviceid>1098</deviceid>
<deviceid>10BA</deviceid>
<deviceid>10BB</deviceid>
<deviceid>1501</deviceid>
<deviceid>1049</deviceid>
<deviceid>104A</deviceid>
<deviceid>104B</deviceid>
<deviceid>104C</deviceid>
<deviceid>10C4</deviceid>
<deviceid>10C5</deviceid>
<deviceid>104D</deviceid>
<deviceid>10BF</deviceid>
<deviceid>10F5</deviceid>
<deviceid>10CB</deviceid>
<deviceid>10BD</deviceid>
<deviceid>10E5</deviceid>
<deviceid>294C</deviceid>
<deviceid>10C0</deviceid>
<deviceid>10C3</deviceid>
<deviceid>10C2</deviceid>
<deviceid>10CC</deviceid>
<deviceid>10CD</deviceid>
<deviceid>10CE</deviceid>
<deviceid>10DE</deviceid>
<deviceid>10DF</deviceid>
<deviceid>1525</deviceid>
<deviceid>10EA</deviceid>
<deviceid>10EB</deviceid>
<deviceid>10EF</deviceid>
<deviceid>10F0</deviceid>
<deviceid>1502</deviceid>
<deviceid>1503</deviceid>
<deviceid>153A</deviceid>
<deviceid>153B</deviceid>
<deviceid>155A</deviceid>
<deviceid>1559</deviceid>
<deviceid>15A0</deviceid>
<deviceid>15A1</deviceid>
<deviceid>15A2</deviceid>
<deviceid>15A3</deviceid>
<deviceid>156F</deviceid>
<deviceid>1570</deviceid>
<deviceid>15B7</deviceid>
<deviceid>15B8</deviceid>
<deviceid>15B9</deviceid>
<deviceid>15D7</deviceid>
<deviceid>15D7</deviceid>
<deviceid>15D8</deviceid>
<deviceid>15E3</deviceid>
<deviceid>15D6</deviceid>
<deviceid>15BD</deviceid>
<deviceid>15BE</deviceid>
<deviceid>15BB</deviceid>
<deviceid>15BC</deviceid>
<deviceid>15DF</deviceid>
<deviceid>15E0</deviceid>
<deviceid>15E1</deviceid>
<deviceid>15E2</deviceid>
<deviceid>10C9</deviceid>
<deviceid>10E6</deviceid>
<deviceid>10E7</deviceid>
<deviceid>10E8</deviceid>
<deviceid>1526</deviceid>
<deviceid>150A</deviceid>
<deviceid>1518</deviceid>
<deviceid>150D</deviceid>
<deviceid>10A7</deviceid>
<deviceid>10A9</deviceid>
<deviceid>10D6</deviceid>
<deviceid>150E</deviceid>
<deviceid>150F</deviceid>
<deviceid>1510</deviceid>
<deviceid>1511</deviceid>
<deviceid>1516</deviceid>
<deviceid>1527</deviceid>
<deviceid>1521</deviceid>
<deviceid>1522</deviceid>
<deviceid>1523</deviceid>
<deviceid>1524</deviceid>
<deviceid>1546</deviceid>
<deviceid>1533</deviceid>
<deviceid>1534</deviceid>
<deviceid>1535</deviceid>
<deviceid>1536</deviceid>
<deviceid>1537</deviceid>
<deviceid>1538</deviceid>
<deviceid>157B</deviceid>
<deviceid>157C</deviceid>
<deviceid>1539</deviceid>
<deviceid>1F40</deviceid>
<deviceid>1F41</deviceid>
<deviceid>1F45</deviceid>
<deviceid>0438</deviceid>
<deviceid>043A</deviceid>
<deviceid>043C</deviceid>
<deviceid>0440</deviceid>
<deviceid>10C6</deviceid>
<deviceid>10C7</deviceid>
<deviceid>10C8</deviceid>
<deviceid>150B</deviceid>
<deviceid>10DB</deviceid>
<deviceid>10DD</deviceid>
<deviceid>10EC</deviceid>
<deviceid>10F1</deviceid>
<deviceid>10E1</deviceid>
<deviceid>10F4</deviceid>
<deviceid>10F7</deviceid>
<deviceid>1514</deviceid>
<deviceid>1517</deviceid>
<deviceid>10F8</deviceid>
<deviceid>000C</deviceid>
<deviceid>1F63</deviceid>
<deviceid>10F9</deviceid>
<deviceid>10FB</deviceid>
<deviceid>11A9</deviceid>
<deviceid>1071</deviceid>
 <deviceid>1071</deviceid>
<deviceid>1F72</deviceid>
<deviceid>17D0</deviceid>
<deviceid>0470</deviceid>
<deviceid>211B</deviceid>
<deviceid>8976</deviceid>
<deviceid>2159</deviceid>
<deviceid>000D</deviceid>
<deviceid>0008</deviceid>
<deviceid>152A</deviceid>
<deviceid>1529</deviceid>
<deviceid>1507</deviceid>
<deviceid>154D</deviceid>
<deviceid>154A</deviceid>
<deviceid>1558</deviceid>
<deviceid>1557</deviceid>
<deviceid>0001</deviceid>
<deviceid>10FC</deviceid>
<deviceid>151C</deviceid>
<deviceid>1528</deviceid>
<deviceid>1560</deviceid>
<deviceid>1563</deviceid>
<deviceid>ABCD</deviceid>
<deviceid>15AA</deviceid>
<deviceid>15AB</deviceid>
<deviceid>15AC</deviceid>
<deviceid>15AD</deviceid>
<deviceid>15AE</deviceid>
</NIC>

<NIC>
<manufacturer>10EC</manufacturer>
<deviceid>8136</deviceid>
<deviceid>8137</deviceid>
<deviceid>8168</deviceid>
<deviceid>8167</deviceid>
<deviceid>8169</deviceid>
<deviceid>8166</deviceid>
</NIC>

<NIC>
<manufacturer>14E4</manufacturer>
<deviceid>1644</deviceid>
<deviceid>1645</deviceid>
<deviceid>1646</deviceid>
<deviceid>16A6</deviceid>
<deviceid>16C6</deviceid>
<deviceid>1647</deviceid>
<deviceid>16A7</deviceid>
<deviceid>16C7</deviceid>
<deviceid>164D</deviceid>
<deviceid>1648</deviceid>
<deviceid>16A8</deviceid>
<deviceid>1653</deviceid>
<deviceid>166E</deviceid>
<deviceid>1654</deviceid>
<deviceid>165D</deviceid>
<deviceid>165E</deviceid>
<deviceid>166D</deviceid>
<deviceid>170D</deviceid>
<deviceid>170E</deviceid>
<deviceid>1696</deviceid>
<deviceid>1676</deviceid>
<deviceid>1677</deviceid>
<deviceid>1659</deviceid>
<deviceid>167C</deviceid>
<deviceid>167D</deviceid>
<deviceid>169D</deviceid>
<deviceid>16F7</deviceid>
<deviceid>16FD</deviceid>
<deviceid>16FD</deviceid>
<deviceid>16FE</deviceid>
<deviceid>16DD</deviceid>
<deviceid>1668</deviceid>
<deviceid>1669</deviceid>
<deviceid>1678</deviceid>
<deviceid>1679</deviceid>
<deviceid>1600</deviceid>
<deviceid>1601</deviceid>
<deviceid>166A</deviceid>
<deviceid>166B</deviceid>
<deviceid>16FF</deviceid>
<deviceid>170F</deviceid>
<deviceid>169B</deviceid>
<deviceid>1693</deviceid>
<deviceid>167F</deviceid>
<deviceid>169A</deviceid>
<deviceid>1698</deviceid>
<deviceid>1692</deviceid>
<deviceid>1694</deviceid>
<deviceid>1690</deviceid>
<deviceid>1691</deviceid>
<deviceid>1699</deviceid>
<deviceid>16A0</deviceid>
<deviceid>167B</deviceid>
<deviceid>1673</deviceid>
<deviceid>165A</deviceid>
<deviceid>1674</deviceid>
<deviceid>1681</deviceid>
<deviceid>1680</deviceid>
<deviceid>1688</deviceid>
<deviceid>167A</deviceid>
<deviceid>1672</deviceid>
<deviceid>1684</deviceid>
<deviceid>165B</deviceid>
<deviceid>16B1</deviceid>
<deviceid>16B5</deviceid>
<deviceid>16B0</deviceid>
<deviceid>16B4</deviceid>
<deviceid>16B2</deviceid>
<deviceid>16B6</deviceid>
<deviceid>1682</deviceid>
<deviceid>1686</deviceid>
<deviceid>16B3</deviceid>
<deviceid>16B7</deviceid>
<deviceid>1655</deviceid>
<deviceid>1665</deviceid>
<deviceid>1656</deviceid>
<deviceid>1657</deviceid>
<deviceid>165F</deviceid>
<deviceid>165C</deviceid>
<deviceid>1683</deviceid>
<deviceid>1641</deviceid>
<deviceid>1642</deviceid>
<deviceid>1643</deviceid>
<deviceid>1687</deviceid>
<deviceid>164A</deviceid>
<deviceid>16AA</deviceid>
<deviceid>164C</deviceid>
<deviceid>16AC</deviceid>
<deviceid>1639</deviceid>
<deviceid>163A</deviceid>
<deviceid>163B</deviceid>
<deviceid>163C</deviceid>
<deviceid>164E</deviceid>
<deviceid>164F</deviceid>
<deviceid>1650</deviceid>
<deviceid>1662</deviceid>
<deviceid>1663</deviceid>
<deviceid>168A</deviceid>
 <deviceid>168A</deviceid>
<deviceid>168D</deviceid>
<deviceid>16A1</deviceid>
<deviceid>16A2</deviceid>
<deviceid>168E</deviceid>
<deviceid>163D</deviceid>
<deviceid>16A5</deviceid>
<deviceid>16A4</deviceid>
<deviceid>16AE</deviceid>
<deviceid>163E</deviceid>
</NIC>

<NIC>
<manufacturer>1969</manufacturer>
<deviceid>1062</deviceid>
<deviceid>1063</deviceid>
<deviceid>2060</deviceid>
<deviceid>2062</deviceid>
<deviceid>1073</deviceid>
<deviceid>1083</deviceid>
<deviceid>1090</deviceid>
<deviceid>1091</deviceid>
<deviceid>E091</deviceid>
<deviceid>10A0</deviceid>
<deviceid>10A1</deviceid>
<deviceid>E0A1</deviceid>
<deviceid>10B0</deviceid>
<deviceid>10B1</deviceid>
<deviceid>E0B1</deviceid>
<deviceid>10C0</deviceid>
<deviceid>10C1</deviceid>
<deviceid>E0C1</deviceid>
<deviceid>10D0</deviceid>
<deviceid>10D1</deviceid>
<deviceid>E0D1</deviceid>
<deviceid>10E0</deviceid>
<deviceid>10E1</deviceid>
<deviceid>E0E1</deviceid>
<deviceid>10F0</deviceid>
<deviceid>10F1</deviceid>
<deviceid>E0F1</deviceid>
</NIC>

<NIC>
<manufacturer>19A2</manufacturer>
<deviceid>0211</deviceid>
<deviceid>0215</deviceid>
<deviceid>0221</deviceid>
<deviceid>0700</deviceid>
<deviceid>0710</deviceid>
</NIC>

<NIC>
<manufacturer>10DF</manufacturer>
<deviceid>0720</deviceid>
<deviceid>E220</deviceid>
</NIC>

<NIC>
<manufacturer>15B3</manufacturer>
<deviceid>1000</deviceid>
<deviceid>1001</deviceid>
<deviceid>1002</deviceid>
<deviceid>1003</deviceid>
<deviceid>1004</deviceid>
<deviceid>1005</deviceid>
<deviceid>1006</deviceid>
<deviceid>1007</deviceid>
<deviceid>1008</deviceid>
 <deviceid>1009</deviceid>
<deviceid>100A</deviceid>
<deviceid>100B</deviceid>
<deviceid>100C</deviceid>
<deviceid>100D</deviceid>
<deviceid>100E</deviceid>
<deviceid>100F</deviceid>
<deviceid>1010</deviceid>
<deviceid>6340</deviceid>
<deviceid>6341</deviceid>
<deviceid>634A</deviceid>
<deviceid>634B</deviceid>
<deviceid>6354</deviceid>
<deviceid>6368</deviceid>
<deviceid>6369</deviceid>
<deviceid>6372</deviceid>
<deviceid>6732</deviceid>
<deviceid>6733</deviceid>
<deviceid>673C</deviceid>
<deviceid>673D</deviceid>
<deviceid>6746</deviceid>
<deviceid>6750</deviceid>
<deviceid>6751</deviceid>
<deviceid>675A</deviceid>
<deviceid>6764</deviceid>
<deviceid>6765</deviceid>
<deviceid>676E</deviceid>
<deviceid>6778</deviceid>
<deviceid>1013</deviceid>
<deviceid>1015</deviceid>
<deviceid>1017</deviceid>
<deviceid>1019</deviceid>
<deviceid>101B</deviceid>
<deviceid>101D</deviceid>
<deviceid>101F</deviceid>
<deviceid>1021</deviceid>
<deviceid>1023</deviceid>
<deviceid>1025</deviceid>
<deviceid>1027</deviceid>
<deviceid>1029</deviceid>
<deviceid>102B</deviceid>
<deviceid>102F</deviceid>
</NIC>

<NIC>
<manufacturer>1137</manufacturer>
<deviceid>0043</deviceid>
</NIC>

</SupportedNetworkInterfaceCards>

Related topics
Setting Up Kernel-Mode Debugging over a Network Cable in Visual Studio
Setting Up KDNET Network Kernel Debugging Automatically
Setting Up KDNET Network Kernel Debugging Manually
Supported Ethernet NICs for Network Kernel Debugging in Windows 8
Supported Ethernet NICs for Network Kernel Debugging in Windows 8.1
 Supported Ethernet NICs for Network Kernel
Debugging in Windows 10 version 1709 (Redstone
3) Build 16299
3/5/2021 • 2 minutes to read • Edit Online

To do kernel debugging over an Ethernet network cable, the target computer must have a supported network
interface card (NIC).
During kernel debugging, the computer that runs the debugger is called the host computer, and the computer
being debugged is called the target computer. For more information, see Setting Up KDNET Network Kernel
Debugging Automatically.
For general information on supported network adapters see Supported Ethernet NICs for Network Kernel
Debugging in Windows 10.
Version Information
The list of supported adapters is for the following versions of Windows
Windows 10, version 1709 (Redstone 3) Build 16299

<?xml version="1.0" encoding="utf-8"?>

<SupportedNetworkInterfaceCards>
<NIC>
<manufacturer>8086</manufacturer>
<deviceid>1000</deviceid>
<deviceid>1001</deviceid>
<deviceid>1004</deviceid>
<deviceid>1008</deviceid>
<deviceid>1009</deviceid>
<deviceid>100C</deviceid>
<deviceid>100D</deviceid>
<deviceid>100E</deviceid>
<deviceid>1015</deviceid>
<deviceid>1016</deviceid>
<deviceid>1017</deviceid>
<deviceid>101E</deviceid>
<deviceid>100F</deviceid>
<deviceid>1011</deviceid>
<deviceid>1026</deviceid>
<deviceid>1027</deviceid>
<deviceid>1028</deviceid>
<deviceid>1010</deviceid>
<deviceid>1012</deviceid>
<deviceid>101D</deviceid>
<deviceid>1079</deviceid>
<deviceid>107A</deviceid>
<deviceid>107B</deviceid>
<deviceid>108A</deviceid>
<deviceid>1099</deviceid>
<deviceid>10B5</deviceid>
<deviceid>1013</deviceid>
<deviceid>1018</deviceid>
<deviceid>1014</deviceid>
<deviceid>1078</deviceid>
<deviceid>1076</deviceid>
<deviceid>107C</deviceid>
<deviceid>1077</deviceid>
<deviceid>1077</deviceid>
<deviceid>1019</deviceid>
<deviceid>101A</deviceid>
<deviceid>1075</deviceid>
<deviceid>105E</deviceid>
<deviceid>105F</deviceid>
<deviceid>1060</deviceid>
<deviceid>10D9</deviceid>
<deviceid>10DA</deviceid>
<deviceid>10A4</deviceid>
<deviceid>10D5</deviceid>
<deviceid>10A5</deviceid>
<deviceid>10BC</deviceid>
<deviceid>107D</deviceid>
<deviceid>107E</deviceid>
<deviceid>107F</deviceid>
<deviceid>10B9</deviceid>
<deviceid>108B</deviceid>
<deviceid>108C</deviceid>
<deviceid>109A</deviceid>
<deviceid>10D3</deviceid>
<deviceid>10F6</deviceid>
<deviceid>150C</deviceid>
<deviceid>1096</deviceid>
<deviceid>1098</deviceid>
<deviceid>10BA</deviceid>
<deviceid>10BB</deviceid>
<deviceid>1501</deviceid>
<deviceid>1049</deviceid>
<deviceid>104A</deviceid>
<deviceid>104B</deviceid>
<deviceid>104C</deviceid>
<deviceid>10C4</deviceid>
<deviceid>10C5</deviceid>
<deviceid>104D</deviceid>
<deviceid>10BF</deviceid>
<deviceid>10F5</deviceid>
<deviceid>10CB</deviceid>
<deviceid>10BD</deviceid>
<deviceid>10E5</deviceid>
<deviceid>294C</deviceid>
<deviceid>10C0</deviceid>
<deviceid>10C3</deviceid>
<deviceid>10C2</deviceid>
<deviceid>10CC</deviceid>
<deviceid>10CD</deviceid>
<deviceid>10CE</deviceid>
<deviceid>10DE</deviceid>
<deviceid>10DF</deviceid>
<deviceid>1525</deviceid>
<deviceid>10EA</deviceid>
<deviceid>10EB</deviceid>
<deviceid>10EF</deviceid>
<deviceid>10F0</deviceid>
<deviceid>1502</deviceid>
<deviceid>1503</deviceid>
<deviceid>153A</deviceid>
<deviceid>153B</deviceid>
<deviceid>155A</deviceid>
<deviceid>1559</deviceid>
<deviceid>15A0</deviceid>
<deviceid>15A1</deviceid>
<deviceid>15A2</deviceid>
<deviceid>15A3</deviceid>
<deviceid>156F</deviceid>
<deviceid>1570</deviceid>
<deviceid>15B7</deviceid>
<deviceid>15B8</deviceid>
<deviceid>15B9</deviceid>
<deviceid>15D7</deviceid>
<deviceid>15D7</deviceid>
<deviceid>15D8</deviceid>
<deviceid>15E3</deviceid>
<deviceid>15D6</deviceid>
<deviceid>15BD</deviceid>
<deviceid>15BE</deviceid>
<deviceid>15BB</deviceid>
<deviceid>15BC</deviceid>
<deviceid>15DF</deviceid>
<deviceid>15E0</deviceid>
<deviceid>15E1</deviceid>
<deviceid>15E2</deviceid>
<deviceid>10C9</deviceid>
<deviceid>10E6</deviceid>
<deviceid>10E7</deviceid>
<deviceid>10E8</deviceid>
<deviceid>1526</deviceid>
<deviceid>150A</deviceid>
<deviceid>1518</deviceid>
<deviceid>150D</deviceid>
<deviceid>10A7</deviceid>
<deviceid>10A9</deviceid>
<deviceid>10D6</deviceid>
<deviceid>150E</deviceid>
<deviceid>150F</deviceid>
<deviceid>1510</deviceid>
<deviceid>1511</deviceid>
<deviceid>1516</deviceid>
<deviceid>1527</deviceid>
<deviceid>1521</deviceid>
<deviceid>1522</deviceid>
<deviceid>1523</deviceid>
<deviceid>1524</deviceid>
<deviceid>1546</deviceid>
<deviceid>1533</deviceid>
<deviceid>1534</deviceid>
<deviceid>1535</deviceid>
<deviceid>1536</deviceid>
<deviceid>1537</deviceid>
<deviceid>1538</deviceid>
<deviceid>157B</deviceid>
<deviceid>157C</deviceid>
<deviceid>1539</deviceid>
<deviceid>1F40</deviceid>
<deviceid>1F41</deviceid>
<deviceid>1F45</deviceid>
<deviceid>0438</deviceid>
<deviceid>043A</deviceid>
<deviceid>043C</deviceid>
<deviceid>0440</deviceid>
<deviceid>10C6</deviceid>
<deviceid>10C7</deviceid>
<deviceid>10C8</deviceid>
<deviceid>150B</deviceid>
<deviceid>10DB</deviceid>
<deviceid>10DD</deviceid>
<deviceid>10EC</deviceid>
<deviceid>10F1</deviceid>
<deviceid>10E1</deviceid>
<deviceid>10F4</deviceid>
<deviceid>10F7</deviceid>
<deviceid>1514</deviceid>
<deviceid>1517</deviceid>
<deviceid>10F8</deviceid>
<deviceid>000C</deviceid>
<deviceid>1F63</deviceid>
<deviceid>10F9</deviceid>
<deviceid>10FB</deviceid>
<deviceid>11A9</deviceid>
<deviceid>1071</deviceid>
 <deviceid>1071</deviceid>
<deviceid>1F72</deviceid>
<deviceid>17D0</deviceid>
<deviceid>0470</deviceid>
<deviceid>211B</deviceid>
<deviceid>8976</deviceid>
<deviceid>2159</deviceid>
<deviceid>000D</deviceid>
<deviceid>0008</deviceid>
<deviceid>152A</deviceid>
<deviceid>1529</deviceid>
<deviceid>1507</deviceid>
<deviceid>154D</deviceid>
<deviceid>154A</deviceid>
<deviceid>1558</deviceid>
<deviceid>1557</deviceid>
<deviceid>0001</deviceid>
<deviceid>10FC</deviceid>
<deviceid>151C</deviceid>
<deviceid>1528</deviceid>
<deviceid>1560</deviceid>
<deviceid>1563</deviceid>
<deviceid>ABCD</deviceid>
<deviceid>15AA</deviceid>
<deviceid>15AB</deviceid>
<deviceid>15AC</deviceid>
<deviceid>15AD</deviceid>
<deviceid>15AE</deviceid>
</NIC>

<NIC>
<manufacturer>10EC</manufacturer>
<deviceid>8136</deviceid>
<deviceid>8137</deviceid>
<deviceid>8168</deviceid>
<deviceid>8167</deviceid>
<deviceid>8169</deviceid>
<deviceid>8166</deviceid>
</NIC>

<NIC>
<manufacturer>14E4</manufacturer>
<deviceid>1644</deviceid>
<deviceid>1645</deviceid>
<deviceid>1646</deviceid>
<deviceid>16A6</deviceid>
<deviceid>16C6</deviceid>
<deviceid>1647</deviceid>
<deviceid>16A7</deviceid>
<deviceid>16C7</deviceid>
<deviceid>164D</deviceid>
<deviceid>1648</deviceid>
<deviceid>16A8</deviceid>
<deviceid>1653</deviceid>
<deviceid>166E</deviceid>
<deviceid>1654</deviceid>
<deviceid>165D</deviceid>
<deviceid>165E</deviceid>
<deviceid>166D</deviceid>
<deviceid>170D</deviceid>
<deviceid>170E</deviceid>
<deviceid>1696</deviceid>
<deviceid>1676</deviceid>
<deviceid>1677</deviceid>
<deviceid>1659</deviceid>
<deviceid>167C</deviceid>
<deviceid>167D</deviceid>
<deviceid>169D</deviceid>
<deviceid>16F7</deviceid>
<deviceid>16FD</deviceid>
<deviceid>16FD</deviceid>
<deviceid>16FE</deviceid>
<deviceid>16DD</deviceid>
<deviceid>1668</deviceid>
<deviceid>1669</deviceid>
<deviceid>1678</deviceid>
<deviceid>1679</deviceid>
<deviceid>1600</deviceid>
<deviceid>1601</deviceid>
<deviceid>166A</deviceid>
<deviceid>166B</deviceid>
<deviceid>16FF</deviceid>
<deviceid>170F</deviceid>
<deviceid>169B</deviceid>
<deviceid>1693</deviceid>
<deviceid>167F</deviceid>
<deviceid>169A</deviceid>
<deviceid>1698</deviceid>
<deviceid>1692</deviceid>
<deviceid>1694</deviceid>
<deviceid>1690</deviceid>
<deviceid>1691</deviceid>
<deviceid>1699</deviceid>
<deviceid>16A0</deviceid>
<deviceid>167B</deviceid>
<deviceid>1673</deviceid>
<deviceid>165A</deviceid>
<deviceid>1674</deviceid>
<deviceid>1681</deviceid>
<deviceid>1680</deviceid>
<deviceid>1688</deviceid>
<deviceid>167A</deviceid>
<deviceid>1672</deviceid>
<deviceid>1684</deviceid>
<deviceid>165B</deviceid>
<deviceid>16B1</deviceid>
<deviceid>16B5</deviceid>
<deviceid>16B0</deviceid>
<deviceid>16B4</deviceid>
<deviceid>16B2</deviceid>
<deviceid>16B6</deviceid>
<deviceid>1682</deviceid>
<deviceid>1686</deviceid>
<deviceid>16B3</deviceid>
<deviceid>16B7</deviceid>
<deviceid>1655</deviceid>
<deviceid>1665</deviceid>
<deviceid>1656</deviceid>
<deviceid>1657</deviceid>
<deviceid>165F</deviceid>
<deviceid>165C</deviceid>
<deviceid>1683</deviceid>
<deviceid>1641</deviceid>
<deviceid>1642</deviceid>
<deviceid>1643</deviceid>
<deviceid>1687</deviceid>
<deviceid>164A</deviceid>
<deviceid>16AA</deviceid>
<deviceid>164C</deviceid>
<deviceid>16AC</deviceid>
<deviceid>1639</deviceid>
<deviceid>163A</deviceid>
<deviceid>163B</deviceid>
<deviceid>163C</deviceid>
<deviceid>164E</deviceid>
<deviceid>164F</deviceid>
<deviceid>1650</deviceid>
<deviceid>1662</deviceid>
<deviceid>1663</deviceid>
<deviceid>168A</deviceid>
 <deviceid>168A</deviceid>
<deviceid>168D</deviceid>
<deviceid>16A1</deviceid>
<deviceid>16A2</deviceid>
<deviceid>168E</deviceid>
<deviceid>163D</deviceid>
<deviceid>16A5</deviceid>
<deviceid>16A4</deviceid>
<deviceid>16AE</deviceid>
<deviceid>163E</deviceid>
</NIC>

<NIC>
<manufacturer>1969</manufacturer>
<deviceid>1062</deviceid>
<deviceid>1063</deviceid>
<deviceid>2060</deviceid>
<deviceid>2062</deviceid>
<deviceid>1073</deviceid>
<deviceid>1083</deviceid>
<deviceid>1090</deviceid>
<deviceid>1091</deviceid>
<deviceid>E091</deviceid>
<deviceid>10A0</deviceid>
<deviceid>10A1</deviceid>
<deviceid>E0A1</deviceid>
<deviceid>10B0</deviceid>
<deviceid>10B1</deviceid>
<deviceid>E0B1</deviceid>
<deviceid>10C0</deviceid>
<deviceid>10C1</deviceid>
<deviceid>E0C1</deviceid>
<deviceid>10D0</deviceid>
<deviceid>10D1</deviceid>
<deviceid>E0D1</deviceid>
<deviceid>10E0</deviceid>
<deviceid>10E1</deviceid>
<deviceid>E0E1</deviceid>
<deviceid>10F0</deviceid>
<deviceid>10F1</deviceid>
<deviceid>E0F1</deviceid>
</NIC>

<NIC>
<manufacturer>19A2</manufacturer>
<deviceid>0211</deviceid>
<deviceid>0215</deviceid>
<deviceid>0221</deviceid>
<deviceid>0700</deviceid>
<deviceid>0710</deviceid>
</NIC>

<NIC>
<manufacturer>10DF</manufacturer>
<deviceid>0720</deviceid>
<deviceid>E220</deviceid>
</NIC>

<NIC>
<manufacturer>15B3</manufacturer>
<deviceid>1000</deviceid>
<deviceid>1001</deviceid>
<deviceid>1002</deviceid>
<deviceid>1003</deviceid>
<deviceid>1004</deviceid>
<deviceid>1005</deviceid>
<deviceid>1006</deviceid>
<deviceid>1007</deviceid>
<deviceid>1008</deviceid>
 <deviceid>1009</deviceid>
<deviceid>100A</deviceid>
<deviceid>100B</deviceid>
<deviceid>100C</deviceid>
<deviceid>100D</deviceid>
<deviceid>100E</deviceid>
<deviceid>100F</deviceid>
<deviceid>1010</deviceid>
<deviceid>6340</deviceid>
<deviceid>6341</deviceid>
<deviceid>634A</deviceid>
<deviceid>634B</deviceid>
<deviceid>6354</deviceid>
<deviceid>6368</deviceid>
<deviceid>6369</deviceid>
<deviceid>6372</deviceid>
<deviceid>6732</deviceid>
<deviceid>6733</deviceid>
<deviceid>673C</deviceid>
<deviceid>673D</deviceid>
<deviceid>6746</deviceid>
<deviceid>6750</deviceid>
<deviceid>6751</deviceid>
<deviceid>675A</deviceid>
<deviceid>6764</deviceid>
<deviceid>6765</deviceid>
<deviceid>676E</deviceid>
<deviceid>6778</deviceid>
<deviceid>1013</deviceid>
<deviceid>1015</deviceid>
<deviceid>1017</deviceid>
<deviceid>1019</deviceid>
<deviceid>101B</deviceid>
<deviceid>101D</deviceid>
<deviceid>101F</deviceid>
<deviceid>1021</deviceid>
<deviceid>1023</deviceid>
<deviceid>1025</deviceid>
<deviceid>1027</deviceid>
<deviceid>1029</deviceid>
<deviceid>102B</deviceid>
<deviceid>102F</deviceid>
</NIC>

<NIC>
<manufacturer>1137</manufacturer>
<deviceid>0043</deviceid>
</NIC>

</SupportedNetworkInterfaceCards>

Related topics
Setting Up Kernel-Mode Debugging over a Network Cable in Visual Studio
Setting Up KDNET Network Kernel Debugging Automatically
Setting Up KDNET Network Kernel Debugging Manually
Supported Ethernet NICs for Network Kernel Debugging in Windows 8
Supported Ethernet NICs for Network Kernel Debugging in Windows 8.1
 Supported Ethernet NICs for Network Kernel
Debugging in Windows 10 version 1703 (Redstone
2) Build 15063
3/5/2021 • 2 minutes to read • Edit Online

To do kernel debugging over an Ethernet network cable, the target computer must have a supported network
interface card (NIC).
During kernel debugging, the computer that runs the debugger is called the host computer, and the computer
being debugged is called the target computer. For more information, see Setting Up KDNET Network Kernel
Debugging Automatically.
For general information on supported network adapters see Supported Ethernet NICs for Network Kernel
Debugging in Windows 10.
Version Information
The list of supported adapters is for the following versions of Windows.
Windows 10, version 1703 Redstone 2 Build 15063

<?xml version="1.0" encoding="utf-8"?>

<SupportedNetworkInterfaceCards>
<NIC>
<manufacturer>8086</manufacturer>
<deviceid>1000</deviceid>
<deviceid>1001</deviceid>
<deviceid>1004</deviceid>
<deviceid>1008</deviceid>
<deviceid>1009</deviceid>
<deviceid>100C</deviceid>
<deviceid>100D</deviceid>
<deviceid>100E</deviceid>
<deviceid>1015</deviceid>
<deviceid>1016</deviceid>
<deviceid>1017</deviceid>
<deviceid>101E</deviceid>
<deviceid>100F</deviceid>
<deviceid>1011</deviceid>
<deviceid>1026</deviceid>
<deviceid>1027</deviceid>
<deviceid>1028</deviceid>
<deviceid>1010</deviceid>
<deviceid>1012</deviceid>
<deviceid>101D</deviceid>
<deviceid>1079</deviceid>
<deviceid>107A</deviceid>
<deviceid>107B</deviceid>
<deviceid>108A</deviceid>
<deviceid>1099</deviceid>
<deviceid>10B5</deviceid>
<deviceid>1013</deviceid>
<deviceid>1018</deviceid>
<deviceid>1014</deviceid>
<deviceid>1078</deviceid>
<deviceid>1076</deviceid>
<deviceid>107C</deviceid>
<deviceid>1077</deviceid>
<deviceid>1077</deviceid>
<deviceid>1019</deviceid>
<deviceid>101A</deviceid>
<deviceid>1075</deviceid>
<deviceid>105E</deviceid>
<deviceid>105F</deviceid>
<deviceid>1060</deviceid>
<deviceid>10D9</deviceid>
<deviceid>10DA</deviceid>
<deviceid>10A4</deviceid>
<deviceid>10D5</deviceid>
<deviceid>10A5</deviceid>
<deviceid>10BC</deviceid>
<deviceid>107D</deviceid>
<deviceid>107E</deviceid>
<deviceid>107F</deviceid>
<deviceid>10B9</deviceid>
<deviceid>108B</deviceid>
<deviceid>108C</deviceid>
<deviceid>109A</deviceid>
<deviceid>10D3</deviceid>
<deviceid>10F6</deviceid>
<deviceid>150C</deviceid>
<deviceid>1096</deviceid>
<deviceid>1098</deviceid>
<deviceid>10BA</deviceid>
<deviceid>10BB</deviceid>
<deviceid>1501</deviceid>
<deviceid>1049</deviceid>
<deviceid>104A</deviceid>
<deviceid>104B</deviceid>
<deviceid>104C</deviceid>
<deviceid>10C4</deviceid>
<deviceid>10C5</deviceid>
<deviceid>104D</deviceid>
<deviceid>10BF</deviceid>
<deviceid>10F5</deviceid>
<deviceid>10CB</deviceid>
<deviceid>10BD</deviceid>
<deviceid>10E5</deviceid>
<deviceid>294C</deviceid>
<deviceid>10C0</deviceid>
<deviceid>10C3</deviceid>
<deviceid>10C2</deviceid>
<deviceid>10CC</deviceid>
<deviceid>10CD</deviceid>
<deviceid>10CE</deviceid>
<deviceid>10DE</deviceid>
<deviceid>10DF</deviceid>
<deviceid>1525</deviceid>
<deviceid>10EA</deviceid>
<deviceid>10EB</deviceid>
<deviceid>10EF</deviceid>
<deviceid>10F0</deviceid>
<deviceid>1502</deviceid>
<deviceid>1503</deviceid>
<deviceid>153A</deviceid>
<deviceid>153B</deviceid>
<deviceid>155A</deviceid>
<deviceid>1559</deviceid>
<deviceid>15A0</deviceid>
<deviceid>15A1</deviceid>
<deviceid>15A2</deviceid>
<deviceid>15A3</deviceid>
<deviceid>156F</deviceid>
<deviceid>1570</deviceid>
<deviceid>15B7</deviceid>
<deviceid>15B8</deviceid>
<deviceid>10C9</deviceid>
<deviceid>10E6</deviceid>
<deviceid>10E6</deviceid>
<deviceid>10E7</deviceid>
<deviceid>10E8</deviceid>
<deviceid>1526</deviceid>
<deviceid>150A</deviceid>
<deviceid>1518</deviceid>
<deviceid>150D</deviceid>
<deviceid>10A7</deviceid>
<deviceid>10A9</deviceid>
<deviceid>10D6</deviceid>
<deviceid>150E</deviceid>
<deviceid>150F</deviceid>
<deviceid>1510</deviceid>
<deviceid>1511</deviceid>
<deviceid>1516</deviceid>
<deviceid>1527</deviceid>
<deviceid>1521</deviceid>
<deviceid>1522</deviceid>
<deviceid>1523</deviceid>
<deviceid>1524</deviceid>
<deviceid>1546</deviceid>
<deviceid>1533</deviceid>
<deviceid>1534</deviceid>
<deviceid>1535</deviceid>
<deviceid>1536</deviceid>
<deviceid>1537</deviceid>
<deviceid>1538</deviceid>
<deviceid>157B</deviceid>
<deviceid>157C</deviceid>
<deviceid>1539</deviceid>
<deviceid>1F40</deviceid>
<deviceid>1F41</deviceid>
<deviceid>1F45</deviceid>
<deviceid>0438</deviceid>
<deviceid>043A</deviceid>
<deviceid>043C</deviceid>
<deviceid>0440</deviceid>
<deviceid>10C6</deviceid>
<deviceid>10C7</deviceid>
<deviceid>10C8</deviceid>
<deviceid>150B</deviceid>
<deviceid>10DB</deviceid>
<deviceid>10DD</deviceid>
<deviceid>10EC</deviceid>
<deviceid>10F1</deviceid>
<deviceid>10E1</deviceid>
<deviceid>10F4</deviceid>
<deviceid>10F7</deviceid>
<deviceid>1514</deviceid>
<deviceid>1517</deviceid>
<deviceid>10F8</deviceid>
<deviceid>000C</deviceid>
<deviceid>1F63</deviceid>
<deviceid>10F9</deviceid>
<deviceid>10FB</deviceid>
<deviceid>11A9</deviceid>
<deviceid>1071</deviceid>
<deviceid>1F72</deviceid>
<deviceid>17D0</deviceid>
<deviceid>0470</deviceid>
<deviceid>211B</deviceid>
<deviceid>8976</deviceid>
<deviceid>2159</deviceid>
<deviceid>000D</deviceid>
<deviceid>0008</deviceid>
<deviceid>152A</deviceid>
<deviceid>1529</deviceid>
<deviceid>1507</deviceid>
<deviceid>154D</deviceid>
<deviceid>154A</deviceid>
 <deviceid>154A</deviceid>
<deviceid>1558</deviceid>
<deviceid>1557</deviceid>
<deviceid>0001</deviceid>
<deviceid>10FC</deviceid>
<deviceid>151C</deviceid>
<deviceid>1528</deviceid>
<deviceid>1560</deviceid>
<deviceid>1563</deviceid>
<deviceid>ABCD</deviceid>
<deviceid>15AA</deviceid>
<deviceid>15AB</deviceid>
<deviceid>15AC</deviceid>
<deviceid>15AD</deviceid>
<deviceid>15AE</deviceid>
</NIC>

<NIC>
<manufacturer>10EC</manufacturer>
<deviceid>8136</deviceid>
<deviceid>8137</deviceid>
<deviceid>8168</deviceid>
<deviceid>8167</deviceid>
<deviceid>8169</deviceid>
<deviceid>8166</deviceid>
</NIC>

<NIC>
<manufacturer>14E4</manufacturer>
<deviceid>1644</deviceid>
<deviceid>1645</deviceid>
<deviceid>1646</deviceid>
<deviceid>16A6</deviceid>
<deviceid>16C6</deviceid>
<deviceid>1647</deviceid>
<deviceid>16A7</deviceid>
<deviceid>16C7</deviceid>
<deviceid>164D</deviceid>
<deviceid>1648</deviceid>
<deviceid>16A8</deviceid>
<deviceid>1653</deviceid>
<deviceid>166E</deviceid>
<deviceid>1654</deviceid>
<deviceid>165D</deviceid>
<deviceid>165E</deviceid>
<deviceid>166D</deviceid>
<deviceid>170D</deviceid>
<deviceid>170E</deviceid>
<deviceid>1696</deviceid>
<deviceid>1676</deviceid>
<deviceid>1677</deviceid>
<deviceid>1659</deviceid>
<deviceid>167C</deviceid>
<deviceid>167D</deviceid>
<deviceid>169D</deviceid>
<deviceid>16F7</deviceid>
<deviceid>16FD</deviceid>
<deviceid>16FE</deviceid>
<deviceid>16DD</deviceid>
<deviceid>1668</deviceid>
<deviceid>1669</deviceid>
<deviceid>1678</deviceid>
<deviceid>1679</deviceid>
<deviceid>1600</deviceid>
<deviceid>1601</deviceid>
<deviceid>166A</deviceid>
<deviceid>166B</deviceid>
<deviceid>16FF</deviceid>
<deviceid>170F</deviceid>
<deviceid>169B</deviceid>
 <deviceid>169B</deviceid>
<deviceid>1693</deviceid>
<deviceid>167F</deviceid>
<deviceid>169A</deviceid>
<deviceid>1698</deviceid>
<deviceid>1692</deviceid>
<deviceid>1694</deviceid>
<deviceid>1690</deviceid>
<deviceid>1691</deviceid>
<deviceid>1699</deviceid>
<deviceid>16A0</deviceid>
<deviceid>167B</deviceid>
<deviceid>1673</deviceid>
<deviceid>165A</deviceid>
<deviceid>1674</deviceid>
<deviceid>1681</deviceid>
<deviceid>1680</deviceid>
<deviceid>1688</deviceid>
<deviceid>167A</deviceid>
<deviceid>1672</deviceid>
<deviceid>1684</deviceid>
<deviceid>165B</deviceid>
<deviceid>16B1</deviceid>
<deviceid>16B5</deviceid>
<deviceid>16B0</deviceid>
<deviceid>16B4</deviceid>
<deviceid>16B2</deviceid>
<deviceid>16B6</deviceid>
<deviceid>1682</deviceid>
<deviceid>1686</deviceid>
<deviceid>16B3</deviceid>
<deviceid>16B7</deviceid>
<deviceid>1655</deviceid>
<deviceid>1665</deviceid>
<deviceid>1656</deviceid>
<deviceid>1657</deviceid>
<deviceid>165F</deviceid>
<deviceid>165C</deviceid>
<deviceid>1683</deviceid>
<deviceid>1641</deviceid>
<deviceid>1642</deviceid>
<deviceid>1643</deviceid>
<deviceid>1687</deviceid>
<deviceid>164A</deviceid>
<deviceid>16AA</deviceid>
<deviceid>164C</deviceid>
<deviceid>16AC</deviceid>
<deviceid>1639</deviceid>
<deviceid>163A</deviceid>
<deviceid>163B</deviceid>
<deviceid>163C</deviceid>
<deviceid>164E</deviceid>
<deviceid>164F</deviceid>
<deviceid>1650</deviceid>
<deviceid>1662</deviceid>
<deviceid>1663</deviceid>
<deviceid>168A</deviceid>
<deviceid>168D</deviceid>
<deviceid>16A1</deviceid>
<deviceid>16A2</deviceid>
<deviceid>168E</deviceid>
<deviceid>163D</deviceid>
<deviceid>16A5</deviceid>
<deviceid>16A4</deviceid>
<deviceid>16AE</deviceid>
<deviceid>163E</deviceid>
</NIC>

<NIC>
<manufacturer>1969</manufacturer>
 <manufacturer>1969</manufacturer>
<deviceid>1062</deviceid>
<deviceid>1063</deviceid>
<deviceid>2060</deviceid>
<deviceid>2062</deviceid>
<deviceid>1073</deviceid>
<deviceid>1083</deviceid>
<deviceid>1090</deviceid>
<deviceid>1091</deviceid>
<deviceid>E091</deviceid>
<deviceid>10A0</deviceid>
<deviceid>10A1</deviceid>
<deviceid>E0A1</deviceid>
<deviceid>10B0</deviceid>
<deviceid>10B1</deviceid>
<deviceid>E0B1</deviceid>
<deviceid>10C0</deviceid>
<deviceid>10C1</deviceid>
<deviceid>E0C1</deviceid>
<deviceid>10D0</deviceid>
<deviceid>10D1</deviceid>
<deviceid>E0D1</deviceid>
<deviceid>10E0</deviceid>
<deviceid>10E1</deviceid>
<deviceid>E0E1</deviceid>
<deviceid>10F0</deviceid>
<deviceid>10F1</deviceid>
<deviceid>E0F1</deviceid>
</NIC>

<NIC>
<manufacturer>19A2</manufacturer>
<deviceid>0211</deviceid>
<deviceid>0215</deviceid>
<deviceid>0221</deviceid>
<deviceid>0700</deviceid>
<deviceid>0710</deviceid>
</NIC>

<NIC>
<manufacturer>10DF</manufacturer>
<deviceid>0720</deviceid>
<deviceid>E220</deviceid>
</NIC>

<NIC>
<manufacturer>15B3</manufacturer>
<deviceid>1000</deviceid>
<deviceid>1001</deviceid>
<deviceid>1002</deviceid>
<deviceid>1003</deviceid>
<deviceid>1004</deviceid>
<deviceid>1005</deviceid>
<deviceid>1006</deviceid>
<deviceid>1007</deviceid>
<deviceid>1008</deviceid>
<deviceid>1009</deviceid>
<deviceid>100A</deviceid>
<deviceid>100B</deviceid>
<deviceid>100C</deviceid>
<deviceid>100D</deviceid>
<deviceid>100E</deviceid>
<deviceid>100F</deviceid>
<deviceid>1010</deviceid>
<deviceid>6340</deviceid>
<deviceid>6341</deviceid>
<deviceid>634A</deviceid>
<deviceid>634B</deviceid>
<deviceid>6354</deviceid>
 <deviceid>6368</deviceid>
<deviceid>6369</deviceid>
<deviceid>6372</deviceid>
<deviceid>6732</deviceid>
<deviceid>6733</deviceid>
<deviceid>673C</deviceid>
<deviceid>673D</deviceid>
<deviceid>6746</deviceid>
<deviceid>6750</deviceid>
<deviceid>6751</deviceid>
<deviceid>675A</deviceid>
<deviceid>6764</deviceid>
<deviceid>6765</deviceid>
<deviceid>676E</deviceid>
<deviceid>6778</deviceid>
<deviceid>1013</deviceid>
<deviceid>1015</deviceid>
<deviceid>1017</deviceid>
<deviceid>1019</deviceid>
<deviceid>101B</deviceid>
<deviceid>101D</deviceid>
<deviceid>101F</deviceid>
<deviceid>1021</deviceid>
<deviceid>1023</deviceid>
<deviceid>1025</deviceid>
<deviceid>1027</deviceid>
<deviceid>1029</deviceid>
<deviceid>102B</deviceid>
<deviceid>102F</deviceid>
</NIC>

<NIC>
<manufacturer>1137</manufacturer>
<deviceid>0043</deviceid>
</NIC>

</SupportedNetworkInterfaceCards>

Related topics
Setting Up Kernel-Mode Debugging over a Network Cable in Visual Studio
Setting Up KDNET Network Kernel Debugging Automatically
Setting Up KDNET Network Kernel Debugging Manually
Supported Ethernet NICs for Network Kernel Debugging in Windows 8
Supported Ethernet NICs for Network Kernel Debugging in Windows 8.1
 Supported Ethernet NICs for Network Kernel
Debugging in Windows 8.1
3/5/2021 • 3 minutes to read • Edit Online

You can do kernel debugging over an Ethernet network cable when the target computer is running Windows 8.1.
The target computer must have a supported network interface card (NIC) or network adapter.
During kernel debugging, the computer that runs the debugger is called the host computer, and the computer
being debugged is called the target computer. For more information, see Setting Up KDNET Network Kernel
Debugging Automatically.
To do kernel debugging over a network cable, the target computer must have a supported network adapter.
When the target computer is running Windows 8.1, the network adapters listed here are supported for kernel
debugging.
Note Support for kernel debugging over selected 10 gigabit network adapters is a new feature in Windows 8.1.
Debugging over 10 gigabit network adapters is not supported in Windows 8. For a list of network adapters
supported by Windows 8 for kernel debugging, see Supported Ethernet NICs for Network Kernel Debugging in
Windows 8.

System Requirements
Kernel debugging through Ethernet NICs requires certain low-level platform support. Windows requires that
these NICs be attached via PCI/PCIe for this debugging solution. In most cases, simply plugging in one of these
supported NICs will allow a robust kernel debugging experience. However, there may be cases where BIOS
configuration details hinder the Windows debug path. The following platform requirement should be
considered:
System firmware should discover and configure the NIC device such that its resources do not conflict with
any other devices that have been BIOS-configured.

Finding the vendor ID and device ID

First find the vendor ID and device ID of the network adapter on your target computer.
On the target computer, open Device Manager (enter devmgmt in a Command Prompt window).
In Device Manager, locate the network adapter that you want to use for debugging.
Select and hold (or right-click) the network adapter node, and choose Proper ties .
In the Details tab, under Proper ty , select Hardware Ids .
The vendor and device IDs are shown as VEN_VendorID and DEV_DeviceID. For example, if you see
PCI\VEN_8086&DEV_104B, the vendor ID is 8086, and the device ID is 104B.

Vendor ID 8086, Intel Corporation

For vendor ID 8086, these device IDs are supported:
0438 043A 043C 0440 1000 1001 1004 1008 1009 100C 100D 100E 100F 1010 1011 1012 1013 1014 1015
1016 1017 1018 1019 101A 101D 101E 1026 1027 1028 1049 104A 104B 104C 104D 105E 105F 1060 1075
1076 1077 1078 1079 107A 107B 107C 107D 107E 107F 108A 108B 108C 1096 1098 1099 109A 10A4 10A5
10A7 10A9 10B5 10B9 10BA 10BB 10BC 10BD 10BF 10C0 10C2 10C3 10C4 10C5 10C6 10C7 10C8 10C9 10CB
10CC 10CD 10CE 10D3 10D5 10D6 10D9 10DA 10DB 10DD 10DE 10DF 10E1 10E5 10E6 10E7 10E8 10EA 10EB
10EC 10EF 10F0 10F1 10F4 10F5 10F6 10F7 10F8 10F9 10FA 10FB 10FC 1501 1502 1503 1507 150A 150B
150C 150D 150E 150F 1510 1511 1514 1516 1517 1518 151C 1521 1522 1523 1524 1525 1526 1527 1528
1529 152A 1533 1534 1535 1536 1537 1538 1539 153A 153B 1546 154A 154D 1557 1558 1559 155A 1560
157B 157C 1F40 1F41 1F45 294C

Vendor ID 10EC, Realtek Semiconductor Corp.

For vendor ID 10EC, these device IDs are supported:
8136 8137 8167 8168 8169

Vendor ID 14E4, Broadcom

For vendor ID 14E4, these device IDs are supported:
1600 1601 1639 163A 163B 163C 1644 1645 1646 1647 1648 164A 164C 164D 1653 1654 1655 1656 1657
1658 1659 165A 165B 165C 165D 165E 165F 1668 1669 166A 166B 166D 166E 1672 1673 1674 1676 1677
1678 1679 167A 167B 167C 167D 167F 1680 1681 1684 1688 1690 1691 1692 1693 1694 1696 1698 1699
169A 169B 169D 16A0 16A6 16A7 16A8 16AA 16AC 16B0 16B1 16B2 16B4 16B5 16B6 16C6 16C7 16DD 16F7
16FD 16FE 16FF 170D 170E 170F

Vendor ID 1969, Atheros Communications

For vendor ID 1969, these device IDs are supported:
1062 1063 1073 1083 1090 1091 10A0 10A1 10B0 10B1 10C0 10C1 10D0 10D1 10E0 10E1 10F0 10F1 2060
2062 E091 E0A1 E0B1 E0C1 E0D1 E0E1 E0F1

Vendor ID 19A2, ServerEngines (Emulex)

For vendor ID 19A2, these device IDs are supported:
0211 0215 0221 0700 0710

Vendor ID 10DF, Emulex Corporation

For vendor ID 10DF, these device IDs are supported:
0720 E220

Vendor ID 15B3, Mellanox Technology

For vendor ID 15B3, these device IDs are supported:
1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 100A 100B 100C 100D 100E 100F 1010 6340 6341
634A 634B 6354 6368 6369 6372 6732 6733 673C 673D 6746 6750 6751 675A 6764 6765 676E 6778

Related topics
Setting Up KDNET Network Kernel Debugging Automatically
Supported Ethernet NICs for Network Kernel Debugging in Windows 8
 Supported Ethernet NICs for Network Kernel
Debugging in Windows 8
3/5/2021 • 3 minutes to read • Edit Online

You can do kernel debugging over an Ethernet network cable when the target computer is running Windows 8.
The target computer must have a supported network interface card (NIC) or network adapter.
During kernel debugging, the computer that runs the debugger is called the host computer, and the computer
being debugged is called the target computer. For more information, see Setting Up KDNET Network Kernel
Debugging Automatically.
To do kernel debugging over a network cable, the target computer must have a supported network adapter.
When the target computer is running Windows 8, the network adapters listed here are supported for kernel
debugging.
Note For a list of network adapters supported by Windows 8.1 for kernel debugging, see Supported Ethernet
NICs for Network Kernel Debugging in Windows 8.1.

System Requirements
Kernel debugging through Ethernet NICs requires certain low-level platform support. Windows requires that
these NICs be attached via PCI/PCIe for this debugging solution. In most cases, simply plugging in one of these
supported NICs will allow a robust kernel debugging experience. However, there may be cases where BIOS
configuration details hinder the Windows debug path. The following set of platform requirements should be
considered:
System firmware should discover and configure the NIC device such that its resources do not conflict with
any other devices that have been BIOS-configured.
System firmware should place the NIC’s resources under address windows that are not marked prefetchable.

Finding the vendor ID and device ID

First find the vendor ID and device ID of the network adapter on your target computer.
On the target computer, open Device Manager (enter devmgmt in a Command Prompt window).
In Device Manager, locate the network adapter that you want to use for debugging.
Right click the network adapter node, and choose Proper ties .
In the Details tab, under Proper ty , select Hardware Ids .
The vendor and device IDs are shown as VEN_VendorID and DEV_DeviceID. For example, if you see
PCI\VEN_8086&DEV_104B, the vendor ID is 8086, and the device ID is 104B.

Vendor ID 8086, Intel Corporation

For vendor ID 8086, these device IDs are supported:
1000 1001 1004 1008 1009 100C 100D 100E 100F 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019
101A 101D 101E 1026 1027 1028 1049 104A 104B 104C 104D 105E 105F 1060 1075 1076 1077 1078 1079
107A 107B 107C 107D 107E 107F 108A 108B 108C 1096 1098 1099 109A 10A4 10A5 10A7 10A9 10B5 10B9
10BA 10BB 10BC 10BD 10BF 10C9 10CB 10CC 10CD 10CE 10D3 10D5 10D6 10D9 10DA 10E5 10E6 10E7 10E8
10EA 10EB 10EF 10F0 10F5 10F6 1501 1502 1503 150A 150C 150D 150E 150F 1510 1511 1516 1518 1521
1522 1523 1524 1526 294C

Vendor ID 10EC, Realtek Semiconductor Corp.

For vendor ID 10EC, these device IDs are supported:
8136 8137 8167 8168 8169

Vendor ID 14E4, Broadcom

For vendor ID 14E4, these device IDs are supported:
1600 1601 1639 163A 163B 163C 1644 1645 1646 1647 1648 164A 164C 164D 1653 1654 1655 1656 1657
1658 1659 165A 165B 165C 165D 165E 165F 1668 1669 166A 166B 166D 166E 1672 1673 1674 1676 1677
1678 1679 167A 167B 167C 167D 167F 1680 1681 1684 1688 1690 1691 1692 1693 1694 1696 1698 1699
169A 169B 169D 16A0 16A6 16A7 16A8 16AA 16AC 16B0 16B1 16B2 16B4 16B5 16B6 16C6 16C7 16DD 16F7
16FD 16FE 16FF 170D 170E 170F

Vendor ID 1969, Atheros Communications

Support for Atheros network adapters is provided by a separate module that is available from Qualcomm. These
device IDs are supported.
1062 1063 1073 1083 1090 1091 10A0 10A1 10B0 10B1 10C0 10C1 10D0 10D1 10E0 10E1 10F0 10F1 2060
2062 E091 E0A1 E0B1 E0C1 E0D1 E0E1 E0F1

Related topics
Setting Up KDNET Network Kernel Debugging Automatically
Supported Ethernet NICs for Network Kernel Debugging in Windows 8.1
Supported Ethernet NICs for Network Kernel Debugging in Windows 10
 Configuring tools.ini
3/5/2021 • 3 minutes to read • Edit Online

The file tools.ini contains information to initialize the command-line debuggers. On startup, the debugger
searches for the appropriate section header in the tools.ini file and extracts initialization information from the
entries under the header. Each command-line debugger has its own section header - [CDB], [NTSD], and [KD].
The environment variable INIT must point to the directory containing the tools.ini file.
WinDbg does not use the tools.ini file. Instead, WinDbg saves initialization settings in workspaces.
The tools.ini entries are shown in the following table.
Keywords must be separated from the values by white space or a colon. Keywords are not case-sensitive.
For TRUE or FALSE values, "FALSE" is the only false value. Anything else is TRUE .

EN T RY DESC RIP T IO N

$u0: value ... $u9: value Assign values to fixed-name aliases. You can specify
numeric values n or 0xn or any other string. See Using
Aliases for details. No command-line equivalent.

DebugChildren: flag TRUE or FALSE . If TRUE , CDB debugs the specified

application as well as any child processes that it might
spawn. Command-line equivalent is -o .

DebugOutput: flag TRUE or FALSE . If TRUE , CDB sends output and

receives input through a terminal. If FALSE , output goes
to the user screen. The command-line option -d is
similar but not identical.

IniFile: file Specifies the name of the script file that CDB or KD takes
commands from at startup. The default is the ntsd.ini file
in the current directory. Command-line equivalent is -cf .
For details, see Using Script Files.

LazyLoad: flag TRUE or FALSE . If TRUE , CDB performs lazy symbol

loading; that is, symbols are not loaded until required.
Command-line equivalent is -s .
For details, and other methods of setting this option, see
Deferred Symbol Loading.

SetDll: filename Set extension DLL. The .dll filename extension should be
omitted. Default is userexts.dll. Command-line
equivalent is -a .
For details, and other methods of setting this default,
see Loading Debugger Extension DLLs.
EN T RY DESC RIP T IO N

StopFirst: flag TRUE or FALSE . If true , CDB stops on the breakpoint at

the end of the image-loading process. Command-line
equivalent is -g .

StopOnProcessExit: flag TRUE or FALSE . If TRUE , CDB stops when it receives a

process termination notification. Command-line
equivalent is -G .

sxd: event sxe: event Sets the debugger response and the handling status for
the specified exception or event.
Exceptions and events may be specified in the following
ways:
* : Default exception n: Exception n (decimal) 0xn:
Exception 0xn (hexadecimal) (other): Event code
See Controlling Exceptions and Events for details of this
process and for other methods of controlling these
settings.

VerboseOutput: flag TRUE or FALSE . If TRUE , CDB will display detailed

information about symbol handling, event notification,
and other run-time occurrences. Command-line
equivalent is -v .

lines: flag TRUE or FALSE . The lines flag enables or disables

support for source-line information.

srcopt: options Sets the source line options that control source display
and program stepping options. For more information
see l+, l- (Set Source Options) .

srcpath: directory Sets the source file search path. For more information
see .srcpath, .lsrcpath (Set Source Path) .

enable_unicode: flag TRUE or FALSE . The enable_unicode flag specifies

whether the debugger displays USHORT pointers and
arrays as Unicode strings.

force_radix_output: flag TRUE or FALSE . The force_radix_output flag specifies

whether integers are displayed in decimal format or in
the default radix.

col_mode: flag TRUE or FALSE . The col_mode flag controls the color
mode setting. When color mode is enabled the
debugger can produce colored output. By default, most
colors are not set and instead default to the current
console colors.
 EN T RY DESC RIP T IO N

col: name colspec The name indicates the element that you are coloring.
The colspec is a three-letter RGB indicator of the form
[rR-][gG-][bB-]. A lower-case letter indicates darker, an
upper-case letter indicates brighter and a dash indicates
no color component contribution. Due to console color
limitations, bright is not actually per-component, but
applies to all components if any request bright. In other
words, rgB is the same as RGB. For this reason, it is
recommended that all caps be used if any caps are going
to be used.
Example usage:
col: emphfg R--

A sample [NTSD] section in the tools.ini file follows:

[NTSD]
sxe: 3c
sxe: cc
$u0: VeryLongName
VerboseOutput:true
 Using KDbgCtrl
3/5/2021 • 5 minutes to read • Edit Online

The KDbgCtrl (Kernel Debugging Control, kdbgctrl.exe) tool can be used to control the kernel debugging
connection from the target computer.
To use this tool, your target computer must be running Windows Server 2003 or a later version of Windows.
KDbgCtrl can control five different settings: Full Kernel Debugging, Automatic Kernel Debugging, User-Mode
Error Handling, Blocking of Kernel Debugging, and the size of the DbgPrint buffer.
To use KDbgCtrl, you must have already enabled kernel debugging in the boot settings of the target computer
before the last boot. KDbgCtrl cannot be used to enable kernel debugging if this was not done. See Boot
Parameters to Enable Debugging for details on these boot settings.
Full Kernel Debugging
When Full Kernel Debugging is enabled, a kernel debugger running on the host computer can break into the
target computer. The target computer will break into the kernel debugger if a kernel-mode exception is hit.
Messages from the target to the host, such as DbgPrint output, symbol load messages, and redirected user-
mode debuggers, are also allowed.
If this setting is disabled, all signals from the host computer will be ignored by the target.
Full Kernel Debugging is enabled by default. To check the current setting value, use kdbgctrl -c . To disable this
setting, use kdbgctrl -d . To enable this setting, use kdbgctrl -e .
If you wish to check the current setting and use it to control execution within a batch file, you can use the
kdbgctrl -cx command. For details on this command, see KDbgCtrl Command-Line Options .
Automatic Kernel Debugging
If Full Kernel Debugging is enabled, the current setting for Automatic Kernel Debugging is immaterial -- all
communication is permitted.
When Full Kernel Debugging is disabled and Automatic Kernel Debugging is enabled, only the target computer
can initiate a debugging connection.
In this case, only a kernel-mode exception, breakpoint, or other kernel-mode event will cause a connection to be
established. The connection will not be established for DbgPrint output, symbol load messages, redirected
user-mode debugger input and output, or other similar messages -- these will be stored in the DbgPrint buffer
instead of being sent to the kernel debugger.
If an exception or event causes the target to break into the kernel debugger, then Full Kernel Debugging will be
automatically turned on, just as if you had executed kdbgctrl -e .
Automatic Kernel Debugging is disabled by default (although this is immaterial unless Full Kernel Debugging is
disabled as well). To check the current setting value, use kdbgctrl -ca . To disable this setting, use kdbgctrl -da .
To enable this setting, use kdbgctrl -ea .
User-Mode Error Handling
When User-Mode Error Handling is enabled, some user-mode events will cause the target computer to break
into the kernel debugger.
Specifically, all int 3 interrupts -- such as breakpoints inserted into the code by a debugger or calls to
DbgBreakPoint -- will cause a break into the kernel debugger. However, standard exceptions -- such as access
violations and division by zero -- will usually not be sent to the kernel debugger.
If a user-mode debugger is already attached to the process, this debugger will capture all user-mode errors, and
the kernel debugger will not be alterted. For the precedence ranking of the various user-mode error handlers,
see Enabling Postmortem Debugging.
For User-Mode Error Handling to function, either Full Kernel Debugging or Automatic Kernel Debugging must
be enabled as well.
User-Mode Error Handling is enabled by default. To check the current setting value, use kdbgctrl -cu . To disable
this setting, use kdbgctrl -du . To enable this setting, use kdbgctrl -eu .
Blocking Kernel Debugging
In some cases you might want to set up the target computer for kernel debugging, but wait to enable kernel
debugging until after the target computer is started. You can do that by blocking kernel debugging.

IMPORTANT
Before using BCDEdit to change boot information you may need to temporarily suspend Windows security features such
as BitLocker and Secure Boot on the test PC. Re-enable these security features when testing is complete and appropriately
manage the test PC, when the security features are disabled.

To block kernel debugging, set up the target computer by using commands similar to the following:

bcdedit /debug on
bcdedit /dbgsettings 1394 channel:32 /start DISABLE /noumex

When you restart the target computer, it will be prepared for kernel debugging, but kernel debugging and User-
Mode Error Handling will be disabled. At that point, a host computer will not be able to attach to the target
computer, bug checks will not be caught by the kernel debugger, and user-mode exceptions will not cause a
break in to the kernel debugger.
When you are ready, you can enable kernel debugging (without restarting the target computer) by entering the
following commands.

kdbgctrl -db
kdbgctrl -e

Later, you can disable kernel debugging by entering the following commands.

kdbgctrl -d
kdbgctrl -eb

You can use kdbgctrl -cb to check whether kernel debugging is blocked.
The DbgPrint Buffer Size
The DbgPrint buffer stores messages that the target computer has sent to the kernel debugger.
If Full Kernel Debugging is enabled, these messages will automatically appear in the kernel debugger. But if this
option is disabled, these messages will be stored in the buffer. At a later point in time, you can enable kernel
debugging, connect to a kernel debugger, and use the !dbgprint extension to see the contents of this buffer. For
more information about this buffer, see The DbgPrint Buffer.
The default size of the DbgPrint buffer is 4 KB on a free build of Windows. To determine the current buffer size,
use kdbgctrl -cdb . To change the buffer size, use kdbgctrl -sdb Size, where Size specifies the new buffer size.
For syntax details, see KDbgCtrl Command-Line Options .
Examples
To display all the current settings, use the following command:

kdbgctrl -c -ca -cu -cb -cdb

To restore the default settings, use the following command:

kdbgctrl -e -da -eu -db -sdb 0x1000

To lock out the host computer so that it only is contacted on exceptions, use the following command:

kdbgctrl -d -ea -eu

To disable all kernel debugging, use the following command:

kdbgctrl -d -da

If you are disabling all kernel debugging, you may also wish to increase the size of the DbgPrint buffer. This
insures that all messages will be saved in case you need to see them later. If you have a megabyte of memory to
spare, you might use the following command:

kdbgctrl -sdb 0x100000

 Debug Windows Drivers - Step by Step Lab (Echo
Kernel-Mode)
6/16/2021 • 40 minutes to read • Edit Online

This lab introduces the WinDbg kernel debugger. WinDbg is used to debug the echo kernel mode sample driver
code.

Lab objectives
This lab includes exercises that introduce the debugging tools, teach common debugging commands, illustrate
the use of break points, and show the use of the debugging extensions.
In this lab, a live kernel debug connection is used to explore the following:
Use the Windows debugger commands
Use standard commands (Call stacks, variables, threads, IRQL)
Use advanced driver debugging commands (!commands)
Use symbols
Set breakpoints in live debugging
View call stacks
Display the Plug and Play device tree
Work with thread and process context
Note When working with the Windows debugger, there are two types of debugging that can be performed -
user or kernel mode debugging.
User mode - Applications and subsystems run on the computer in user mode. Processes that run in user mode
do so within their own virtual address spaces. They are restricted from gaining direct access to many parts of
the system, including system hardware, memory that was not allocated for their use, and other portions of the
system that might compromise system integrity. Because processes that run in user mode are effectively
isolated from the system and other user mode processes, they cannot interfere with these resources.
Kernel mode - Kernel mode is the processor access mode in which the operating system and privileged
programs run. Kernel mode code has permission to access any part of the system, and is not restricted like user
mode code. It can gain access to any part of any other process running in either user mode or kernel mode.
Much of the core OS functionality and many hardware device drivers run in kernel mode.
This lab will focus on kernel mode debugging, as that is the method used to debug many device drivers.
This exercise covers debug commands that are frequently used during both user-mode and kernel-mode
debugging. The exercise also covers debug extensions (sometimes called "!commands") that are used for kernel-
mode debugging.

Lab setup
You will need the following hardware to be able to complete the lab.
A laptop or desktop computer (host) running Windows 10
A laptop or desktop computer (target) running Windows 10
A network hub/router and network cables to connect the two PCs
 Access to the internet to download symbol files
You will need the following software to be able to complete the lab.
Visual Studio
Windows Software Development Kit (SDK) for Windows 10
Windows Driver Kit (WDK) for Windows 10
The sample echo driver for Windows 10
The lab has the following eleven sections.
Section 1: Connect to a kernel mode WinDbg session
Section 2: Kernel mode debugging commands and techniques
Section 3: Download and build the KMDF Echo Driver
Section 4: Install the KMDF Echo driver sample on the target system
Section 5: Use WinDbg to display information about the driver
Section 6: Display Plug and Play device tree information
Section 7: Work with breakpoints and source code
Section 8: View variables and call stacks
Section 9: Display processes and threads
Section 10: IRQL, Registers and Ending the WinDbg session
Section 11: Windows debugging resources

Section 1: Connect to a kernel mode WinDbg session

In Section 1, you will configure network debugging on the host and target system.
The PCs in this lab need to be configured to use an Ethernet network connection for kernel debugging.
This lab uses two PCs. Windows debugger runs on the host system and the KMDF Echo driver runs on the target
system.
Use a network hub/router and network cables to connect the two PCs.

To work with kernel mode applications and use WinDbg, we recommend that you use the KDNET over Ethernet
transport. For information about how to use the Ethernet transport protocol, see Getting Started with WinDbg
(Kernel-Mode). For more information about setting up the target computer, see Preparing a Computer for
Manual Driver Deployment and Setting Up KDNET Network Kernel Debugging Automatically.
Configure kernel–mode debugging using ethernet
To enable kernel mode debugging on the target system, perform the following steps.
<- On the host system
1. Open a command prompt on the host system and type ipconfig to determine its IP address.
 C:\>ipconfig
Windows IP Configuration
Ethernet adapter Ethernet:
Connection-specific DNS Suffix . :
Link-local IPv6 Address . . . . . : fe80::c8b6:db13:d1e8:b13b%3
Autoconfiguration IPv4 Address. . : 169.182.1.1
Subnet Mask . . . . . . . . . . . : 255.255.0.0
Default Gateway . . . . . . . . . :

2. Record the IP address of the host system: ______________________________________

-> On the target system
3. Open a command prompt on the target system and use the ping command to confirm network connectivity
between the two systems. Use the actual IP address of the host system you recorded instead of 169.182.1.1
that is shown in the sample output.

C:\> ping 169.182.1.1

Pinging 169.182.1.1 with 32 bytes of data:

Reply from 169.182.1.1: bytes=32 time=1ms TTL=255
Reply from 169.182.1.1: bytes=32 time<1ms TTL=255
Reply from 169.182.1.1: bytes=32 time<1ms TTL=255
Reply from 169.182.1.1: bytes=32 time<1ms TTL=255

Ping statistics for 169.182.1.1:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 1ms, Average = 0ms

Enable kernel mode debugging on the target system by completing the following steps.

IMPORTANT
Before using BCDEdit to change boot information you may need to temporarily suspend Windows security features such
as BitLocker and Secure Boot on the test PC. Re-enable these security features when testing is complete and appropriately
manage the test PC, when the security features are disabled.

1. On the target computer, open a Command Prompt window as Administrator. Enter this command to
enable debugging.

C:\> bcdedit /set {default} DEBUG YES

2. Type this command to enable test signing.

C:\> bcdedit /set TESTSIGNING ON

3. Type this command to set the IP address of the host system. Use the IP address of the host system that
you recorded earlier, not the one shown.

C:\> bcdedit /dbgsettings net hostip:192.168.1.1 port:50000

key:2steg4fzbj2sz.23418vzkd4ko3.1g34ou07z4pev.1sp3yo9yz874p

Warning To increase the security of the connection and decrease the risk of the random client debugger
connection requests, consider using an auto generated random key. For more information, see Setting Up
KDNET Network Kernel Debugging Automatically.
4. Type this command to confirm that the dbgsettings they are set properly.

C:\> bcdedit /dbgsettings

key 2steg4fzbj2sz.23418vzkd4ko3.1g34ou07z4pev.1sp3yo9yz874p
debugtype NET
hostip 169.168.1.1
port 50000
dhcp Yes
The operation completed successfully.

Note
Firewalls and debuggers
If you receive a pop-up message from the firewall, and you wish to use the debugger, check all three of the
boxes.

<- On the host system

1. On the host computer, open a Command Prompt window as Administrator. We will use the x64 version of
WinDbg.exe from the Windows Driver Kit (WDK) that was installed as part of the Windows kit installation.
By default it is located here.

C:\> Cd C:\Program Files(x86)\Windows Kits\10\Debuggers\x64

NOTE
This labs assumes that both PCs are running a 64 bit version of Windows on both the target and host. If that is not the
case, the best approach is to run the same "bitness" of tools on the host that the target is running. For example if the
target is running 32 bit Windows, run a 32 version of the debugger on the host. For more information, see Choosing the
32-Bit or 64-Bit Debugging Tools.

2. Launch WinDbg with remote user debug using the following command. The value for the key and port
match what we set earlier using BCDEdit on the target.
 WinDbg –k net:port=50000,key=2steg4fzbj2sz.23418vzkd4ko3.1g34ou07z4pev.1sp3yo9yz874p

->On the target system

Reboot the target system.
<-On the host system
In a minute or two, debug output should be displayed on the host system.

Microsoft (R) Windows Debugger Version 10.0.17074.1002 AMD64

Copyright (c) Microsoft Corporation. All rights reserved.

Using NET for debugging

Opened WinSock 2.0
Waiting to reconnect...
Connected to target 169.182.1.1 on port 50005 on local IP 169.182.1.2
You can get the target MAC address by running .kdtargetmac command.
Connected to Windows 10 16299 x64 target at (Wed Feb 28 17:16:23.051 2018 (UTC - 8:00)), ptr64 TRUE
Kernel Debugger connection established. (Initial Breakpoint requested)
Symbol search path is: srv*
Executable search path is:
Windows 10 Kernel Version 16299 MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 16299.15.amd64fre.rs3_release.170928-1534
Machine Name:
Kernel base = 0xfffff800`9540d000 PsLoadedModuleList = 0xfffff800`95774110
Debug session time: Wed Feb 28 17:16:23.816 2018 (UTC - 8:00)
System Uptime: 0 days 0:00:20.534

The Debugger Command window is the primary debugging information window in WinDbg. You can enter
debugger commands and view the command output in this window.
The Debugger Command window is split into two panes. You type commands in the smaller pane (the
command entry pane) at the bottom of the window and view the command output in the larger pane at the top
of the window.
In the command entry pane, use the up arrow and down arrow keys to scroll through the command history.
When a command appears, you can edit it or press ENTER to run the command.

Section 2: Kernel mode debugging commands and techniques

In Section 2, you will use debug commands to display information about the target system.
<- On the host system
Enable Debugger Markup Language (DML) with .prefer_dml
Some debug commands display text using Debugger Markup Language that you can select to quickly gather
more information.
1. Use Ctrl+Break (Scroll Lock) in WinDBg to break into the code running on the target system. It may take a bit
of time for the target system to respond.
2. Type the following command to enable DML in the Debugger Command window.

0: kd> .prefer_dml 1
DML versions of commands on by default

Use .hh to get help

You can access reference command help using the .hh command.
3. Type the following command to view the command reference help for .prefer_dml .

0: kd> .hh .prefer_dml

The Debugger help file will display help for the .prefer_dml command.
Display the version of Windows on the target system
5. Display detailed version information on the target system by typing the ver target (Show Target
Computer Version) command in the WinDbg window.

0: kd> vertarget
Windows 10 Kernel Version 9926 MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 9926.0.amd64fre.fbl_awesome1501.150119-1648
Machine Name: ""
Kernel base = 0xfffff801`8d283000 PsLoadedModuleList = 0xfffff801`8d58aef0
Debug session time: Fri Feb 20 10:15:17.807 2015 (UTC - 8:00)
System Uptime: 0 days 01:31:58.931

List the loaded modules

6. You can verify that you are working with the right kernel mode process by displaying the loaded modules by
typing the lm (List Loaded Modules) command in the WinDbg window.
 0: Kd> lm
start end module name
fffff801`09200000 fffff801`0925f000 volmgrx (no symbols)
fffff801`09261000 fffff801`092de000 mcupdate_GenuineIntel (no symbols)
fffff801`092de000 fffff801`092ec000 werkernel (export symbols) werkernel.sys
fffff801`092ec000 fffff801`0934d000 CLFS (export symbols) CLFS.SYS
fffff801`0934d000 fffff801`0936f000 tm (export symbols) tm.sys
fffff801`0936f000 fffff801`09384000 PSHED (export symbols) PSHED.dll
fffff801`09384000 fffff801`0938e000 BOOTVID (export symbols) BOOTVID.dll
fffff801`0938e000 fffff801`093f7000 spaceport (no symbols)
fffff801`09400000 fffff801`094cf000 Wdf01000 (no symbols)
fffff801`094d9000 fffff801`09561000 CI (export symbols) CI.dll
...

Note Output that has been omitted is indicated with "… " in this lab.
7. To request detailed information about a specific module, use the v (verbose) option as shown.

0: Kd> lm v m tcpip
Browse full module list
start end module name
fffff801`09eeb000 fffff801`0a157000 tcpip (no symbols)
Loaded symbol image file: tcpip.sys
Image path: \SystemRoot\System32\drivers\tcpip.sys
Image name: tcpip.sys
Browse all global symbols functions data
Timestamp: Sun Nov 09 18:59:03 2014 (546029F7)
CheckSum: 00263DB1
ImageSize: 0026C000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4

Unable to enumerate user-mode unloaded modules, Win32 error 0n30

8. Because we have yet to set the symbol path and loaded symbols, limited information is available in the
debugger.

Section 3: Download and build the KMDF echo driver

In Section 3, you will download and build the KMDF echo driver.
Typically, you would be working with your own driver code when you use WinDbg. To become familiar with
WinDbg operation, the KMDF Template "Echo" sample driver is used. With the source code available, it will also
be easier to understand the information that is displayed in WinDbg. In addition, this sample is used to illustrate
how you can single step through native kernel mode code. This technique can be very valuable for debugging
complex kernel mode code issues.
To download and build the Echo sample audio driver, perform the following steps.
1. Download and extract the KMDF Echo sample from GitHub
You can use a browser to view the echo sample in GitHub here:
https://github.com/Microsoft/Windows-driver-samples/tree/master/general/echo/kmdf
You can read about the sample here:
https://github.com/microsoft/Windows-driver-samples/blob/master/general/echo/kmdf/README.md
You can browse all of the Windows driver samples here:
https://github.com/Microsoft/Windows-driver-samples
 The KMDF Echo sample is located in the general folder.

a. This lab, shows how to download the driver samples in one zip file.
https://github.com/Microsoft/Windows-driver-samples/archive/master.zip
b. Download the master.zip file to your local hard drive.
c. Select and hold (or right-click) Windows-driver-samples-master.zip, and choose Extract All . Specify a
new folder, or browse to an existing one that will store the extracted files. For example, you could specify
C:\DriverSamples\ as the new folder into which the files are extracted.
d. After the files are extracted, navigate to the following subfolder.
C:\DriverSamples\general\echo\kmdf
2. Open the driver solution in Visual Studio
In Microsoft Visual Studio, select File > Open > Project/Solution... and navigate to the folder that
contains the extracted files (for example, C:\DriverSamples\general\echo\kmdf). Double-click the
kmdfecho solution file to open it.
In Visual Studio, locate the Solution Explorer. (If this is not already open, choose Solution Explorer from
the View menu.) In Solution Explorer, you can see one solution that has three projects.
3. Set the sample's configuration and platform
In Solution Explorer, select and hold (or right-click) Solution 'kmdfecho' (3 projects) , and choose
Configuration Manager . Make sure that the configuration and platform settings are the same for the
three projects. By default, the configuration is set to "Win10 Debug", and the platform is set to "Win64"
for all the projects. If you make any configuration and/or platform changes for one project, you must
make the same changes for the remaining three projects.
4. Set the runtime librar y
Set the runtime library - Open the echo driver’s property page and locate C/C++ > Code Generation .
Change Runtime Library from DLL version to non DLL version. Without this setting, you have to install
the MSVC runtime to the target computer separately.
5. Check driver signing
Also on the driver’s properties make sure Driver Signing > Sign Mode is set to “Test Sign”. This is
required because Windows requires that drivers are signed.

6. Build the sample using Visual Studio

In Visual Studio, select Build > Build Solution .
If all goes well, the build windows should display a message indicating that the build for all three projects
succeeded.
7. Locate the built driver files
 In File Explorer, navigate to the folder that contains the extracted files for the sample. For example, you
would navigate to C:\DriverSamples\general\echo\kmdf, if that's the folder you specified earlier. Within
that folder, the location of the compiled driver files varies depending on the configuration and platform
settings that you selected in the Configuration Manager . For example, if you left the default settings
unchanged, then the compiled driver files will be saved to a folder named \x64\Debug for a 64 bit, debug
build.
Navigate to the folder that contains the built files for the Autosync driver:
C:\DriverSamples\general\echo\kmdf\driver\AutoSync\x64\Debug.
The folder should contain these files:

F IL E DESC RIP T IO N

Echo.sys The driver file.

Echo.inf An information (INF) file that contains information

needed to install the driver.

In addition, the echoapp.exe file was built and it should be located here:
C:\DriverSamples\general\echo\kmdf\exe\x64\Debug

F IL E DESC RIP T IO N

EchoApp.exe A command prompt executable test file that

communicates with the echo.sys driver.

8. Locate a USB thumb drive or set up a network share to copy the built driver files and the test EchoApp
from the host to the target system.
In the next section, you will copy the code to the target system, and install and test the driver.

Section 4: Install the KMDF echo driver sample on the target system
In Section 4, you will use devcon to install the echo sample driver.
The computer where you install the driver is called the target computer or the test computer. Typically, this is a
separate computer from the computer on which you develop and build the driver package. The computer where
you develop and build the driver is called the host computer.
The process of moving the driver package to the target computer and installing the driver is called deploying the
driver.
Before you deploy a test signed driver, you must prepare the target computer by enabling test signing. You also
need to locate the DevCon tool in your WDK installation and copy that to the target system.
To install the driver on the target system, perform the following steps.
-> On the target system
Enable test signed drivers
Enable the ability to run test signed drivers:
a. Open Windows Settings.
b. In Update and Security, select Recover y .
c. Under Advanced startup, select Restar t Now .
d. When the PC reboots, select Star tup options . In Windows 10, select Troubleshoot > Advanced options >
Star tup Settings , then select Restart button.
e. Select Disable driver signature enforcement by pressing the F7 key.
f. Reboot the target computer.
<- On the host system
Navigate to the Tools folder in your WDK installation and locate the DevCon tool. For example, look in the
following folder:
C:\Program Files (x86)\Windows Kits\10\Tools\x64\devcon.exe
Create a folder on the target for the built driver package (for example, C:\EchoDriver). Copy devcon.exe to the
target system. Locate the .cer certificate on the host system, it is in the same folder on the host computer in the
folder that contains the built driver files. Copy all the files from the built driver described earlier on the host
computer and save them to the same folder that you created on the target computer.
-> On the target system
On the target computer, select and hold (or right-click) the certificate file, and select Install , then follow the
prompts to install the test certificate.
If you need more detailed instructions for setting up the target computer, see Preparing a Computer for Manual
Driver Deployment.
-> On the target system
Install the driver
The following instructions show you how to install and test the sample driver. Here's the general syntax for the
devcon tool that you will use to install the driver:
devcon install <INF file> <hardware ID>
The INF file required for installing this driver is echo.inf. The inf file contains the hardware ID for installing the
echo.sys. For the echo sample the hardware ID is root\ECHO .
On the target computer, open a Command Prompt window as Administrator. Navigate to your driver package
folder, and enter the following command:
devcon install echo.inf root\ECHO If you get an error message about devcon not being recognized, try
adding the path to the devcon tool. For example, if you copied it to a folder called C:\Tools, then try using the
following command:
c:\tools\devcon install echo.inf root\ECHO A dialog box will appear indicating that the test driver is an
unsigned driver. Select Install this driver anyway to proceed.
 TIP
If you have any issues with the installation, check the following file for more information.
%windir%\inf\setupapi.dev.log

After successfully installing the sample driver, you're now ready to test it.
Examine the driver in Device Manager
On the target computer, in a Command Prompt window, enter devmgmt open Device Manager. In Device
Manager, on the View menu, choose Devices by type. In the device tree, locate Sample WDF Echo Driver in the
Sample Device node.

Test the driver

Type echoapp to start the test echo app to confirm that the driver is functional.

C:\Samples\KMDF_Echo_Sample> echoapp
DevicePath: \\?\root#sample#0005#{cdc35b6e-0be4-4936-bf5f-5537380a7c1a}
Opened device successfully
512 Pattern Bytes Written successfully
512 Pattern Bytes Read successfully
Pattern Verified successfully
30720 Pattern Bytes Written successfully
30720 Pattern Bytes Read successfully
Pattern Verified successfully

Section 5: Use WinDbg to display information about the driver

In Section 5, you will set the symbol path and use kernel debugger commands to display information about the
KMDF echo sample driver.
View information about the driver by performing the following steps.
<-On the host system
1. If you closed the debugger, open it again using the following command in the administrator command
prompt window.

WinDbg -k net:port=50000,key=2steg4fzbj2sz.23418vzkd4ko3.1g34ou07z4pev.1sp3yo9yz874p

2. Use Ctrl+Break (Scroll Lock) to break into the code running on the target system.
Setting the symbol path
1. To set the symbols path to the Microsoft symbol server in the WinDbg environment, use the .symfix
command.

0: kd> .symfix

2. To add your local symbol location to use your local symbols, add the path using .sympath+ and then
.reload /f .

0: kd> .sympath+ C:\DriverSamples\general\echo\kmdf

0: kd> .reload /f

Note The .reload command with the /f force option deletes all symbol information for the specified
module and reloads the symbols. In some cases, this command also reloads or unloads the module itself.
Note You must load the proper symbols to use advanced functionality that WinDbg provides. If you do not have
symbols properly configured, you will receive messages indicating that symbols are not available when you
attempt to use functionality that is dependent on symbols.

0:000> dv
Unable to enumerate locals, HRESULT 0x80004005
Private symbols (symbols.pri) are required for locals.
Type “.hh dbgerr005” for details.

Note
Symbol ser vers
There are a number of approaches that can be used to work with symbols. In many situations, you can configure
the PC to access symbols from a symbol server that Microsoft provides when they are needed. This walkthrough
assumes that this approach will be used. If the symbols in your environment are in a different location, modify
the steps to use that location. For additional information, see Symbol Stores and Symbol Servers.
Note
Understand source code symbol requirements
To perform source debugging, you must build a checked (debug) version of your binaries. The compiler will
create symbol files (.pdb files). These symbol files will show the debugger how the binary instructions
correspond to the source lines. The actual source files themselves must also be accessible to the debugger.
The symbol files do not contain the text of the source code. For debugging, it is best if the linker does not
optimize your code. Source debugging and access to local variables are more difficult, and sometimes nearly
impossible, if the code has been optimized. If you are having problems viewing local variables or source lines,
set the following build options:

set COMPILE_DEBUG=1
set ENABLE_OPTIMIZER=0

1. Type the following in the command area of the debugger to display information about the echo driver :

0: kd> lm m echo* v
Browse full module list
start end module name
fffff801`4ae80000 fffff801`4ae89000 ECHO (private pdb symbols)
C:\Samples\KMDF_ECHO_SAMPLE\echo.pdb
Loaded symbol image file: ECHO.sys
Image path: \SystemRoot\system32\DRIVERS\ECHO.sys
Image name: ECHO.sys
...

For information, see lm .

2. Because we set prefer_dml =1 earlier, some elements of the output are hot links that you can select.
Select the Browse all global symbols link in the debug output to display information about items symbols
that start with the letter “a”.

0: kd> x /D Echo!a*

3. As it turns out, the echo sample doesn’t contain any symbols that start with the letter “a”, so type
x ECHO!Echo* to display information about all of the symbols associated with echo driver that start with
Echo.

0: kd> x ECHO!Echo*
fffff801`0bf95690 ECHO!EchoEvtIoQueueContextDestroy (void *)
fffff801`0bf95000 ECHO!EchoEvtDeviceSelfManagedIoStart (struct WDFDEVICE__ *)
fffff801`0bf95ac0 ECHO!EchoEvtTimerFunc (struct WDFTIMER__ *)
fffff801`0bf9b120 ECHO!EchoEvtDeviceSelfManagedIoSuspend (struct WDFDEVICE__ *)
...

For information, see x (Examine Symbols) .

4. The !lmi extension displays detailed information about a module. Type !lmi echo . Your output should be
similar to the text shown below.

0: kd> !lmi echo

Loaded Module Info: [echo]
Module: ECHO
Base Address: fffff8010bf94000
Image Name: ECHO.sys
…

5. Use the !dh extension to display header information as shown below.

 0: kd> !dh echo

File Type: EXECUTABLE IMAGE

FILE HEADER VALUES
14C machine (i386)
6 number of sections
54AD8A42 time date stamp Wed Jan 07 11:34:26 2015
...

6. Setting the debug mask

Type the following to change the default debug bit mask so that all debug messages from the target
system will be displayed in the debugger.

0: kd> ed nt!Kd_DEFAULT_MASK 0xFFFFFFFF

Some drivers will display additional information when the mask of 0xFFFFFFFF is used. Set the mask to
0x00000000 if you would like to reduce the amount of information that is displayed.

0: kd> ed nt!Kd_DEFAULT_MASK 0x00000000

Use the dd command to display confirm the mask is set to display all of the debugger messages.

0: kd> dd nt!kd_DEFAULT_MASK
fffff802`bb4057c0 ffffffff 00000000 00000000 00000000
fffff802`bb4057d0 00000000 00000000 00000000 00000000
fffff802`bb4057e0 00000001 00000000 00000000 00000000
fffff802`bb4057f0 00000000 00000000 00000000 00000000
fffff802`bb405800 00000000 00000000 00000000 00000000
fffff802`bb405810 00000000 00000000 00000000 00000000
fffff802`bb405820 00000000 00000000 00000000 00000000
fffff802`bb405830 00000000 00000000 00000000 00000000

Section 6: Displaying Plug and Play device tree information

In Section 6, you will display information about the echo sample device driver and where it lives in the Plug and
Play device tree.
Information about the device driver in the Plug and Play device tree can be useful for troubleshooting. For
example, if a device driver is not resident in the device tree, there may an issue with the installation of the device
driver.
For more information about the device node debug extension, see !devnode .
<-On the host system
1. To see all the device nodes in the Plug and Play device tree, enter the !devnode 0 1 command.
 0: kd> !devnode 0 1
Dumping IopRootDeviceNode (= 0xffffe0005a3a8d30)
DevNode 0xffffe0005a3a8d30 for PDO 0xffffe0005a3a9e50
InstancePath is "HTREE\ROOT\0"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
DevNode 0xffffe0005a3a3d30 for PDO 0xffffe0005a3a4e50
InstancePath is "ROOT\volmgr\0000"
ServiceName is "volmgr"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
DevNode 0xffffe0005a324560 for PDO 0xffffe0005bd95ca0…
…

2. Use Ctrl+F to search in the output that is generated to look for the name of the device driver, echo.

3. The echo device driver should be loaded. Use the !devnode 0 1 echo command to display Plug and
Play information associated with our echo device driver as shown below.

0: Kd> !devnode 0 1 echo

Dumping IopRootDeviceNode (= 0xffffe0007b725d30)
DevNode 0xffffe0007b71a630 for PDO 0xffffe0007b71a960
InstancePath is "ROOT\SAMPLE\0000"
ServiceName is "ECHO"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
…

4. The output displayed in the previous command includes the PDO associated with the running instance of
our driver, in this example it is 0xffffe0007b71a960. Enter the !devobj <PDO address> command to
display Plug and Play information associated with the echo device driver. Use the PDO address that
!devnode displays on your PC, not the one shown here.

0: kd> !devobj 0xffffe0007b71a960

Device object (ffffe0007b71a960) is for:
0000000e \Driver\PnpManager DriverObject ffffe0007b727e60
Current Irp 00000000 RefCount 0 Type 00000004 Flags 00001040
Dacl ffffc102c9b36031 DevExt 00000000 DevObjExt ffffe0007b71aab0 DevNode ffffe0007b71a630
ExtensionFlags (0x00000800) DOE_DEFAULT_SD_PRESENT
Characteristics (0x00000180) FILE_AUTOGENERATED_DEVICE_NAME, FILE_DEVICE_SECURE_OPEN
AttachedDevice (Upper) ffffe000801fee20 \Driver\ECHO
Device queue is not busy.

5. The output displayed in the !devnode 0 1 command includes the PDO address associated with the
running instance of our driver, in this example it is 0xffffe0007b71a960. Enter the !devstack <PDO
address> command to display Plug and Play information associated with the device driver. Use the PDO
address that !devnode displays on your PC, not the one shown below.
 0: kd> !devstack 0xffffe0007b71a960
!DevObj !DrvObj !DevExt ObjectName
ffffe000801fee20 \Driver\ECHO ffffe0007f72eff0
> ffffe0007b71a960 \Driver\PnpManager 00000000 0000000e
!DevNode ffffe0007b71a630 :
DeviceInst is "ROOT\SAMPLE\0000"
ServiceName is "ECHO"

The output shows that we have a fairly simple device driver stack. The echo driver is a child of the PnPManager
node. The PnPManager is a root node.
\Driver\ECHO
\Driver\PnpManager
This diagram shows a more complex device node tree.

Note For more information about more complex driver stacks, see Driver stacks and Device nodes and device
stacks.

Section 7: Working with breakpoints and source code

In Section 7, you will set breakpoints and single step through kernel mode source code.
Note
Setting breakpoints using commands
To be able to step through code and check the values of variables in real time, we need to enable breakpoints
and set a path to the source code.
Breakpoints are used to stop code execution at a particular line of code. You can then step forward in the code
from that point, to debug that specific section of code.
To set a breakpoint using a debug command, use one of the following b commands.

bp Sets a breakpoint that will be active until the module it is

in is unloaded.

bu Sets a breakpoint that is unresolved when the module is

unloaded and re-enables when the module reloads.

bm Sets a breakpoint for a symbol. This command will use

bu or bp appropriately and allows wildcards * to be used
to set breakpoints on every symbols that matches (like
all methods in a class).

For more information, see Source Code Debugging in WinDbg in the debugging reference documentation.
<-On the host system
1. Use the WinDbg UI to confirm that Debug > Source Mode is enabled in the current WinDbg session.
2. Add your local code location to the source path by typing the following command.

.srcpath+ C:\DriverSamples\KMDF_Echo_Sample\driver\AutoSync

3. Add your local symbol location to the symbol path by typing the following command.

.sympath+ C:\DriverSamples\KMDF_Echo_Sample\driver\AutoSync

4. We will use the x command to examine the symbols associated with the echo driver to determine the
function name to use for the breakpoint. We can use a wild card or Ctrl+F to locate the DeviceAdd
function name.

0: kd> x ECHO!EchoEvt*
8b4c7490 ECHO!EchoEvtIoQueueContextDestroy (void *)
8b4c7000 ECHO!EchoEvtDeviceSelfManagedIoStart (struct WDFDEVICE__ *)
8b4c7820 ECHO!EchoEvtTimerFunc (struct WDFTIMER__ *)
8b4cb0e0 ECHO!EchoEvtDeviceSelfManagedIoSuspend (struct WDFDEVICE__ *)
8b4c75d0 ECHO!EchoEvtIoWrite (struct WDFQUEUE__ *, struct WDFREQUEST__ *, unsigned int)
8b4cb170 ECHO!EchoEvtDeviceAdd (struct WDFDRIVER__ *, struct
…

The output above shows that DeviceAdd method for our echo driver is ECHO!EchoEvtDeviceAdd.
Alternatively, we could review the source code to locate the desired function name for our breakpoint.
5. Set the breakpoint with the bm command using the name of the driver, followed by the function name
(for example AddDevice ) where you want to set the breakpoint, separated by an exclamation mark. We
will use AddDevice to watch the driver being loaded.

0: kd> bm ECHO!EchoEvtDeviceAdd
1: fffff801`0bf9b1c0 @!"ECHO!EchoEvtDeviceAdd"

Note
You can use different syntax in conjunction with setting variables like <module>!<symbol>, <class>::
<method>,‘<file.cpp>:<line number>’, or skip a number of times <condition> <#>. For more
 information, see Conditional breakpoints in WinDbg and other Windows debuggers.
6. List the current breakpoints to confirm that the breakpoint was set by typing the bl command.

0: kd> bl
1 e fffff801`0bf9b1c0 0001 (0001) ECHO!EchoEvtDeviceAdd

The "e" in the output shown above indicates that the breakpoint number 1 is enabled to fire.
7. Restart code execution on the target system by typing the go command g .
8. -> On the target system
In Windows, open Device Manager using the icon or by entering mmc devmgmt.msc . In Device
Manager, expand the Samples node.
9. Select and hold (or right-click) the KMDF Echo driver entry and select Disable from the menu.
10. Select and hold (or right-click) the KMDF Echo driver entry again and select Enable from the menu.
11. <- On the host system
When the driver is enabled, the AddDevice debug breakpoint should fire, and the execution of the driver
code on the target system should halt. When the breakpoint is hit, the execution should be stopped at the
start of the AddDevice routine. The debug command output will display "Breakpoint 1 hit".

12. Step through the code line-by-line by typing the p command or pressing F10 until you reach the
following end of the AddDevice routine. The Brace character “}” will be highlighted as shown.
13. In the next section, we will examine the state of the variables after the DeviceAdd code has executed.
Note
Modifying breakpoint state
You can modify existing breakpoints by using the following commands:

bl Lists breakpoints.

bc Clears a breakpoint from the list. Use bc * to clear all

breakpoints.

bd Disables a breakpoint. Use bd * to disable all

breakpoints.

be Enables a breakpoint. Use be * to enable all breakpoints.

Alternatively, you can also modify breakpoints by selecting edit > breakpoints in WinDbg. Note that the
breakpoint dialog box only works with existing breakpoints. New breakpoints must be set from the command
line.
Note
Setting memor y access breakpoints
You can also set breakpoints that fire when a memory location is accessed. Use the ba (break on access)
command, with the following syntax.

ba <access> <size> <address> {options}

O P T IO N DESC RIP T IO N

e execute (when CPU fetches an instruction from the

address)

r read/write (when CPU reads or writes to the address)

w write (when the CPU writes to the address)

Note that you can only set four data breakpoints at any given time and it is up to you to make sure that you are
aligning your data correctly or you won’t trigger the breakpoint (words must end in addresses divisible by 2,
dwords must be divisible by 4, and quadwords by 0 or 8).
For example, to set a read/write breakpoint on a specific memory address, you could use a command like this.

ba r 4 0x0003f7bf0

Note
Stepping through code from the Debugger Command window
The following are the commands that you can use to step through your code (with the associated keyboard
short cuts shown in parentheses).
Break in (Ctrl+Break) - This command will interrupt a system as long as the system is running and is in
communication with WinDbg (the sequence in the Kernel Debugger is Ctrl+C).
Run to cursor (F7 or Ctrl+F10) – Place the cursor in a source or disassembly window where you want the
execution to break, then press F7; code execution will run to that point. Note that if the flow of code
execution does not reach the point indicated by the cursor (an IF statement isn't executed), WinDbg would
not break, because the code execution did not reach the indicated point.
Run (F5) – Run until a breakpoint is encountered or an event like a bug check occurs.
Step over (F10) – This command causes code execution to proceed one statement or one instruction at a
time. If a call is encountered, code execution passes over the call without entering the called routine. (If
the programming language is C or C++ and WinDbg is in source mode, source mode can be turned on
or off using Debug >Source Mode ).
Step in (F11) – This command is like step-over, except that the execution of a call does go into the called
routine.
Step out (Shift+F11) – This command causes execution to run to and exit from the current routine
(current place in the call stack). This is useful if you've seen enough of the routine.
For more information, see Source Code Debugging in WinDbg in the debugging reference documentation.

Section 8: Viewing variables and call stacks

In Section 8, you will display information about variables and call stacks.
This lab assumes that you are stopped at the AddDevice routine using the process described earlier. To view the
output show here, repeat the steps described previously, if necessary.
<- On the host system
Display variables
Use the view > local menu item to display local variables.

Global variables
You can find the location of a global variable address by typing ? <variable name>.
Local variables
You can display the names and values of all local variables for a given frame by typing the dv command.

0: kd> dv
Driver = 0x00001fff`7ff9c838
DeviceInit = 0xffffd001`51978190
status = 0n0

Callstacks
Note
The call stack is the chain of function calls that have led to the current location of the program counter. The top
function on the call stack is the current function, and the next function is the function that called the current
function, and so on.
To display the call stack, use the k* commands.

kb Displays the stack and first three parameters.

kp Displays the stacks and the full list of parameters.

kn Allows you to see the stack with the frame information

next to it.

<-On the host system

1. If you want to keep the call stack available, you can select view > call stack to view it. Select the columns at
the top of the window to toggle the display of additional information.

2. Use the kn command to show the call stack while debugging the sample adapter code in a break state.
 3: kd> kn
# Child-SP RetAddr Call Site
00 ffffd001`51978110 fffff801`0942f55b ECHO!EchoEvtDeviceAdd+0x66 [c:\Samples\kmdf echo
sample\c++\driver\autosync\driver.c @ 138]
01 (Inline Function) --------`-------- Wdf01000!FxDriverDeviceAdd::Invoke+0x30
[d:\wbrtm\minkernel\wdf\framework\shared\inc\private\common\fxdrivercallbacks.hpp @ 61]
02 ffffd001`51978150 fffff801`eed8097d Wdf01000!FxDriver::AddDevice+0xab
[d:\wbrtm\minkernel\wdf\framework\shared\core\km\fxdriverkm.cpp @ 72]
03 ffffd001`51978570 fffff801`ef129423 nt!PpvUtilCallAddDevice+0x35
[d:\9142\minkernel\ntos\io\pnpmgr\verifier.c @ 104]
04 ffffd001`519785b0 fffff801`ef0c4112 nt!PnpCallAddDevice+0x63 [d:\9142\minkernel\ntos\io\pnpmgr\enum.c @
7397]
05 ffffd001`51978630 fffff801`ef0c344f nt!PipCallDriverAddDevice+0x6e2
[d:\9142\minkernel\ntos\io\pnpmgr\enum.c @ 3390]
...

The call stack shows that the kernel (nt) called into Plug and Play code (PnP), that called driver framework code
(WDF) that subsequently called the echo driver DeviceAdd function.

Section 9: Displaying processes and threads

Processes
In Section 9, you will display information about the process and threads running in kernel mode.
Note
You can display or set process information by using the !process debugger extension. We will set a breakpoint
to examine the process that are used when a sound is played.
1. <- On the host system
Type the dv command to examine the locale variables associated with the EchoEvtIo routine as shown.

0: kd> dv ECHO!EchoEvtIo*
ECHO!EchoEvtIoQueueContextDestroy
ECHO!EchoEvtIoWrite
ECHO!EchoEvtIoRead

2. Clear the previous breakpoints using bc * .

0: kd> bc *

3. c. Set a symbol breakpoint on the EchoEvtIo routines using the following command.

0: kd> bm ECHO!EchoEvtIo*
2: aade5490 @!”ECHO!EchoEvtIoQueueContextDestroy”
3: aade55d0 @!”ECHO!EchoEvtIoWrite”
4: aade54c0 @!”ECHO!EchoEvtIoRead”

4. List the breakpoints to confirm that the breakpoint is set properly.

0: kd> bl
1 e aabf0490 [c:\Samples\kmdf echo sample\c++\driver\autosync\queue.c @ 197] 0001 (0001)
ECHO!EchoEvtIoQueueContextDestroy
...

5. Type g to restart code execution.

 0: kd> g

6. -> On the target system

Run the EchoApp.exe driver test program on the target system.
7. <- On the host system
When the test app runs, the I/O routine in the driver will be called. This will cause the breakpoint to fire,
and execution of the driver code on the target system will halt.

Breakpoint 2 hit
ECHO!EchoEvtIoWrite:
fffff801`0bf95810 4c89442418 mov qword ptr [rsp+18h],r8

8. Use the !process command to display the current process that is involved in running echoapp.exe.

0: kd> !process
PROCESS ffffe0007e6a7780
SessionId: 1 Cid: 03c4 Peb: 7ff7cfec4000 ParentCid: 0f34
DirBase: 1efd1b000 ObjectTable: ffffc001d77978c0 HandleCount: 34.
Image: echoapp.exe
VadRoot ffffe000802c79f0 Vads 30 Clone 0 Private 135. Modified 5. Locked 0.
DeviceMap ffffc001d83c6e80
Token ffffc001cf270050
ElapsedTime 00:00:00.052
UserTime 00:00:00.000
KernelTime 00:00:00.000
QuotaPoolUsage[PagedPool] 33824
QuotaPoolUsage[NonPagedPool] 4464
Working Set Sizes (now,min,max) (682, 50, 345) (2728KB, 200KB, 1380KB)
PeakWorkingSetSize 652
VirtualSize 16 Mb
PeakVirtualSize 16 Mb
PageFaultCount 688
MemoryPriority BACKGROUND
BasePriority 8
CommitCharge 138

THREAD ffffe00080e32080 Cid 03c4.0ec0 Teb: 00007ff7cfece000 Win32Thread: 0000000000000000

RUNNING on processor 1

The output shows that the process is associated with the echoapp.exe which was running when our
breakpoint on the driver write event was hit. For more information, see !process .
9. Use the !process 0 0 to display summary information for all processes. In the output, use CTRL+F to
locate the same process address for the process associated with the echoapp.exe image. In the example
shown below, the process address is ffffe0007e6a7780.

...

PROCESS ffffe0007e6a7780
SessionId: 1 Cid: 0f68 Peb: 7ff7cfe7a000 ParentCid: 0f34
DirBase: 1f7fb9000 ObjectTable: ffffc001cec82780 HandleCount: 34.
Image: echoapp.exe

...

10. Record the process ID associated with echoapp.exe to use later in this lab. You can also use CTRL+C, to
 copy the address to the copy buffer for later use.
_____________________________________________________(echoapp.exe process address)
11. Enter g as required into the debugger to run the code forward until the echoapp.exe finishes running. It
will hit the breakpoint in the read and write event a number of times. When echoapp.exe finishes, break in
to the debugger, by pressing CTRL+ScrLk (Ctrl+Break).
12. Use the !process command to confirm that you are now running a different process. In the output
shown below, the process with the Image value of System is different from the Echo Image value.

1: kd> !process
PROCESS ffffe0007b65d900
SessionId: none Cid: 0004 Peb: 00000000 ParentCid: 0000
DirBase: 001ab000 ObjectTable: ffffc001c9a03000 HandleCount: 786.
Image: System
VadRoot ffffe0007ce45930 Vads 14 Clone 0 Private 22. Modified 131605. Locked 64.
DeviceMap ffffc001c9a0c220
Token ffffc001c9a05530
ElapsedTime 21:31:02.516
...

The output above shows that a system process ffffe0007b65d900 was running, when we stopped the OS.
13. Now, use the !process command to try to look at the process ID that had been associated with
echoapp.exe that you recorded earlier. Provide your echoapp.exe process address that you recorded
earlier, instead of the example process address shown below.

0: kd> !process ffffe0007e6a7780

TYPE mismatch for process object at 82a9acc0

The process object is no longer available, as the echoapp.exe process is no longer running.
Threads
Note
The commands to view and set threads are very similar to those of processes. Use the !thread command to
view threads. Use .thread to set the current threads.
1. <- On the host system
Enter g into the debugger to restart code execution on the target system.
2. -> On the target system
Run the EchoApp.exe driver test program on the target system.
3. <- On the host system
The breakpoint will be hit and code execution will halt.

Breakpoint 4 hit
ECHO!EchoEvtIoRead:
aade54c0 55 push ebp

4. To view the threads that are running, type !thread . Information similar to the following should be
displayed:
 0: kd> !thread
THREAD ffffe000809a0880 Cid 0b28.1158 Teb: 00007ff7d00dd000 Win32Thread: 0000000000000000 RUNNING
on processor 0
IRP List:
ffffe0007bc5be10: (0006,01f0) Flags: 00060a30 Mdl: 00000000
Not impersonating
DeviceMap ffffc001d83c6e80
Owning Process ffffe0008096c900 Image: echoapp.exe
...

Note the image name of echoapp.exe, indicating that we are looking at the thread associated with the test
app.
5. d. Use the !process command to determine if this is the only thread running in the process associated
with echoapp.exe. Note that the thread number of the running thread in the process is the same
thread running that the !thread command displayed.

0: kd> !process
PROCESS ffffe0008096c900
SessionId: 1 Cid: 0b28 Peb: 7ff7d00df000 ParentCid: 0f34
DirBase: 1fb746000 ObjectTable: ffffc001db6b52c0 HandleCount: 34.
Image: echoapp.exe
VadRoot ffffe000800cf920 Vads 30 Clone 0 Private 135. Modified 8. Locked 0.
DeviceMap ffffc001d83c6e80
Token ffffc001cf5dc050
ElapsedTime 00:00:00.048
UserTime 00:00:00.000
KernelTime 00:00:00.000
QuotaPoolUsage[PagedPool] 33824
QuotaPoolUsage[NonPagedPool] 4464
Working Set Sizes (now,min,max) (681, 50, 345) (2724KB, 200KB, 1380KB)
PeakWorkingSetSize 651
VirtualSize 16 Mb
PeakVirtualSize 16 Mb
PageFaultCount 686
MemoryPriority BACKGROUND
BasePriority 8
CommitCharge 138

THREAD ffffe000809a0880 Cid 0b28.1158 Teb: 00007ff7d00dd000 Win32Thread: 0000000000000000

RUNNING on processor 0

6. Use the !process 0 0 command to locate the process address of two related processes and record
those process address here.
Cmd.exe: ____________________________________________________________
EchoApp.exe: _______________________________________________________
 0: kd> !process 0 0

PROCESS ffffe0007bbde900
SessionId: 1 Cid: 0f34 Peb: 7ff72dfa7000 ParentCid: 0c64
DirBase: 19c5fa000 ObjectTable: ffffc001d8c2f300 HandleCount: 31.
Image: cmd.exe
…
PROCESS ffffe0008096c900
SessionId: 1 Cid: 0b28 Peb: 7ff7d00df000 ParentCid: 0f34
DirBase: 1fb746000 ObjectTable: ffffc001db6b52c0 HandleCount: 34.
Image: echoapp.exe
…

Note You can alternatively use !process 0 17 to display detailed information about every process. The
output from this command can be lengthy. The output can be searched using Ctrl+F.
7. Use the !process command to list process information for both processes running your PC. Provide the
process address from your !process 0 0 output, not the address shown below.
This example output is for the cmd.exe process ID that was recorded earlier. Note that the image name for
this process ID is cmd.exe.

0: kd> !process ffffe0007bbde900

PROCESS ffffe0007bbde900
SessionId: 1 Cid: 0f34 Peb: 7ff72dfa7000 ParentCid: 0c64
DirBase: 19c5fa000 ObjectTable: ffffc001d8c2f300 HandleCount: 31.
Image: cmd.exe
VadRoot ffffe0007bb8e7b0 Vads 25 Clone 0 Private 117. Modified 20. Locked 0.
DeviceMap ffffc001d83c6e80
Token ffffc001d8c48050
ElapsedTime 21:33:05.840
UserTime 00:00:00.000
KernelTime 00:00:00.000
QuotaPoolUsage[PagedPool] 24656
QuotaPoolUsage[NonPagedPool] 3184
Working Set Sizes (now,min,max) (261, 50, 345) (1044KB, 200KB, 1380KB)
PeakWorkingSetSize 616
VirtualSize 2097164 Mb
PeakVirtualSize 2097165 Mb
PageFaultCount 823
MemoryPriority FOREGROUND
BasePriority 8
CommitCharge 381

THREAD ffffe0007cf34880 Cid 0f34.0f1c Teb: 00007ff72dfae000 Win32Thread: 0000000000000000

WAIT: (UserRequest) UserMode Non-Alertable
ffffe0008096c900 ProcessObject
Not impersonating
...

This example output is for the echoapp.exe process ID that was recorded earlier.
 0: kd> !process ffffe0008096c900
PROCESS ffffe0008096c900
SessionId: 1 Cid: 0b28 Peb: 7ff7d00df000 ParentCid: 0f34
DirBase: 1fb746000 ObjectTable: ffffc001db6b52c0 HandleCount: 34.
Image: echoapp.exe
VadRoot ffffe000800cf920 Vads 30 Clone 0 Private 135. Modified 8. Locked 0.
DeviceMap ffffc001d83c6e80
Token ffffc001cf5dc050
ElapsedTime 00:00:00.048
UserTime 00:00:00.000
KernelTime 00:00:00.000
QuotaPoolUsage[PagedPool] 33824
QuotaPoolUsage[NonPagedPool] 4464
Working Set Sizes (now,min,max) (681, 50, 345) (2724KB, 200KB, 1380KB)
PeakWorkingSetSize 651
VirtualSize 16 Mb
PeakVirtualSize 16 Mb
PageFaultCount 686
MemoryPriority BACKGROUND
BasePriority 8
CommitCharge 138

THREAD ffffe000809a0880 Cid 0b28.1158 Teb: 00007ff7d00dd000 Win32Thread: 0000000000000000

RUNNING on processor 0
IRP List:
ffffe0007bc5be10: (0006,01f0) Flags: 00060a30 Mdl: 00000000
Not impersonating
...

8. Record the first thread address associated with the two processes here.
Cmd.exe: ____________________________________________________
EchoApp.exe: _________________________________________________
9. Use the !Thread command to display information about the current thread.

0: kd> !Thread
THREAD ffffe000809a0880 Cid 0b28.1158 Teb: 00007ff7d00dd000 Win32Thread: 0000000000000000 RUNNING
on processor 0
IRP List:
ffffe0007bc5be10: (0006,01f0) Flags: 00060a30 Mdl: 00000000
Not impersonating
DeviceMap ffffc001d83c6e80
Owning Process ffffe0008096c900 Image: echoapp.exe
Attached Process N/A Image: N/A
...

As expected, the current thread is the thread associated with echoapp.exe and it is in a running state.
10. Use the !Thread command to display information about the thread associated with cmd.exe process.
Provide the thread address you recorded earlier.
 0: kd> !Thread ffffe0007cf34880
THREAD ffffe0007cf34880 Cid 0f34.0f1c Teb: 00007ff72dfae000 Win32Thread: 0000000000000000 WAIT:
(UserRequest) UserMode Non-Alertable
ffffe0008096c900 ProcessObject
Not impersonating
DeviceMap ffffc001d83c6e80
Owning Process ffffe0007bbde900 Image: cmd.exe
Attached Process N/A Image: N/A
Wait Start TickCount 4134621 Ticks: 0
Context Switch Count 4056 IdealProcessor: 0
UserTime 00:00:00.000
KernelTime 00:00:01.421
Win32 Start Address 0x00007ff72e9d6e20
Stack Init ffffd0015551dc90 Current ffffd0015551d760
Base ffffd0015551e000 Limit ffffd00155518000 Call 0
Priority 14 BasePriority 8 UnusualBoost 3 ForegroundBoost 2 IoPriority 2 PagePriority 5
Child-SP RetAddr : Args to Child
: Call Site
ffffd001`5551d7a0 fffff801`eed184fe : fffff801`eef81180 ffffe000`7cf34880 00000000`fffffffe
00000000`fffffffe : nt!KiSwapContext+0x76 [d:\9142\minkernel\ntos\ke\amd64\ctxswap.asm @ 109]
ffffd001`5551d8e0 fffff801`eed17f79 : ffff03a5`ca56a3c8 000000de`b6a6e990 000000de`b6a6e990
00007ff7`d00df000 : nt!KiSwapThread+0x14e [d:\9142\minkernel\ntos\ke\thredsup.c @ 6347]
ffffd001`5551d980 fffff801`eecea340 : ffffd001`5551da18 00000000`00000000 00000000`00000000
00000000`00000388 : nt!KiCommitThreadWait+0x129 [d:\9142\minkernel\ntos\ke\waitsup.c @ 619]
...

This thread is associated with cmd.exe and is in a wait state.

11. Provide the thread address of the waiting CMD.exe thread to change the context to that waiting thread.

0: kd> .Thread ffffe0007cf34880

Implicit thread is now ffffe000`7cf34880

12. Use the k command to view the call stack associated with the waiting thread.

0: kd> k
*** Stack trace for last set context - .thread/.cxr resets it
# Child-SP RetAddr Call Site
00 ffffd001`5551d7a0 fffff801`eed184fe nt!KiSwapContext+0x76
[d:\9142\minkernel\ntos\ke\amd64\ctxswap.asm @ 109]
01 ffffd001`5551d8e0 fffff801`eed17f79 nt!KiSwapThread+0x14e [d:\9142\minkernel\ntos\ke\thredsup.c @
6347]
02 ffffd001`5551d980 fffff801`eecea340 nt!KiCommitThreadWait+0x129
[d:\9142\minkernel\ntos\ke\waitsup.c @ 619]
03 ffffd001`5551da00 fffff801`ef02e642 nt!KeWaitForSingleObject+0x2c0
[d:\9142\minkernel\ntos\ke\wait.c @ 683]
...

Call stack elements such as KiCommitThreadWait indicate that this thread is not running as is expected.
Note
For more information about threads and processes, see the following references:
Threads and Processes
Changing Contexts

Section 10: IRQL, Registers and Ending the WinDbg session

Viewing the saved IRQL
In Section 10, you will display the IRQL, and the contents of the regsisters.
<- On the host system
The interrupt request level (IRQL) is used to manage the priority of interrupt servicing. Each processor has an
IRQL setting that threads can raise or lower. Interrupts that occur at or below the processor's IRQL setting are
masked and will not interfere with the current operation. Interrupts that occur above the processor's IRQL
setting take precedence over the current operation. The !irql extension displays the interrupt request level
(IRQL) on the current processor of the target computer before the debugger break occurred. When the target
computer breaks into the debugger, the IRQL changes, but the IRQL that was effective just before the debugger
break is saved and is displayed by !irql .

0: kd> !irql
Debugger saved IRQL for processor 0x0 -- 2 (DISPATCH_LEVEL)

Viewing the registers

<-On the host system
Display the contents of the registers for the current thread on the current processor by using the r (Registers)
command.

0: kd> r
rax=000000000000c301 rbx=ffffe00173eed880 rcx=0000000000000001
rdx=000000d800000000 rsi=ffffe00173eed8e0 rdi=ffffe00173eed8f0
rip=fffff803bb757020 rsp=ffffd001f01f8988 rbp=ffffe00173f0b620
r8=000000000000003e r9=ffffe00167a4a000 r10=000000000000001e
r11=ffffd001f01f88f8 r12=0000000000000000 r13=ffffd001f01efdc0
r14=0000000000000001 r15=0000000000000000
iopl=0 nv up ei pl nz na pe nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00000202
nt!DbgBreakPointWithStatus:
fffff803`bb757020 cc int 3

Alternatively, you can display the contents of the registers by selecting view > registers . For more information
see r (Registers) .
Viewing the contents of the registers can be helpful when stepping through assembly language code execution
and in other scenarios. For more information about assembly language disassembly, see Annotated x86
Disassembly and Annotated x64 Disassembly.
For information about contents of the register, see x86 Architecture and x64 Architecture.
Ending the WinDbg session
<-On the host system
To end a user-mode debugging session, return the debugger to dormant mode, and set the target application to
run again, enter the qd (Quit and Detach) command.
Be sure and use the g command to let the target computer run code, so that it can be used. It also a good idea to
clear any break points using bc * , so that the target computer won't break and try to connect to the host
computer debugger.

0: kd> qd

For more information, see Ending a Debugging Session in WinDbg in the debugging reference documentation.

Section 11: Windows debugging resources

Additional information is available on Windows debugging. Note that some of these books will use older
versions of Windows such as Windows Vista in their examples, but the concepts discussed are applicable to
most versions of Windows.
Books
Advanced Windows Debugging by Mario Hewardt and Daniel Pravat
Inside Windows Debugging: A Practical Guide to Debugging and Tracing Strategies in Windows® by
Tarik Soulami
Windows Internals by Mark E. Russinovich, David A. Solomon and Alex Ionescu
Video
The Defrag Tools Show WinDbg Episodes 13-29 https://channel9.msdn.com/Shows/Defrag-Tools
Training Vendors:
OSR https://www.osr.com/

Related topics
Standard Debugging Techniques
Specialized Debugging Techniques
Getting Started with Windows Debugging
 Debug Drivers - Step by Step Lab (Sysvad Kernel
Mode)
6/16/2021 • 55 minutes to read • Edit Online

This lab provides hands-on exercises that demonstrate how to debug the Sysvad audio kernel-mode device
driver.
Microsoft Windows Debugger (WinDbg) is a powerful Windows-based debugging tool that you can use to
perform user-mode and kernel-mode debugging. WinDbg provides source-level debugging for the Windows
kernel, kernel-mode drivers, and system services, as well as user-mode applications and drivers.
WinDbg can step through source code, set breakpoints, view variables (including C++ objects), stack traces, and
memory. Its Debugger Command window allows the user to issue a wide variety of commands.

Lab setup
You will need the following hardware to be able to complete the lab:
A laptop or desktop computer (host) running Windows 10
A laptop or desktop computer (target) running Windows 10
A network hub/router and network cables to connect the two PCs
Access to the internet to download symbol files
You will need the following software to be able to complete the lab.
Microsoft Visual Studio 2017
Windows Software Development Kit (SDK) for Windows 10
Windows Driver Kit (WDK) for Windows 10
The sample Sysvad audio driver for Windows 10
For information on downloading and installing the WDK, see Download the Windows Driver Kit (WDK).

Sysvad debugging walkthrough

This lab walk you through the process of debugging a kernel-mode driver. The exercises use the Syvad virtual
audio driver sample. Because the Syvad audio driver doesn't interact with actual audio hardware, it can be used
on most devices. The lab covers the following tasks:
Section 1: Connect to a kernel-mode WinDbg session
Section 2: kernel-mode debugging commands and techniques
Section 3: Download and build the Sysvad audio driver
Section 4: Install the Sysvad audio driver on the target system
Section 5: Use WinDbg to display information about the driver
Section 6: Display Plug and Play device tree information
Section 7: Work with breakpoints and source code
Section 8: Look at variables
Section 9: View call stacks
Section 10: Display processes and threads
Section 11: IRQL, registers and disassembly
 Section 12: Work with memory
Section 13: Ending the WinDbg session
Section 14: Windows debugging resources

Echo driver lab

The Echo driver is a simpler driver then the Sysvad audio driver. If you are new to WinDbg, you may want to
consider first completing the Debug Universal Drivers - Step-by-Step Lab (Echo kernel mode). This lab reuses
the setup directions from that lab, so if you have completed that lab you can skip sections 1 and 2 here.

Section 1: Connect to a kernel-mode WinDbg session

In Section 1, you will configure network debugging on the host and target system.
The PCs in this lab need to be configured to use an Ethernet network connection for kernel debugging.
This lab uses two computers. WinDbg runs on the host system and the Sysvad driver runs on the target system.
Use a network hub/router and network cables to connect the two PCs.

To work with kernel-mode applications and use WinDbg, we recommend that you use the KDNET over Ethernet
transport. For information about how to use the Ethernet transport protocol, see Getting Started with WinDbg
(Kernel-Mode). For more information about setting up the target computer, see Preparing a Computer for
Manual Driver Deployment and Setting Up KDNET Network Kernel Debugging Automatically.
Configure kernel–mode debugging using ethernet
To enable kernel-mode debugging on the target system, perform the following steps.
<- On the host system
1. Open a command prompt on the host system and type ipconfig /all to determine its IP address.

C:\>ipconfig /all
Windows IP Configuration

Host Name . . . . . . . . . . . . : TARGETPC

...

Ethernet adapter Ethernet:

Connection-specific DNS Suffix . :
Link-local IPv6 Address . . . . . : fe80::c8b6:db13:d1e8:b13b3
Autoconfiguration IPv4 Address. . : 169.182.1.1
Subnet Mask . . . . . . . . . . . : 255.255.0.0
Default Gateway . . . . . . . . . :

2. Record the IP address of the host System: ______________________________________

3. Record the Host Name of the host System: ______________________________________
-> On the target system
4. Open a command prompt on the target system and use the ping command to confirm network connectivity
between the two systems. Use the actual IP address of the host system you recorded instead of 169.182.1.1
that is shown in the sample output.
 C:\> ping 169.182.1.1

Pinging 169.182.1.1 with 32 bytes of data:

Reply from 169.182.1.1: bytes=32 time=1ms TTL=255
Reply from 169.182.1.1: bytes=32 time<1ms TTL=255
Reply from 169.182.1.1: bytes=32 time<1ms TTL=255
Reply from 169.182.1.1: bytes=32 time<1ms TTL=255

Ping statistics for 169.182.1.1:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 1ms, Average = 0ms

To use the KDNET utility to enable kernel-mode debugging on the target system, peform the following steps.
1. On the host system, locate the WDK KDNET directory. By default it is located here.
C:\Program Files (x86)\Windows Kits\10\Debuggers\x64

NOTE
This labs assumes that both PCs are running a 64 bit version of Windowson both the target and host. If that is not the
case, the best approach is to run the same "bitness" of tools on the host that the target is running. For example if the
target is running 32 bit Windows, run a 32 version of the debugger on the host. For more information, see Choosing the
32-Bit or 64-Bit Debugging Tools.

2. Locate these two files and copy them to a network share or thumb drive, so that they will be available on
the target computer.
kdnet.exe
VerifiedNICList.xml
3. On the target computer, open a Command Prompt window as Administrator. Enter this command to
validate that the NIC on the target PC is suported.

C:\KDNET>kdnet

Network debugging is supported on the following NICs:

busparams=0.25.0, Intel(R) 82579LM Gigabit Network Connection, KDNET is running on this NIC.kdnet.exe

4. Type this command to set the IP address of the host system. Use the actual IP address of the host system you
recorded instead of 169.182.1.1 that is shown in the sample output. Pick a unique port address for each
target/host pair that you work with, such as 50010.

C:\>kdnet 169.182.1.1 50010

Enabling network debugging on Intel(R) 82577LM Gigabit Network Connection.

Key=2steg4fzbj2sz.23418vzkd4ko3.1g34ou07z4pev.1sp3yo9yz874p

IMPORTANT
Before using BCDEdit to change boot information you may need to temporarily suspend Windows security features such
as BitLocker and Secure Boot on the test PC. Re-enable these security features when testing is complete and appropriately
manage the test PC, when the security features are disabled.
5. Type this command to confirm that the dbgsettings are set properly.

C:\> bcdedit /dbgsettings

busparams 0.25.0
key 2steg4fzbj2sz.23418vzkd4ko3.1g34ou07z4pev.1sp3yo9yz874p
debugtype NET
hostip 169.182.1.1
port 50010
dhcp Yes
The operation completed successfully.

Copy the auto generated unique key into a text file, to avoid having to type it in on the host PC. Copy the text file
with the key over to the host system.
Note Firewalls and debuggers
If you receive a pop-up message from the firewall, and you wish to use the debugger, check all three of the
boxes.

<- On the host system

1. On the host computer, open a Command Prompt window as Administrator. Change to the WinDbg.exe
directory. We will use the x64version of WinDbg.exe from the Windows Driver Kit (WDK) that was installed as
part of the Windows kit installation.

C:\> Cd C:\Program Files (x86)\Windows Kits\10\Debuggers\x64

2. Launch WinDbg with remote user debug using the following command. The value for the key and port
match what you set earlier using BCDEdit on the target.

C:\> WinDbg –k net:port=50010,key=2steg4fzbj2sz.23418vzkd4ko3.1g34ou07z4pev.1sp3yo9yz874p

->On the target system

Reboot the target system.
<-On the host system
In a minute or two, debug output should be displayed on the host system.

The Debugger Command window is the primary debugging information window in WinDbg. You can enter
debugger commands and view the command output in this window.
The Debugger Command window is split into two panes. You type commands in the smaller pane (the
command entry pane) at the bottom of the window and view the command output in the larger pane at the top
of the window.
In the command entry pane, use the up arrow and down arrow keys to scroll through the command history.
When a command appears, you can edit it or press ENTER to run the command.

Section 2: kernel-mode debugging commands and techniques

In Section 2, you will use debug commands to display information about the target system.
<- On the host system
Enable Debugger Markup Language (DML) with .prefer_dml
Some debug commands display text using Debugger Markup Language that you can select to quickly gather
more information.
1. Use Ctrl+Break (Scroll Lock) in WinDBg to break into the code running on the target system. It may take a bit
of time for the target system to respond.
2. Type the following command to enable DML in the Debugger Command window.
 0: kd> .prefer_dml 1
DML versions of commands on by default

Use .hh to get help

You can access reference command help using the .hh command.
3. Type the following command to view the command reference help for .prefer_dml .

0: kd> .hh .prefer_dml

The Debugger help file will display help for the .prefer_dml command.

Display the version of Windows on the target system

5. Display detailed version information on the target system by typing the ver target (Show Target
Computer Version) command in the WinDbg window.

0: kd> vertarget
Windows 10 Kernel Version 9926 MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 9926.0.amd64fre.fbl_awesome1501.150119-1648
Machine Name: ""
Kernel base = 0xfffff801`8d283000 PsLoadedModuleList = 0xfffff801`8d58aef0
Debug session time: Fri Feb 20 10:15:17.807 2015 (UTC - 8:00)
System Uptime: 0 days 01:31:58.931

List the loaded modules

6. You can verify that you are working with the right kernel-mode process by displaying the loaded modules by
typing the lm (List Loaded Modules) command in the WinDbg window.

0: Kd> lm
start end module name
fffff801`09200000 fffff801`0925f000 volmgrx (no symbols)
fffff801`09261000 fffff801`092de000 mcupdate_GenuineIntel (no symbols)
fffff801`092de000 fffff801`092ec000 werkernel (export symbols) werkernel.sys
fffff801`092ec000 fffff801`0934d000 CLFS (export symbols) CLFS.SYS
fffff801`0934d000 fffff801`0936f000 tm (export symbols) tm.sys
fffff801`0936f000 fffff801`09384000 PSHED (export symbols) PSHED.dll
fffff801`09384000 fffff801`0938e000 BOOTVID (export symbols) BOOTVID.dll
fffff801`0938e000 fffff801`093f7000 spaceport (no symbols)
fffff801`09400000 fffff801`094cf000 Wdf01000 (no symbols)
fffff801`094d9000 fffff801`09561000 CI (export symbols) CI.dll
...

Note Output that has been omitted is indicated with "… " in this lab.
Because we have yet to set the symbol path and loaded symbols, limited information is available in the
debugger.

Section 3: Download and build the Sysvad audio driver

In Section 3, you will download and build the Sysvad audio driver.
Typically, you would be working with your own driver code when you use WinDbg. To become familiar with
debugging audio drivers, the Sysvad virtual audio sample driver is used. This sample is used to illustrate how
you can single step through native kernel-mode code. This technique can be very valuable for debugging
complex kernel-mode code issues.
To download and build the Sysvad sample audio driver, perform the following steps.
1. Download and extract the Sysvad audio sample from GitHub
You can use a browser to view the Sysvad sample and Readme.md file here:
https://github.com/Microsoft/Windows-driver-samples/tree/master/audio/sysvad

This lab, shows how to download the universal driver samples in one zip file.
 a. Download the master.zip file to your local hard drive.
https://github.com/Microsoft/Windows-driver-samples/archive/master.zip
b. Select and hold (or right-click) Windows-driver-samples-master.zip, and choose Extract All . Specify a
new folder, or browse to an existing one that will store the extracted files. For example, you could specify
C:\WDK_Samples\ as the new folder into which the files are extracted.
c. After the files are extracted, navigate to the following subfolder.
C:\WDK_Samples\Sysvad
2. Open the driver solution in Visual Studio
In Visual Studio, select File > Open > Project/Solution... and navigate to the folder that contains the
extracted files (for example, C:\WDK_Samples\Sysvad). Double-click the Syvad solution file.
In Visual Studio locate the Solution Explorer. (If this is not already open, choose Solution Explorer from
the View menu.) In Solution Explorer, you can see one solution that has a number of projects.

3. Set the sample's configuration and platform

In Solution Explorer, select and hold (or right-click) Solution 'sysvad' (7 of 7 projects) , and choose
Configuration Manager . Make sure that the configuration and platform settings are the same for the
four projects. By default, the configuration is set to "Win10 Debug", and the platform is set to "Win64" for
all the projects. If you make any configuration and/or platform changes for one project, you must make
the same changes for the remaining three projects.
Note This lab assumes that 64 bit Windows is being used. If you are using 32 bit Windows, build the
driver for 32 bit.
4. Check driver signing
Locate the TabletAudioSample. Open the Sysvad driver’s property page and make sure Driver Signing
 > Sign Mode is set to Test Sign.
5. Build the sample using Visual Studio
In Visual Studio, select Build > Build Solution .
The build windows should display a message indicating that the build for all six projects succeeded.
6. Locate the built driver files
In File Explorer, navigate to the folder that contains the extracted files for the sample. For example, you
would navigate to C:\WDK_Samples\Sysvad, if that's the folder you specified earlier. Within that folder, the
location of the compiled driver files varies depending on the configuration and platform settings that you
selected in the Configuration Manager . For example, if you left the default settings unchanged, then
the compiled driver files will be saved to a folder named \x64\Debug for a 64-bit, debug build.
Navigate to the folder that contains the built files for the TabletAudioSample driver:
C:\WDK_Samples\Sysvad\TabletAudioSample\x64\Debug. The folder will contain the TabletAudioSample
.SYS driver, symbol pdp file and the inf file. You will also need to locate the DelayAPO, KWSApo and
KeywordDetectorContosoAdapter dlls and symbol files.
To install the driver, you will need the following files.

F IL E N A M E DESC RIP T IO N

TabletAudioSample.sys The driver file.

TabletAudioSample.pdb The driver symbol file.

tabletaudiosample.inf An information (INF) file that contains information

needed to install the driver.

KeywordDetectorContosoAdapter.dll A sample keyword detector.

KeywordDetectorContosoAdapter.pdb The sample keyword detector symbol file.

DelayAPO.dll A sample delay APO.

DelayAPO.pdb The delay APO symbol file.

KWSApo.dll A sample keyword spotter APO.

KWSApo.pdb The keyword spotter symbol file.

TabletAudioSample.cer The TabletAudioSample certificate file.

7. Locate a USB thumb drive or set up a network share to copy the built driver files from the host to the
target system.
In the next section, you will copy the code to the target system, and install and test the driver.

Section 4: Install the Sysvad audio driver sample on the target system
In Section 4, you will use devcon to install the Sysvad audio driver.
-> On the target system
The computer where you install the driver is called the target computer or the test computer. Typically, this is a
separate computer from the computer on which you develop and build the driver package. The computer where
you develop and build the driver is called the host computer.
The process of moving the driver package to the target computer and installing the driver is called deploying the
driver.
Before you deploy a driver, you must prepare the target computer by turning on test signing. After that you’re
ready to run the built driver sample on the target system.
To install the driver on the target system, perform the following steps.
1. Enable test signed drivers
To enable the ability to run test signed drivers:
a. Open Windows Settings.
b. In Update and Security , select Recover y .
c. Under Advanced star tup , select Restar t Now .
d. When the PC restarts, select Troubleshoot .
e. Then select Advanced options , Star tup Settings and then select Restar t .
f. Select Disable driver signature enforcement by pressing the F7 key.
g. The PC will start with the new values in place.
2. -> On the target system
Install the driver
The following instructions show you how to install and test the sample driver.
The INF file required for installing this driver is TabletAudioSample.inf. On the target computer, open a
Command Prompt window as Administrator. Navigate to your driver package folder, right-click the
TabletAudioSample.inf file, and then select Install .
A dialog box will appear indicating that the test driver is an unsigned driver. Select Install this driver
anyway to proceed.

TIP
If you have any issues with the installation, check the following file for more information.
%windir%\inf\setupapi.dev.log

For more detailed instructions, see Configuring a Computer for Driver Deployment, Testing, and
 Debugging.
The INF file contains the hardware ID for installing the tabletaudiosample.sys. For the Syvad sample, the
hardware ID is: root\sysvad_TabletAudioSample
3. Examine the driver in Device Manager
On the target computer, in a Command Prompt window, enter devmgmt to open Device Manager. In
Device Manager, on the View menu, select Devices by type .
In the device tree, locate Virtual Audio Device (WDM) - Tablet Sample in the Audio Device node. This is
typically under the Sound, video and game controllers node. Confirm that it is installed and active.
Highlight the driver for the actual hardware on the PC in Device Manager. Then select and hold (or right-
click) the driver and select disable to disable the driver.
Confirm in Device Manager that audio hardware driver, displays the a down arrow, indicating that it is
disabled.

After successfully installing the sample driver, you're now ready to test it.
Test the Sysvad audio driver
1. On the target computer, in a Command Prompt window, enter devmgmt to open Device Manager. In
Device Manager, on the View menu, select Devices by type . In the device tree, locate Virtual Audio
Device (WDM) - Tablet Sample.
2. Open Control Panel and navigate to Hardware and Sound > Manage audio devices . In the Sound
dialog box, select the speaker icon labeled as Virtual Audio Device (WDM) - Tablet Sample, and then
select Set Default , but do not select OK . This will keep the Sound dialog box open.
3. Locate an MP3 or other audio file on the target computer and double-click to play it. Then in the Sound
dialog box, verify that there is activity in the volume level indicator associated with the Virtual Audio
Device (WDM) - Tablet Sample driver.

Section 5: Use WinDbg to display information about the driver

In Section 5, you will set the symbol path and use kernel debugger commands to display information about the
Sysvad sample driver.
Symbols allow for WinDbg to display additional information such as variable names, that can be invaluable
when debugging. WinDbg uses the Microsoft Visual Studio debug symbol formats for source-level debugging. It
can access any symbol or variable from a module that has PDB symbol files.
To load the debugger, perform the following steps.
<-On the host system
1. If you closed the debugger, open it again using the following command in the administrator command
prompt window. Replace the key and port with what you previously configured.
 C:\> WinDbg –k net:port=50010,key=2steg4fzbj2sz.23418vzkd4ko3.1g34ou07z4pev.1sp3yo9yz874p

2. Use Ctrl+Break (Scroll Lock) to break into the code running on the target system.
Set the symbol path
1. To set the symbols path to the Microsoft symbol server in the WinDbg environment, use the .symfix
command.

0: kd> .symfix

2. To add your local symbol location to use your local symbols, add the path using .sympath+ and then
.reload /f .

0: kd> .sympath+ C:\WDK_Samples\Sysvad

0: kd> .reload /f

Note The .reload command with the /f force option deletes all symbol information for the specified
module and reloads the symbols. In some cases, this command also reloads or unloads the module itself.
Note You must load the proper symbols to use advanced functionality that WinDbg provides. If you do not
have symbols properly configured, you will receive messages indicating that symbols are not available when
you attempt to use functionality that is dependent on symbols.

0:000> dv
Unable to enumerate locals, HRESULT 0x80004005
Private symbols (symbols.pri) are required for locals.
Type “.hh dbgerr005” for details.

Note Symbol ser vers

There are a number of approaches that can be used to work with symbols. In many situations, you can configure
the PC to access symbols from a symbol server that Microsoft provides when they are needed. This walkthrough
assumes that this approach will be used. If the symbols in your environment are in a different location, modify
the steps to use that location. For additional information, see Symbol Stores and Symbol Servers.
Note Understand source code symbol requirements
To perform source debugging, you must build a checked (debug) version of your binaries. The compiler will
create symbol files (.pdb files). These symbol files will show the debugger how the binary instructions
correspond to the source lines. The actual source files themselves must also be accessible to the debugger.
The symbol files do not contain the text of the source code. For debugging, it is best if the linker does not
optimize your code. Source debugging and access to local variables are more difficult, and sometimes nearly
impossible, if the code has been optimized. If you are having problems viewing local variables or source lines,
set the following build options.
set COMPILE_DEBUG=1
set ENABLE_OPTIMIZER=0
1. Type the following in the command area of the debugger to display information about the Sysvad driver.
 0: kd> lm m tabletaudiosample v
Browse full module list
start end module name
fffff801`14b40000 fffff801`14b86000 tabletaudiosample (private pdb symbols)
C:\Debuggers\sym\TabletAudioSample.pdb\E992C4803EBE48C7B23DC1596495CE181\TabletAudioSample.pdb
Loaded symbol image file: tabletaudiosample.sys
Image path: \SystemRoot\system32\drivers\tabletaudiosample.sys
Image name: tabletaudiosample.sys
Browse all global symbols functions data
Timestamp: Thu Dec 10 12:20:26 2015 (5669DE8A)
CheckSum: 0004891E
...

For more information, see lm .

2. Select the Browse all global symbols link in the debug output to display information about items
symbols that start with the letter a.
3. Because DML is enabled, some elements of the output are hot links that you can select. Select the data
link in the debug output to display information about items symbols that start with the letter a.

0: kd> x /D /f tabletaudiosample!a*
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

fffff806`9adb1000 tabletaudiosample!AddDevice (struct _DRIVER_OBJECT *, struct _DEVICE_OBJECT *)

For information, see x (Examine Symbols) .

4. The !lmi extension displays detailed information about a module. Type !lmi tabletaudiosample . Your
output should be similar to the text shown below.

0: kd> !lmi tabletaudiosample

Loaded Module Info: [tabletaudiosample]
Module: tabletaudiosample
Base Address: fffff8069ad90000
Image Name: tabletaudiosample.sys
Machine Type: 34404 (X64)
Time Stamp: 58ebe848 Mon Apr 10 13:17:12 2017
Size: 48000
CheckSum: 42df7
Characteristics: 22
Debug Data Dirs: Type Size VA Pointer
CODEVIEW a7, e5f4, d1f4 RSDS - GUID: {5395F0C5-AE50-4C56-AD31-DD5473BD318F}
Age: 1, Pdb: C:\Windows-driver-samples-
master\audio\sysvad\TabletAudioSample\x64\Debug\TabletAudioSample.pdb
?? 250, e69c, d29c [Data not mapped]
Image Type: MEMORY - Image read successfully from loaded memory.
Symbol Type: PDB - Symbols loaded successfully from image header.
C:\Program Files (x86)\Windows
Kits\10\Debuggers\x64\sym\TabletAudioSample.pdb\5395F0C5AE504C56AD31DD5473BD318F1\TabletAudioSample.p
db
Compiler: Resource - front end [0.0 bld 0] - back end [14.0 bld 24210]
Load Report: private symbols & lines, not source indexed
C:\Program Files (x86)\Windows
Kits\10\Debuggers\x64\sym\TabletAudioSample.pdb\5395F0C5AE504C56AD31DD5473BD318F1\TabletAudioSample.p
db

5. Use the !dh extension to display header information as shown below.

 0: kd> !dh tabletaudiosample

File Type: EXECUTABLE IMAGE

FILE HEADER VALUES
8664 machine (X64)
9 number of sections
5669DE8A time date stamp Thu Dec 10 12:20:26 2015

0 file pointer to symbol table

0 number of symbols
F0 size of optional header
22 characteristics
Executable
App can handle >2gb addresses
...

Section 6: Displaying Plug and Play device tree information

In Section 6, you will display information about the Sysvad sample device driver and where it lives in the Plug
and Play device tree.
Information about the device driver in the Plug and Play device tree can be useful for troubleshooting. For
example, if a device driver is not resident in the device tree, there may an issue with the installation of the device
driver.
For more information about the device node debug extension, see !devnode .
<-On the host system
1. To see all the device nodes in the Plug and Play device tree, enter the !devnode 0 1 command. This
command can take a minute or two to run. During that time, "*Busy" will be displayed in the status area
of WinDbg.

0: kd> !devnode 0 1
Dumping IopRootDeviceNode (= 0xffffe0005a3a8d30)
DevNode 0xffffe0005a3a8d30 for PDO 0xffffe0005a3a9e50
InstancePath is "HTREE\ROOT\0"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
DevNode 0xffffe0005a3a3d30 for PDO 0xffffe0005a3a4e50
InstancePath is "ROOT\volmgr\0000"
ServiceName is "volmgr"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
DevNode 0xffffe0005a324560 for PDO 0xffffe0005bd95ca0…
...

2. Use Ctrl+F to search in the output that is generated to look for the name of the device driver, sysvad.

A device node entry with a name of sysvad_TabletAudioSample will be present in the !devnode output for
Syvad.
 DevNode 0xffffe00086e68190 for PDO 0xffffe00089c575a0
InstancePath is "ROOT\sysvad_TabletAudioSample\0000"
ServiceName is "sysvad_tabletaudiosample"
State = DeviceNodeStarted (0x308)
...

Note that the PDO address and the DevNode address are displayed.
3. Use the !devnode 0 1 sysvad_TabletAudioSample command to display Plug and Play information
associated with our Sysvad device driver.

0: kd> !devnode 0 1 sysvad_TabletAudioSample

Dumping IopRootDeviceNode (= 0xffffe00082df8d30)
DevNode 0xffffe00086e68190 for PDO 0xffffe00089c575a0
InstancePath is "ROOT\sysvad_TabletAudioSample\0000"
ServiceName is "sysvad_tabletaudiosample"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
DevNode 0xffffe000897fb650 for PDO 0xffffe00089927e30
InstancePath is "SWD\MMDEVAPI\{0.0.0.00000000}.{64097438-cdc0-4007-a19e-62e789062e20}"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeStartPostWork (0x307)
DevNode 0xffffe00086d2f5f0 for PDO 0xffffe00089939ae0
InstancePath is "SWD\MMDEVAPI\{0.0.0.00000000}.{78880f4e-9571-44a4-a9df-960bde446487}"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeStartPostWork (0x307)
DevNode 0xffffe00089759bb0 for PDO 0xffffe000875aa060
InstancePath is "SWD\MMDEVAPI\{0.0.0.00000000}.{7cad07f2-d0a0-4b9b-8100-8dc735e9c447}"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeStartPostWork (0x307)
DevNode 0xffffe00087735010 for PDO 0xffffe000872068c0
InstancePath is "SWD\MMDEVAPI\{0.0.0.00000000}.{fc38551b-e69f-4b86-9661-ae6da78bc3c6}"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeStartPostWork (0x307)
DevNode 0xffffe00088457670 for PDO 0xffffe0008562b830
InstancePath is "SWD\MMDEVAPI\{0.0.1.00000000}.{0894b831-c9fe-4c56-86a6-092380fc5628}"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeStartPostWork (0x307)
DevNode 0xffffe000893dbb70 for PDO 0xffffe00089d68060
InstancePath is "SWD\MMDEVAPI\{0.0.1.00000000}.{15eb6b5c-aa54-47b8-959a-0cff2c1500db}"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeStartPostWork (0x307)
DevNode 0xffffe00088e6f250 for PDO 0xffffe00089f6e990
InstancePath is "SWD\MMDEVAPI\{0.0.1.00000000}.{778c07f0-af9f-43f2-8b8d-490024f87239}"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeStartPostWork (0x307)
DevNode 0xffffe000862eb4b0 for PDO 0xffffe000884443a0
InstancePath is "SWD\MMDEVAPI\{0.0.1.00000000}.{e4b72c7c-be50-45df-94f5-0f2922b85983}"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeStartPostWork (0x307)

4. The output displayed in the previous command includes the PDO associated with the running instance of
our driver, in this example it is 0xffffe00089c575a0. Enter the !devobj <PDO address> command to
display Plug and Play information associated with the Sysvad device driver. Use the PDO address that
!devnode displays on your PC, not the one shown here.
 0: kd> !devobj 0xffffe00089c575a0
Device object (ffffe00089c575a0) is for:
0000004e \Driver\PnpManager DriverObject ffffe00082d47e60
Current Irp 00000000 RefCount 65 Type 0000001d Flags 00001040
SecurityDescriptor ffffc102b0f6d171 DevExt 00000000 DevObjExt ffffe00089c576f0 DevNode
ffffe00086e68190
ExtensionFlags (0000000000)
Characteristics (0x00000180) FILE_AUTOGENERATED_DEVICE_NAME, FILE_DEVICE_SECURE_OPEN
AttachedDevice (Upper) ffffe00088386a50 \Driver\sysvad_tabletaudiosample
Device queue is not busy.

5. The output displayed in the !devobj command includes the name of the attached device:
\Driver\sysvad_tabletaudiosample. Use the !dr vobj command with a bit mask of 2, to display
information associated with the attached device.

0: kd> !drvobj \Driver\sysvad_tabletaudiosample 2

Driver object (ffffe0008834f670) is for:
\Driver\sysvad_tabletaudiosample
DriverEntry: fffff80114b45310 tabletaudiosample!FxDriverEntry
DriverStartIo: 00000000
DriverUnload: fffff80114b5fea0 tabletaudiosample!DriverUnload
AddDevice: fffff80114b5f000 tabletaudiosample!AddDevice

Dispatch routines:
[00] IRP_MJ_CREATE fffff80117b49a20 portcls!DispatchCreate
[01] IRP_MJ_CREATE_NAMED_PIPE fffff8015a949a00 nt!IopInvalidDeviceRequest
[02] IRP_MJ_CLOSE fffff80115e26f90 ks!DispatchCleanup
[03] IRP_MJ_READ fffff80115e32710 ks!DispatchRead
[04] IRP_MJ_WRITE fffff80115e327e0 ks!DispatchWrite
[05] IRP_MJ_QUERY_INFORMATION fffff8015a949a00 nt!IopInvalidDeviceRequest
[06] IRP_MJ_SET_INFORMATION fffff8015a949a00 nt!IopInvalidDeviceRequest
[07] IRP_MJ_QUERY_EA fffff8015a949a00 nt!IopInvalidDeviceRequest
[08] IRP_MJ_SET_EA fffff8015a949a00 nt!IopInvalidDeviceRequest
[09] IRP_MJ_FLUSH_BUFFERS fffff80115e32640 ks!DispatchFlush
[0a] IRP_MJ_QUERY_VOLUME_INFORMATION fffff8015a949a00 nt!IopInvalidDeviceRequest
[0b] IRP_MJ_SET_VOLUME_INFORMATION fffff8015a949a00 nt!IopInvalidDeviceRequest
[0c] IRP_MJ_DIRECTORY_CONTROL fffff8015a949a00 nt!IopInvalidDeviceRequest
[0d] IRP_MJ_FILE_SYSTEM_CONTROL fffff8015a949a00 nt!IopInvalidDeviceRequest
[0e] IRP_MJ_DEVICE_CONTROL fffff80115e27480 ks!DispatchDeviceIoControl
[0f] IRP_MJ_INTERNAL_DEVICE_CONTROL fffff8015a949a00 nt!IopInvalidDeviceRequest
[10] IRP_MJ_SHUTDOWN fffff8015a949a00 nt!IopInvalidDeviceRequest
[11] IRP_MJ_LOCK_CONTROL fffff8015a949a00 nt!IopInvalidDeviceRequest
[12] IRP_MJ_CLEANUP fffff8015a949a00 nt!IopInvalidDeviceRequest
[13] IRP_MJ_CREATE_MAILSLOT fffff8015a949a00 nt!IopInvalidDeviceRequest
[14] IRP_MJ_QUERY_SECURITY fffff80115e326a0 ks!DispatchQuerySecurity
[15] IRP_MJ_SET_SECURITY fffff80115e32770 ks!DispatchSetSecurity
[16] IRP_MJ_POWER fffff80117b3dce0 portcls!DispatchPower
[17] IRP_MJ_SYSTEM_CONTROL fffff80117b13d30 portcls!PcWmiSystemControl
[18] IRP_MJ_DEVICE_CHANGE fffff8015a949a00 nt!IopInvalidDeviceRequest
[19] IRP_MJ_QUERY_QUOTA fffff8015a949a00 nt!IopInvalidDeviceRequest
[1a] IRP_MJ_SET_QUOTA fffff8015a949a00 nt!IopInvalidDeviceRequest
[1b] IRP_MJ_PNP fffff80114b5f7d0 tabletaudiosample!PnpHandler

6. Enter the !devstack <PDO address> command to display Plug and Play information associated with the
device driver. The output displayed in the !devnode 0 1 command includes the PDO address associated
with the running instance of our driver. In this example it is 0xffffe00089c575a0. Use the PDO address
that !devnode displays on your PC, not the one shown below.
 0: kd> !devstack 0xffffe00089c575a0
!DevObj !DrvObj !DevExt ObjectName
ffffe00088d212e0 \Driver\ksthunk ffffe00088d21430 0000007b
ffffe00088386a50 \Driver\sysvad_tabletaudiosampleffffe00088386ba0 0000007a
> ffffe00089c575a0 \Driver\PnpManager 00000000 0000004e
!DevNode ffffe00086e68190 :
DeviceInst is "ROOT\sysvad_TabletAudioSample\0000"
ServiceName is "sysvad_tabletaudiosample"

The output shows that we have a farily simple device driver stack. The sysvad_TabletAudioSample driver is a
child of the PnPManager node. The PnPManager is a root node.
This diagram shows a more complex device node tree.

Note For more information about more complex driver stacks, see Driver stacks and Device nodes and device
stacks.

Section 7: Working with breakpoints

In Section 7, you will work with breakpoints to stop code execution at specific points.
Setting breakpoints using commands
Breakpoints are used to stop code execution at a particular line of code. You can then step forward in the code
from that point, to debug that specific section of code.
To set a breakpoint using a debug command, use one of the following b commands.

bp Sets a breakpoint that will be active until the module it is

in is unloaded.
 bu Sets a breakpoint that is unresolved when the module is
unloaded and re-enables when the module reloads.

bm Sets a breakpoint for a symbol. This command will use

bu or bp appropriately and allows wildcards * to be used
to set breakpoints on every symbols that matches (like
all methods in a class).

1. Use the WinDbg UI to confirm that Debug > Source Mode is enabled in the current WinDbg session.
2. Add your local code location to the source path by typing the following command.

.sympath+ C:\WDK_Samples\Sysvad

3. Add your local symbol location to the symbol path by typing the following command.

.sympath+ C:\WDK_Samples\Sysvad

4. Set the debug mask

As you are working with a driver it can be handy to see all of the messages that it may display. Type the
following to change the default debug bit mask so that all debug messages from the target system will be
displayed in the debugger.

0: kd> ed nt!Kd_DEFAULT_MASK 0xFFFFFFFF

5. Set the breakpoint with the bm command using the name of the driver, followed by the function name
(AddDevice) where you want to set the breakpoint, separated by an exclamation mark.

0: kd> bm tabletaudiosample!AddDevice
breakpoint 1 redefined
1: fffff801`14b5f000 @!"tabletaudiosample!AddDevice"

You can use different syntax in conjunction with setting variables like <module>!<symbol>, <class>::
<method>,‘<file.cpp>:<line number>’, or skip a number of times <condition> <#>. For more
information, see Using Breakpoints.
6. List the current breakpoints to confirm that the breakpoint was set by typing the bl command.

0: kd> bl
1 e fffff801`14b5f000 0001 (0001) tabletaudiosample!AddDevice

7. Restart code execution on the target system by typing the go command g .

8. ->On the target system
In Windows, open Device Manager by using the icon or by entering mmc devmgmt.msc . In Device
Manager expand the Sound, video and game controllers node. Select and hold (or right-click) the
virtual audio driver entry and select Disable from the menu.
9. Select and hold (or right-click) the virtual audio driver entry again and select Enable from the menu.
10. <- On the host system
 This should cause Windows to reload the driver, which calls AddDevice. This will cause the AddDevice
debug breakpoint to fire and the execution of the driver code on the target system should halt.

Breakpoint 1 hit
tabletaudiosample!AddDevice:
fffff801`14baf000 4889542410 mov qword ptr [rsp+10h],rdx

If your source path is set properly, you should stop at the AddDevice routine in adapter.cpp

{
PAGED_CODE();

NTSTATUS ntStatus;
ULONG maxObjects;

DPF(D_TERSE, ("[AddDevice]"));

maxObjects = g_MaxMiniports;

#ifdef SYSVAD_BTH_BYPASS
//
// Allow three (3) Bluetooth hands-free profile devices.
//
maxObjects += g_MaxBthHfpMiniports * 3;
#endif // SYSVAD_BTH_BYPASS

// Tell the class driver to add the device.

//
ntStatus =
PcAddAdapterDevice
(
DriverObject,
PhysicalDeviceObject,
PCPFNSTARTDEVICE(StartDevice),
maxObjects,
0
);
return ntStatus;
} // AddDevice

11. Step line-by-line through the code by typing the p command or pressing F10. You can step forward out
of the sysvad AddDevice code to PpvUtilCall, PnpCallAddDevice and then to the PipCallDriverAddDevice
Windows code. You can provide a number to the p command to step forward multiple lines, for example
p 5.
12. When you are done stepping through the code, use the go command g to restart execution on the target
system.
Setting memor y access breakpoints
You can also set breakpoints that fire when a memory location is accessed. Use the ba (break on access)
command, with the following syntax.

ba <access> <size> <address> {options}

O P T IO N DESC RIP T IO N
 O P T IO N DESC RIP T IO N

e execute (when CPU fetches an instruction from the

address)

r read/write (when CPU reads or writes to the address)

w write (when the CPU writes to the address)

Note that you can only set four data breakpoints at any given time and it is up to you to make sure that you are
aligning your data correctly or you won’t trigger the breakpoint (words must end in addresses divisible by 2,
dwords must be divisible by 4, and quadwords by 0 or 8)
For example, to set a read/write breakpoint on a specific memory address, use a command like this.

ba r 4 fffff800`7bc9eff0

Modifying breakpoint state

You can modify existing breakpoints by using the following commands.

bl Lists breakpoints.

bc Clears a breakpoint from the list. Use bc * to clear all

breakpoints.

bd Disables a breakpoint. Use bd * to disable all

breakpoints.

be Enables a breakpoint. Use be * to enable all breakpoints.

Alternatively, you can also modify breakpoints by selecting edit > breakpoints . Note that the breakpoint dialog
box only works with existing breakpoints. New breakpoints must be set from the command line.
Set a breakpoint on MixerVolume
Different parts of the audio driver code is called to respond to various events, after the device driver is loaded. In
the next section, we set a breakpoint that will fire when the user adjusts the volume control for the virtual audio
driver.
To set a breakpoint on MixerVolume, perform the following steps.
1. <- On the host system
To locate the method that changes the volume, use the x command to list the symbols in
CAdapterCommon, that contain the string volume.
 kd> x tabletaudiosample!CAdapterCommon::*
...
fffff800`7bce26a0 tabletaudiosample!CAdapterCommon::MixerVolumeWrite (unsigned long, unsigned long,
long)
…

Use CTRL+F to search upward in the output for volume and locate the MixerVolumeWrite method.
2. Clear the previous breakpoints using bc *.
3. Set a symbol breakpoint on the CAdapterCommon::MixerVolumeWrite routine using the following
command.

kd> bm tabletaudiosample!CAdapterCommon::MixerVolumeWrite
1: fffff801`177b26a0 @!"tabletaudiosample!CAdapterCommon::MixerVolumeWrite"

4. List the breakpoints to confirm that the breakpoint is set properly.

kd> bl
1 e fffff801`177b26a0 [c:\WDK_Samples\audio\sysvad\common.cpp @ 1668] 0001 (0001)
tabletaudiosample!CAdapterCommon::MixerVolumeWrite

5. Restart code execution on the target system by typing the go command g .

6. In Control Panel select Hardware and Sound >Sound . Select and hold (or right-click) Sink
Description Sample and select Proper ties . Select the Levels tab. Adjust the slider volume.
7. This should cause the SetMixerVolume debug breakpoint to fire and execution of the driver code on the
target system should halt.

kd> g
Breakpoint 1 hit
tabletaudiosample!CAdapterCommon::MixerVolumeWrite:
fffff801`177b26a0 44894c2420 mov dword ptr [rsp+20h],r9d

You should stop at this line in common.cpp

{
if (m_pHW)
{
m_pHW->SetMixerVolume(Index, Channel, Value);
}
} // MixerVolumeWrite

8. Use the dv command to display the current variables and their values. More information on variables is
provided in the next section of this lab.

2: kd> dv
this = 0x00000000`00000010
ulNode = 0x344
ulChannel = 0x210a45f8
lVolume = 0n24

9. Press F10 to single step through the code.

10. Press F5 to finish the execution of the MixerVolumeWrite code.
Summar y - Stepping through code from the Debugger Command window
The following are the commands that you can use to step through your code (with the associated keyboard
short cuts shown in parentheses).
Break in (Ctrl+Break) - This command will interrupt a system as long as the system is running and is in
communication with WinDbg (the sequence in the Kernel Debugger is Ctrl+C).
Step over (F10) – This command causes code execution to proceed one statement or one instruction at a
time. If a call is encountered, code execution passes over the call without entering the called routine. (If
the programming language is C or C++ and WinDbg is in source mode, source mode can be turned on
or off using Debug >Source Mode ).
Step in (F11) – This command is like step-over, except that the execution of a call does go into the called
routine.
Step out (Shift+F11) – This command causes execution to run to and exit from the current routine
(current place in the call stack). This is useful if you've seen enough of the routine.
Run to cursor (F7 or Ctrl+F10) – Place the cursor in a source or disassembly window where you want the
execution to break, then press F7; code execution will run to that point. Note that if the flow of code
execution does not reach the point indicated by the cursor (e.g., an IF statement isn't executed), WinDbg
would not break, because the code execution did not reach the indicated point.
Run (F5) – Run until a breakpoint is encountered or an event like a bug check occurs.
Advanced options
Set instruction to the current line (Ctrl+Shift+I) – In a source window, you can place your cursor on a line,
enter this keyboard shortcut, and code execution will start from that point as soon as you let it proceed
(for example using F5 or F10). This is handy if you want to retry a sequence, but it requires some care. For
example, registers and variables are not set to what they would be if code execution had reached that line
naturally.
Direct setting of the eip register -- You can put a value into the eip register, and as soon as you press F5
(or F10, F11, etc.), execution commences from that address. This is similar to setting instruction to the
cursor-designated current line, except that you specify the address of an assembly instruction.
It can be easier to step through UI rather than from the command line so this method is recommended. If
necessary, the following commands can be used to step through a source file at the command line:
.lines - Enable source line information.
bp main - Set the initial breakpoint at the beginning of your module.
l+t - Stepping will be done by source line.
Select Debug >Source Mode to enter source mode; the L+t command is not sufficient.
l+s - Source lines will be displayed at prompt.
g - Run program until "main" is entered.
p - Execute one source line.
For more information, see Source Code Debugging in WinDbg in the debugging reference documentation.
Set breakpoints in code
You can set a breakpoint in code by adding the DebugBreak() statement and rebuilding the project and re-
installing the driver. This breakpoint will fire each time the driver is enabled, so it would be a techniques to be
used in the early development stages, not in production code. This technique is not as flexible as dynamically
setting breakpoints using the breakpoint commands.
Tip: You may want to keep a copy of the Sysvad driver with out the breakpoint added for further lab work.
1. Set a break to occur each time the AddDevice method is run by adding the DebugBreak() statement to
the sample code.

...
// Insert the DebugBreak() statment before the PcAddAdapterDevice is called.
//

DebugBreak()

// Tell the class driver to add the device.

//
ntStatus =
PcAddAdapterDevice
(
DriverObject,
PhysicalDeviceObject,
PCPFNSTARTDEVICE(StartDevice),
maxObjects,
0
);

return ntStatus;
} // AddDevice

2. Follow all of the steps previously described to rebuild the driver in Microsoft Visual Studio and re-install it
to the target machine. Be sure to uninstall the existing driver before installing the updated driver.
3. Clear any previous breakpoints and make sure that the debugger is attached to the target PC.
4. When the code runs and reaches the DebugBreak statement, execution will stop and a message will be
displayed.

KERNELBASE!DebugBreak:
77b3b770 defe __debugbreak

Section 8: Display variables

In Section 8, you will use debugger commands to display variables.
It can be useful to examine variables as the code executes to confirm that the code is working as expected. This
labs examines variables as the audio driver produces sound.
1. Use the dv command to examine the locale variables associated with the
tabletaudiosample!CMiniportWaveRT::New*.

kd> dv tabletaudiosample!CMiniportWaveRT::New*

2. Clear the previous breakpoints

bc *

3. Set a symbol breakpoint on the CMiniportWaveCyclicStreamMSVAD routines using the following

 command.

0: kd> bm tabletaudiosample!CMiniportWaveRT::NewStream
1: fffff801`177dffc0 @!"tabletaudiosample!CMiniportWaveRT::NewStream"

4. Restart code execution on the target system by typing the go command g .

5. -> On the target system
Locate a small media file (such as Windows notification sound file with a .wav file extension) and select
the file to play it. For example you can use Ring05.wav located in the Windows\Media directory.
6. <- On the host system
When the media file is played, the breakpoint should fire, and execution of the driver code on the target
system should halt.

Breakpoint 1 hit
tabletaudiosample!CMiniportWaveRT::NewStream:
fffff801`177dffc0 44894c2420 mov dword ptr [rsp+20h],r9d

The source code Window should be highlighting the brace on the entrance to the NewStream function.

/*++

Routine Description:

The NewStream function creates a new instance of a logical stream

associated with a specified physical channel. Callers of NewStream should
run at IRQL PASSIVE_LEVEL.

Arguments:

OutStream -

OuterUnknown -

Pin -

Capture -

DataFormat -

Return Value:

NT status code.

--*/
{

...

7. Local variables
You can display the names and values of all local variables for a given frame by typing the dv command.
 0: kd> dv
this = 0xffffe000`4436f8e0
OutStream = 0xffffe000`49d2f130
OuterUnknown = 0xffffe000`4436fa30
Pin = 0
Capture = 0x01 '
DataFormat = 0xffffe000`44227790
signalProcessingMode = {487E9220-E000-FFFF-30F1-D24900E0FFFF}
ntStatus = 0n1055
stream = 0x00000000`00000200

8. Use DML to Display Variables

To use DML to explore variables, select the underlined elements. The select action builds a dx (Display
NatVis Expression) command that allows you to drill down on nested data structures.

0: kd> dx -r1 (*((tabletaudiosample!CMiniportWaveRT *)0xffffe001d10b8380))

(*((tabletaudiosample!CMiniportWaveRT *)0xffffe001d10b8380)) : [Type: CMiniportWaveRT]
[+0x020] m_lRefCount : 0
[+0x028] m_pUnknownOuter : 0xffffe001d1477e50 : [Type: IUnknown *]
[+0x030] m_ulLoopbackAllocated : 0x2050
[+0x034] m_ulSystemAllocated : 0x180
[+0x038] m_ulOffloadAllocated : 0x0
[+0x03c] m_dwCaptureAllocatedModes : 0x0

0: kd> dx -r1 (*((tabletaudiosample!_GUID *)0xffffd001c8acd348))

(*((tabletaudiosample!_GUID *)0xffffd001c8acd348)) : {487E9220-E000-FFFF-30F1-D24900E0FFFF} [Type:
_GUID]
[<Raw View>]

0: kd> dx -r1 -n (*((tabletaudiosample!_GUID *)0xffffd001c8acd348))

(*((tabletaudiosample!_GUID *)0xffffd001c8acd348)) : [Type: _GUID]
[+0x000] Data1 : 0x487e9220
[+0x004] Data2 : 0xe000
[+0x006] Data3 : 0xffff
[+0x008] Data4 : [Type: unsigned char [8]]

0: kd> dx -r1 -n (*((tabletaudiosample!unsigned char (*)[8])0xffffd001c8acd350))

(*((tabletaudiosample!unsigned char (*)[8])0xffffd001c8acd350)) : [Type: unsigned char [8]]
[0] : 0x30
[1] : 0xf1
[2] : 0xd2
[3] : 0x49
[4] : 0x0
[5] : 0xe0
[6] : 0xff
[7] : 0xff

9. Global variables
You can find the memory location of a global variable by typing ? <variable name> .

0: kd> ? signalProcessingMode
Evaluate expression: -52768896396472 = ffffd001`c8acd348

10. This returns the memory location of the variable, in this case ffffd001`c8acd348. You can view the
contents of the memory location by dumping the value of that location typing the dd command using
the memory location returned by the previous command.
 0: kd> dd ffffd001`c8acd348
ffffd001`c8acd348 487e9220 ffffe000 49d2f130 ffffe000
ffffd001`c8acd358 4837c468 ffffe000 18221570 ffffc000
ffffd001`c8acd368 4436f8e0 ffffe000 487e9220 ffffe000
ffffd001`c8acd378 18ab145b fffff801 4837c420 ffffe000
ffffd001`c8acd388 4436f8e0 ffffe000 49d2f130 ffffe000
ffffd001`c8acd398 4436fa30 ffffe000 00000000 00000000
ffffd001`c8acd3a8 00000001 00000000 44227790 ffffe000
ffffd001`c8acd3b8 18adc7f9 fffff801 495972a0 ffffe000

11. You can also use variable names with the dd command.

0: kd> dd signalProcessingMode
ffffd001`c8acd348 487e9220 ffffe000 49d2f130 ffffe000
ffffd001`c8acd358 4837c468 ffffe000 18221570 ffffc000
ffffd001`c8acd368 4436f8e0 ffffe000 487e9220 ffffe000
ffffd001`c8acd378 18ab145b fffff801 4837c420 ffffe000
ffffd001`c8acd388 4436f8e0 ffffe000 49d2f130 ffffe000
ffffd001`c8acd398 4436fa30 ffffe000 00000000 00000000
ffffd001`c8acd3a8 00000001 00000000 44227790 ffffe000
ffffd001`c8acd3b8 18adc7f9 fffff801 495972a0 ffffe000

12. Display variables

Use the View > Locals menu item to display local variables. This interface also provides this ability to
drill down on more complex data structures.

13. Use p or F10 to step forward about 10 lines in the code until you are highlighting the ntStatus =
IsFormatSupported(Pin, Capture, DataFormat); line of code.
 PAGED_CODE();

ASSERT(OutStream);
ASSERT(DataFormat);

DPF_ENTER(("[CMiniportWaveRT::NewStream]"));

NTSTATUS ntStatus = STATUS_SUCCESS;

PCMiniportWaveRTStream stream = NULL;
GUID signalProcessingMode = AUDIO_SIGNALPROCESSINGMODE_DEFAULT;

*OutStream = NULL;

//
// If the data format attributes were specified, extract them.
//
if ( DataFormat->Flags & KSDATAFORMAT_ATTRIBUTES )
{
// The attributes are aligned (QWORD alignment) after the data format
PKSMULTIPLE_ITEM attributes = (PKSMULTIPLE_ITEM) (((PBYTE)DataFormat) + ((DataFormat-
>FormatSize + FILE_QUAD_ALIGNMENT) & ~FILE_QUAD_ALIGNMENT));
ntStatus = GetAttributesFromAttributeList(attributes, attributes->Size,
&signalProcessingMode);
}

// Check if we have enough streams.

//
if (NT_SUCCESS(ntStatus))
{
ntStatus = ValidateStreamCreate(Pin, Capture, signalProcessingMode);
}

// Determine if the format is valid.

//
if (NT_SUCCESS(ntStatus))
{
ntStatus = IsFormatSupported(Pin, Capture, DataFormat);
}

...

14. Use the dv command to display the names and values of all local variables for a given frame. Note that,
as expected, the values are different from the last time we ran this command, as additional code has been
run that changes the local variables and some variables are now not in the current frame or their values
have changed.

2: kd> dv
this = 0xffffe001`d1182000
OutStream = 0xffffe001`d4776d20
OuterUnknown = 0xffffe001`d4776bc8
Pin = 0
Capture = 0x00 '
DataFormat = 0xffffe001`cd7609b0
signalProcessingMode = {4780004E-7133-41D8-8C74-660DADD2C0EE}
ntStatus = 0n0
stream = 0x00000000`00000000

Section 9: View call stacks

In Section 9, you will view call stacks to examine caller/calle code.
The call stack is the chain of function calls that have led to the current location of the program counter. The top
function on the call stack is the current function, and the next function is the function that called the current
function, and so on.
To display the call stack, use the k* commands:

kb Displays the stack and first three parameters.

kp Displays the stacks and the full list of parameters.

kn Allows you to see the stack with the frame information

next to it.

If you want to keep the call stack available, you can select View > Call stack to view it. Select the columns at the
top of the window to toggle the display of additional information.

This output shows the call stack while debugging the sample adapter code in a break state.
 0: kd> kb
# RetAddr : Args to Child : Call Site
00 fffff800`7a0fa607 : ffffe001`d1182000 ffffe001`d4776d20 ffffe001`d4776bc8 ffffe001`00000000 :
tabletaudiosample!CMiniportWaveRT::NewStream+0x1dc [c:\data1\threshold\audio\endpointscommon\minwavert.cpp @
597]
01 fffff800`7a0fb2c3 : 00000000`00000000 ffffe001`d122bb10 ffffe001`ceb81750 ffffe001`d173f058 :
portcls!CPortPinWaveRT::Init+0x2e7
02 fffff800`7a0fc7f9 : ffffe001`d4776bc0 00000000`00000000 ffffe001`d10b8380 ffffe001`d122bb10 :
portcls!CPortFilterWaveRT::NewIrpTarget+0x193
03 fffff800`7a180552 : 00000000`00000000 ffffe001`d10b8380 ffffe001`d122bb10 ffffe001`d4565600 :
portcls!xDispatchCreate+0xd9
04 fffff800`7a109a9a : ffffe001`d10b84d0 ffffe001`d10b8380 00000000`00000000 ffffe001`00000000 :
ks!KsDispatchIrp+0x272
05 fffff800`7bd314b1 : ffffe001`d122bb10 ffffd001`c3098590 ffffe001`d122bd90 ffffe001`ce80da70 :
portcls!DispatchCreate+0x7a
06 fffff803`cda1bfa8 : 00000000`00000024 00000000`00000000 00000000`00000000 ffffe001`d122bb10 :
ksthunk!CKernelFilterDevice::DispatchIrp+0xf9
07 fffff803`cda7b306 : 00000000`000001f0 ffffe001`d48ce690 ffffe001`d13d6400 ffffe001`d13d64c0 :
nt!IopParseDevice+0x7c8
08 fffff803`cda12916 : 00000000`000001f0 ffffd001`c30988d0 ffffe001`d13d6490 fffff803`cda7b250 :
nt!IopParseFile+0xb6
09 fffff803`cda1131c : ffffe001`d2ccb001 ffffd001`c30989e0 00ffffe0`00000040 ffffe001`cd127dc0 :
nt!ObpLookupObjectName+0x776
0a fffff803`cd9fedb8 : ffffe001`00000001 ffffe001`d48ce690 00000000`00000000 00000000`00000000 :
nt!ObOpenObjectByNameEx+0x1ec
0b fffff803`cd9fe919 : 000000ee`6d1fc8d8 000000ee`6d1fc788 000000ee`6d1fc7e0 000000ee`6d1fc7d0 :
nt!IopCreateFile+0x3d8
0c fffff803`cd752fa3 : ffffc000`1f296870 fffff803`cd9d9fbd ffffd001`c3098be8 00000000`00000000 :
nt!NtCreateFile+0x79
0d 00007fff`69805b74 : 00007fff`487484e6 0000029b`00000003 00000000`0000012e 00000000`00000000 :
nt!KiSystemServiceCopyEnd+0x13
0e 00007fff`487484e6 : 0000029b`00000003 00000000`0000012e 00000000`00000000 00000000`00000000 :
0x00007fff`69805b74
0f 0000029b`00000003 : 00000000`0000012e 00000000`00000000 00000000`00000000 00000000`00000000 :
0x00007fff`487484e6
10 00000000`0000012e : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000080 :
0x0000029b`00000003
11 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000080 00000000`00000000 : 0x12e

You can use DML to further explore the code. When you select the first 00 entry, the .frame (Set Local
Context) command is used to set the context and then, the dv (Display Local Variables) command displays
the local variables.

0: kd> .frame 0n0;dv /t /v

00 ffffd001`c30981d0 fffff800`7a0fa607 tabletaudiosample!CMiniportWaveRT::NewStream+0x1dc
[c:\data1\threshold\audio\endpointscommon\minwavert.cpp @ 597]
ffffd001`c30982b0 class CMiniportWaveRT * this = 0xffffe001`d1182000
ffffd001`c30982b8 struct IMiniportWaveRTStream ** OutStream = 0xffffe001`d4776d20
ffffd001`c30982c0 struct IPortWaveRTStream * OuterUnknown = 0xffffe001`d4776bc8
ffffd001`c30982c8 unsigned long Pin = 0
ffffd001`c30982d0 unsigned char Capture = 0x00 '
ffffd001`c30982d8 union KSDATAFORMAT * DataFormat = 0xffffe001`cd7609b0
ffffd001`c3098270 struct _GUID signalProcessingMode = {4780004E-7133-41D8-8C74-660DADD2C0EE}
ffffd001`c3098210 long ntStatus = 0n0
ffffd001`c3098218 class CMiniportWaveRTStream * stream = 0x00000000`00000000

Section 10: Display processes and threads

In Section 10, you will use debugger commands to display processes and threads.
Process
To change the current process context, use the .process <process> command. The following example
demonstrates how to identify a process and switch context to it.
Use the !process command to display the current process that is involved in playing the sound.
For more information see !process
The output shows that the process is associated with audiodg.exe. If you are still at the breakpoint described in
the previous section of this topic, the current process should be associated with the audiodg.exe image.
<- On the host system

0: kd> !process
PROCESS ffffe001d147c840
SessionId: 0 Cid: 10f0 Peb: ee6cf8a000 ParentCid: 0434
DirBase: d2122000 ObjectTable: ffffc0001f191ac0 HandleCount: <Data Not Accessible>
Image: audiodg.exe
VadRoot ffffe001d4222f70 Vads 70 Clone 0 Private 504. Modified 16. Locked 0.
DeviceMap ffffc00019113080
Token ffffc0001f1d4060
ElapsedTime <Invalid>
UserTime 00:00:00.000
KernelTime 00:00:00.000
QuotaPoolUsage[PagedPool] 81632
QuotaPoolUsage[NonPagedPool] 9704
Working Set Sizes (now,min,max) (2154, 1814, 2109) (8616KB, 7256KB, 8436KB)
PeakWorkingSetSize 2101
VirtualSize 2097192 Mb
PeakVirtualSize 2097192 Mb
PageFaultCount 2336
MemoryPriority BACKGROUND
BasePriority 8
CommitCharge 1573

THREAD ffffe001d173e840 Cid 10f0.1dac Teb: 000000ee6cf8b000 Win32Thread: ffffe001d1118cf0 WAIT:

(UserRequest) UserMode Non-Alertable
ffffe001d16c4dd0 NotificationEvent
ffffe001d08b0840 ProcessObject

THREAD ffffe001ceb77080 Cid 10f0.16dc Teb: 000000ee6cf8d000 Win32Thread: 0000000000000000 WAIT:

(WrQueue) UserMode Alertable
ffffe001cf2d1840 QueueObject

THREAD ffffe001d112c840 Cid 10f0.0a4c Teb: 000000ee6cf8f000 Win32Thread: 0000000000000000 WAIT:

(WrQueue) UserMode Alertable
ffffe001cf2d1840 QueueObject

THREAD ffffe001d16c7840 Cid 10f0.13c4 Teb: 000000ee6cf91000 Win32Thread: 0000000000000000 WAIT:

(WrQueue) UserMode Alertable
ffffe001cf2d1840 QueueObject

THREAD ffffe001cec67840 Cid 10f0.0dbc Teb: 000000ee6cf93000 Win32Thread: 0000000000000000 WAIT:

(WrQueue) UserMode Alertable
ffffe001d173e5c0 QueueObject

THREAD ffffe001d1117840 Cid 10f0.1d6c Teb: 000000ee6cf95000 Win32Thread: 0000000000000000 WAIT:

(WrQueue) UserMode Alertable
ffffe001d173e5c0 QueueObject

THREAD ffffe001cdeae840 Cid 10f0.0298 Teb: 000000ee6cf97000 Win32Thread: 0000000000000000 RUNNING

on processor 2

Note that one of the threads associated with this process is in the RUNNING state. This thread was supporting
the playing of the media clip when the breakpoint was hit.
Use the !process 0 0 command to display summary information for all processes. In the command output use
CTRL+F to locate the process ID for the process associated with the audiodg.exe image. In the example shown
below, the process ID is ffffe001d147c840.
Record the process ID associated with audiodg.exe on your PC to use later in this lab. ________________________

...

PROCESS ffffe001d147c840
SessionId: 0 Cid: 10f0 Peb: ee6cf8a000 ParentCid: 0434
DirBase: d2122000 ObjectTable: ffffc0001f191ac0 HandleCount: <Data Not Accessible>
Image: audiodg.exe
...

Enter g into the debugger to run the code forward until the media clip is done playing. Then break in to the
debugger, by pressing Ctrl+ScrLk (Ctrl+Break) Use the !process command to confirm that you are now running
a different process.

!process
PROCESS ffffe001cd0ad040
SessionId: none Cid: 0004 Peb: 00000000 ParentCid: 0000
DirBase: 001aa000 ObjectTable: ffffc00017214000 HandleCount: <Data Not Accessible>
Image: System
VadRoot ffffe001d402b820 Vads 438 Clone 0 Private 13417. Modified 87866. Locked 64.
DeviceMap ffffc0001721a070
Token ffffc00017216a60
ElapsedTime 05:04:54.716
UserTime 00:00:00.000
KernelTime 00:00:20.531
QuotaPoolUsage[PagedPool] 0
QuotaPoolUsage[NonPagedPool] 0
Working Set Sizes (now,min,max) (1720, 50, 450) (6880KB, 200KB, 1800KB)
PeakWorkingSetSize 15853
VirtualSize 58 Mb
PeakVirtualSize 74 Mb
PageFaultCount 46128
MemoryPriority BACKGROUND
BasePriority 8
CommitCharge 66

THREAD ffffe001cd0295c0 Cid 0004.000c Teb: 0000000000000000 Win32Thread: 0000000000000000 WAIT:

(Executive) KernelMode Non-Alertable
fffff803cd8e0120 SynchronizationEvent

THREAD ffffe001cd02a6c0 Cid 0004.0010 Teb: 0000000000000000 Win32Thread: 0000000000000000 WAIT:

(Executive) KernelMode Non-Alertable
fffff803cd8e0ba0 Semaphore Limit 0x7fffffff
...

The output above shows that a different system process of ffffe001cd0ad040 is running. The image name shows
System, not audiodg.exe.
Now use the !process command to switch to the process that was associated with audiodg.exe. In the example,
the process ID is ffffe001d147c840. Substitute the process ID in the example with your process ID, that you
recorded earlier.

0: kd> !process ffffe001d147c840

PROCESS ffffe001d147c840
SessionId: 0 Cid: 10f0 Peb: ee6cf8a000 ParentCid: 0434
DirBase: d2122000 ObjectTable: ffffc0001f191ac0 HandleCount: <Data Not Accessible>
Image: audiodg.exe
VadRoot ffffe001d4222f70 Vads 60 Clone 0 Private 299. Modified 152. Locked 0.
DeviceMap ffffc00019113080
Token ffffc0001f1d4060
 Token ffffc0001f1d4060
ElapsedTime 1 Day 01:53:14.490
UserTime 00:00:00.031
KernelTime 00:00:00.031
QuotaPoolUsage[PagedPool] 81552
QuotaPoolUsage[NonPagedPool] 8344
Working Set Sizes (now,min,max) (1915, 1814, 2109) (7660KB, 7256KB, 8436KB)
PeakWorkingSetSize 2116
VirtualSize 2097189 Mb
PeakVirtualSize 2097192 Mb
PageFaultCount 2464
MemoryPriority BACKGROUND
BasePriority 8
CommitCharge 1418

THREAD ffffe001d173e840 Cid 10f0.1dac Teb: 000000ee6cf8b000 Win32Thread: ffffe001d1118cf0 WAIT:

(UserRequest) UserMode Non-Alertable
ffffe001d16c4dd0 NotificationEvent
ffffe001d08b0840 ProcessObject
Not impersonating
DeviceMap ffffc00019113080
Owning Process ffffe001d147c840 Image: audiodg.exe
Attached Process N/A Image: N/A
Wait Start TickCount 338852 Ticks: 197682 (0:00:51:28.781)
Context Switch Count 36 IdealProcessor: 0
UserTime 00:00:00.015
KernelTime 00:00:00.000
Win32 Start Address 0x00007ff7fb928de0
Stack Init ffffd001c2ec6dd0 Current ffffd001c2ec60c0
Base ffffd001c2ec7000 Limit ffffd001c2ec1000 Call 0
Priority 8 BasePriority 8 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5
Kernel stack not resident.

THREAD ffffe001d115c080 Cid 10f0.15b4 Teb: 000000ee6cf9b000 Win32Thread: 0000000000000000 WAIT:

(WrQueue) UserMode Alertable
ffffe001d0bf0640 QueueObject
Not impersonating
DeviceMap ffffc00019113080
Owning Process ffffe001d147c840 Image: audiodg.exe
Attached Process N/A Image: N/A
Wait Start TickCount 338852 Ticks: 197682 (0:00:51:28.781)
Context Switch Count 1 IdealProcessor: 0
UserTime 00:00:00.000
KernelTime 00:00:00.000
Win32 Start Address 0x00007fff6978b350
Stack Init ffffd001c3143dd0 Current ffffd001c3143520
Base ffffd001c3144000 Limit ffffd001c313e000 Call 0
Priority 8 BasePriority 8 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5
Kernel stack not resident.

THREAD ffffe001d3a27040 Cid 10f0.17f4 Teb: 000000ee6cf9d000 Win32Thread: 0000000000000000 WAIT:

(WrQueue) UserMode Alertable
ffffe001d173e5c0 QueueObject
Not impersonating
DeviceMap ffffc00019113080
Owning Process ffffe001d147c840 Image: audiodg.exe
Attached Process N/A Image: N/A
Wait Start TickCount 518918 Ticks: 17616 (0:00:04:35.250)
Context Switch Count 9 IdealProcessor: 1
UserTime 00:00:00.000
KernelTime 00:00:00.000
Win32 Start Address 0x00007fff6978b350
Stack Init ffffd001c70c6dd0 Current ffffd001c70c6520
Base ffffd001c70c7000 Limit ffffd001c70c1000 Call 0
Priority 9 BasePriority 8 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5
Kernel stack not resident.

Because this code is not active, all of the threads are in WAIT state, as expected.
Threads
The commands to view and set threads are very similar to those of processes. Use the !thread command to
view threads. Use .thread to set the current threads.
To explore threads associated with the media player, play the media clip again. If the breakpoint described in the
previous section is still in place, you will stop in the context of audiodg.exe.
Use the !thread -1 0 to display brief information for the current thread. This shows the thread address, the
thread and process IDs, the thread environment block (TEB) address, the address of the Win32 function (if any)
the thread was created to run, and the thread’s scheduling state.

0: kd> !thread -1 0
THREAD ffffe001d3a27040 Cid 10f0.17f4 Teb: 000000ee6cf9d000 Win32Thread: 0000000000000000 RUNNING on
processor 0

To view more information about the thread that is running, type !thread . Information similar to the following
should be displayed.
 0: kd> !thread
THREAD ffffe001d3a27040 Cid 10f0.17f4 Teb: 000000ee6cf9d000 Win32Thread: 0000000000000000 RUNNING on
processor 0
IRP List:
ffffe001d429e580: (0006,02c8) Flags: 000008b4 Mdl: 00000000
Not impersonating
DeviceMap ffffc00019113080
Owning Process ffffe001d147c840 Image: audiodg.exe
Attached Process N/A Image: N/A
Wait Start TickCount 537630 Ticks: 0
Context Switch Count 63 IdealProcessor: 1
UserTime 00:00:00.000
KernelTime 00:00:00.015
Win32 Start Address 0x00007fff6978b350
Stack Init ffffd001c70c6dd0 Current ffffd001c70c6520
Base ffffd001c70c7000 Limit ffffd001c70c1000 Call 0
Priority 8 BasePriority 8 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5
Child-SP RetAddr : Args to Child
: Call Site
ffffd001`c70c62a8 fffff800`7a0fa607 : ffffe001`d4aec5c0 ffffe001`cdefd3d8 ffffe001`d4aec5c0
ffffe001`cdefd390 : tabletaudiosample!CMiniportWaveRT::NewStream
[c:\data1\threshold\audio\endpointscommon\minwavert.cpp @ 562]
ffffd001`c70c62b0 fffff800`7a0fb2c3 : 00000000`00000000 ffffe001`d429e580 ffffe001`d4ea47b0
ffffe001`cdefd3d8 : portcls!CPortPinWaveRT::Init+0x2e7
ffffd001`c70c6340 fffff800`7a0fc7f9 : ffffe001`d4aec430 00000000`00000000 ffffe001`d10b8380
ffffe001`d429e580 : portcls!CPortFilterWaveRT::NewIrpTarget+0x193
ffffd001`c70c63c0 fffff800`7a180552 : 00000000`00000000 ffffe001`d10b8380 ffffe001`d429e580
ffffe001`d4565600 : portcls!xDispatchCreate+0xd9
ffffd001`c70c6450 fffff800`7a109a9a : ffffe001`d10b84d0 ffffe001`d10b8380 00000000`00000000
ffffe001`00000000 : ks!KsDispatchIrp+0x272
ffffd001`c70c6510 fffff800`7bd314b1 : ffffe001`d429e580 ffffd001`c70c6590 ffffe001`d429e800
ffffe001`ce80da70 : portcls!DispatchCreate+0x7a
ffffd001`c70c6540 fffff803`cda1bfa8 : 00000000`00000025 00000000`00000000 00000000`00000000
ffffe001`d429e580 : ksthunk!CKernelFilterDevice::DispatchIrp+0xf9
ffffd001`c70c65a0 fffff803`cda7b306 : 00000000`000002fc ffffe001`d5e0d510 00000000`00000000
ffffe001`d3341bd0 : nt!IopParseDevice+0x7c8
ffffd001`c70c6770 fffff803`cda12916 : 00000000`000002fc ffffd001`c70c68d0 ffffe001`d3341ba0
fffff803`cda7b250 : nt!IopParseFile+0xb6
ffffd001`c70c67d0 fffff803`cda1131c : ffffe001`ceb6c601 ffffd001`c70c69e0 00000000`00000040
ffffe001`cd127dc0 : nt!ObpLookupObjectName+0x776
ffffd001`c70c6970 fffff803`cd9fedb8 : ffff8ab8`00000001 ffffe001`d5e0d510 00000000`00000000
00000000`00000000 : nt!ObOpenObjectByNameEx+0x1ec
ffffd001`c70c6a90 fffff803`cd9fe919 : 000000ee`6d37c6e8 00000004`6d37c500 000000ee`6d37c5f0
000000ee`6d37c5e0 : nt!IopCreateFile+0x3d8
ffffd001`c70c6b40 fffff803`cd752fa3 : fffff6fb`7da05360 fffff6fb`40a6c0a8 fffff681`4d815760
ffff8ab8`92895e23 : nt!NtCreateFile+0x79
ffffd001`c70c6bd0 00007fff`69805b74 : 00007fff`487484e6 0000029b`00000003 00000000`0000012e
00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ ffffd001`c70c6c40)
000000ee`6d37c568 00007fff`487484e6 : 0000029b`00000003 00000000`0000012e 00000000`00000000
00000000`00000000 : 0x00007fff`69805b74
000000ee`6d37c570 0000029b`00000003 : 00000000`0000012e 00000000`00000000 00000000`00000000
00000000`00000000 : 0x00007fff`487484e6
000000ee`6d37c578 00000000`0000012e : 00000000`00000000 00000000`00000000 00000000`00000000
00000000`00000080 : 0x0000029b`00000003
000000ee`6d37c580 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000080
00000000`00000000 : 0x12e

Use the k command to view the call stack associated with the thread.
 0: kd> k
# Child-SP RetAddr Call Site
00 ffffd001`c70c62a8 fffff800`7a0fa607 tabletaudiosample!CMiniportWaveRT::NewStream
[c:\data1\threshold\audio\endpointscommon\minwavert.cpp @ 562]
01 ffffd001`c70c62b0 fffff800`7a0fb2c3 portcls!CPortPinWaveRT::Init+0x2e7
02 ffffd001`c70c6340 fffff800`7a0fc7f9 portcls!CPortFilterWaveRT::NewIrpTarget+0x193
03 ffffd001`c70c63c0 fffff800`7a180552 portcls!xDispatchCreate+0xd9
04 ffffd001`c70c6450 fffff800`7a109a9a ks!KsDispatchIrp+0x272
05 ffffd001`c70c6510 fffff800`7bd314b1 portcls!DispatchCreate+0x7a
06 ffffd001`c70c6540 fffff803`cda1bfa8 ksthunk!CKernelFilterDevice::DispatchIrp+0xf9
07 ffffd001`c70c65a0 fffff803`cda7b306 nt!IopParseDevice+0x7c8
08 ffffd001`c70c6770 fffff803`cda12916 nt!IopParseFile+0xb6
09 ffffd001`c70c67d0 fffff803`cda1131c nt!ObpLookupObjectName+0x776
0a ffffd001`c70c6970 fffff803`cd9fedb8 nt!ObOpenObjectByNameEx+0x1ec
0b ffffd001`c70c6a90 fffff803`cd9fe919 nt!IopCreateFile+0x3d8
0c ffffd001`c70c6b40 fffff803`cd752fa3 nt!NtCreateFile+0x79
0d ffffd001`c70c6bd0 00007fff`69805b74 nt!KiSystemServiceCopyEnd+0x13
0e 000000ee`6d37c568 00007fff`487484e6 0x00007fff`69805b74
0f 000000ee`6d37c570 0000029b`00000003 0x00007fff`487484e6
10 000000ee`6d37c578 00000000`0000012e 0x0000029b`00000003
11 000000ee`6d37c580 00000000`00000000 0x12e

Enter g into the debugger to run the code forward until the media clip is done playing. Then break in to the
debugger, by pressing Ctrl - ScrLk (Ctrl-Break) Use the !thread command to confirm that you are now running a
different thread.
 0: kd> !thread
THREAD ffffe001ce80b840 Cid 17e4.01ec Teb: 00000071fa9b9000 Win32Thread: ffffe001d41690d0 RUNNING on
processor 0
Not impersonating
DeviceMap ffffc0001974e2c0
Owning Process ffffe001d1760840 Image: rundll32.exe
Attached Process N/A Image: N/A
Wait Start TickCount 538040 Ticks: 0
Context Switch Count 3181840 IdealProcessor: 0
UserTime 00:00:08.250
KernelTime 00:00:10.796
Win32 Start Address 0x00007ff6d2f24270
Stack Init ffffd001cd16afd0 Current ffffd001cd16a730
Base ffffd001cd16b000 Limit ffffd001cd165000 Call 0
Priority 8 BasePriority 8 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5

Child-SP RetAddr : Args to Child

: Call Site
fffff803`cf373d18 fffff800`7a202852 : fffff803`cf373e60 00000000`00000001 ffffe001`cf4ed330
00000000`0000ffff : nt!DbgBreakPointWithStatus
fffff803`cf373d20 fffff803`cd6742c6 : ffffe001`cf4ed2f0 fffff803`cf373e60 00000000`00000001
00000000`0004e4b8 : kdnic!TXSendCompleteDpc+0x142
fffff803`cf373d60 fffff803`cd74d495 : 00000000`00000000 fffff803`cd923180 fffff803`cde1f4b0
fffff901`40669010 : nt!KiRetireDpcList+0x5f6
fffff803`cf373fb0 fffff803`cd74d2a0 : 00000000`00000090 0000000e`0000006a 00000000`00000092
00000000`00000000 : nt!KxRetireDpcList+0x5 (TrapFrame @ fffff803`cf373e70)
ffffd001`cd16a6c0 fffff803`cd74bd75 : 00000000`00000000 fffff803`cd74a031 00000000`00000000
00000000`00000000 : nt!KiDispatchInterruptContinue
ffffd001`cd16a6f0 fffff803`cd74a031 : 00000000`00000000 00000000`00000000 ffffe001`cff4d2a0
fffff803`cd67738e : nt!KiDpcInterruptBypass+0x25
ffffd001`cd16a700 fffff960`50cdb5a4 : fffff901`400006d0 00000000`00000001 fffff901`40000d60
ffffd001`cd16a9f0 : nt!KiInterruptDispatchNoLockNoEtw+0xb1 (TrapFrame @ ffffd001`cd16a700)
ffffd001`cd16a890 fffff960`50c66b2f : 00000000`00000000 fffff901`40669010 fffff901`42358580
fffff901`40000d60 : win32kfull!Win32FreePoolImpl+0x34
ffffd001`cd16a8c0 fffff960`50c68cd6 : 00000000`00000000 ffffd001`cd16a9f0 fffff901`400006d0
fffff901`400c0460 : win32kfull!EXLATEOBJ::vAltUnlock+0x1f
ffffd001`cd16a8f0 fffff803`cd752fa3 : 00000000`00000000 00000000`00000000 ffffe001`ce80b840
00000000`00000000 : win32kfull!NtGdiAlphaBlend+0x1d16
ffffd001`cd16add0 00007fff`674c1494 : 00007fff`674b1e97 0000a7c6`daee0559 00000000`00000001
0000020b`741f3c50 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ ffffd001`cd16ae40)
00000071`fa74c9a8 00007fff`674b1e97 : 0000a7c6`daee0559 00000000`00000001 0000020b`741f3c50
00000000`00ffffff : 0x00007fff`674c1494
00000071`fa74c9b0 0000a7c6`daee0559 : 00000000`00000001 0000020b`741f3c50 00000000`00ffffff
00000000`00000030 : 0x00007fff`674b1e97
00000071`fa74c9b8 00000000`00000001 : 0000020b`741f3c50 00000000`00ffffff 00000000`00000030
00000000`01010bff : 0x0000a7c6`daee0559
00000071`fa74c9c0 0000020b`741f3c50 : 00000000`00ffffff 00000000`00000030 00000000`01010bff
00000000`00000000 : 0x1
00000071`fa74c9c8 00000000`00ffffff : 00000000`00000030 00000000`01010bff 00000000`00000000
00000000`000000c0 : 0x0000020b`741f3c50
00000071`fa74c9d0 00000000`00000030 : 00000000`01010bff 00000000`00000000 00000000`000000c0
00000000`00000030 : 0xffffff
00000071`fa74c9d8 00000000`01010bff : 00000000`00000000 00000000`000000c0 00000000`00000030
00000071`00000030 : 0x30
00000071`fa74c9e0 00000000`00000000 : 00000000`000000c0 00000000`00000030 00000071`00000030
00000071`01ff8000 : 0x1010bff

The image name is rundll32.exe, which is indeed not the image name associated with playing the media clip.
Note To set the current thread, type .thread <thread number>.
For more information about threads and processes, see the following references:
Threads and Processes
Changing Contexts
Section 11: IRQL, registers, and disassembly
View the saved IRQL
In Section 11, you will display the IRQL, and the contents of the regsisters.
<- On the host system
The interrupt request level (IRQL) is used to manage the priority of interrupt servicing. Each processor has an
IRQL setting that threads can raise or lower. Interrupts that occur at or below the processor's IRQL setting are
masked and will not interfere with the current operation. Interrupts that occur above the processor's IRQL
setting take precedence over the current operation. The !irql extension displays the interrupt request level
(IRQL) on the current processor of the target computer before the debugger break occurred. When the target
computer breaks into the debugger, the IRQL changes, but the IRQL that was effective just before the debugger
break is saved and is displayed by !irql.

0: kd> !irql
Debugger saved IRQL for processor 0x0 -- 2 (DISPATCH_LEVEL)

<
View the registers and disassembly
View the registers
Display the contents of the registers for the current thread on the current processor by using the r (Registers)
command.

0: kd> r
rax=000000000000c301 rbx=ffffe00173eed880 rcx=0000000000000001
rdx=000000d800000000 rsi=ffffe00173eed8e0 rdi=ffffe00173eed8f0
rip=fffff803bb757020 rsp=ffffd001f01f8988 rbp=ffffe00173f0b620
r8=000000000000003e r9=ffffe00167a4a000 r10=000000000000001e
r11=ffffd001f01f88f8 r12=0000000000000000 r13=ffffd001f01efdc0
r14=0000000000000001 r15=0000000000000000
iopl=0 nv up ei pl nz na pe nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00000202
nt!DbgBreakPointWithStatus:
fffff803`bb757020 cc int 3

Alternatively, you can display the contents of the registers by selecting View > Registers .
Viewing the contents of the registers can be helpful when stepping through assembly language code execution
and in other scenarios. For more information see r (Registers) .
For information about contents of the register, see x86 Architecture and x64 Architecture.
Disassembly
You can disassemble the code that is under execution to view the assembly language code that is being run by
selecting View > Disassembly .

For more information about assembly language disassembly, see Annotated x86 Disassembly and Annotated
x64 Disassembly.
Section 12: Work with memory
In Section 12, you will use debugger commands to display the contents of memory.
View memor y
You may need to examine memory to identify an issue or to inspect variables, pointers, and so on. You can
display memory by typing one of the following d* <address> commands.

db Displays data in byte values and ASCII characters.

dd Displays data as double wide words (4 bytes).

du Displays data as Unicode characters.

dw Displays data as word values (2 bytes) and ASCII

characters.

Note If you attempt to display an invalid address, its contents are shown as question marks (?).
Alternatively, you can view the memory by selecting View > Memor y . Use the Display format pull down to
change how the memory is displayed.

1. To view data associated with the volume control, set a breakpoint to fire on the
PropertyHandlerAudioEngineVolumeLevel routine using the bm command. Before we set the new
breakpoint, we will clear all of the previous breakpoints using bc *.

kd> bc *

2. Set a breakpoint to fire on the PropertyHandlerAudioEngineVolumeLevel routine using the bm

command.

kd> bm tabletaudiosample!CMiniportWaveRT::SetDeviceChannelVolume
1: fffff80f`02c3a4b0 @!"tabletaudiosample!CMiniportWaveRT::SetDeviceChannelVolume"

3. List the breakpoints to confirm that the breakpoint is set properly.

 kd> bl
1: fffff80f`02c3a4b0 @!"tabletaudiosample!CMiniportWaveRT::SetDeviceChannelVolume"

4. Use the g command to restart code execution.

On the target system adjust the volume in the system tray. This will cause the breakpoint to fire.

Breakpoint 1 hit
tabletaudiosample!CMiniportWaveRT::SetDeviceChannelVolume:
fffff80f`02c3a4b0 44894c2420 mov dword ptr [rsp+20h],r9d

5. Use the View > Local menu item to display local variables. Note the current value of the IVolume
variable.
6. You can display the data type and the current value for the IVolume variable in the sample code by typing
the dt command and the name of the variable.

kd> dt lVolume
Local var @ 0xa011ea50 Type long
0n-6291456

7. The breakpoint is hit on entering SetDeviceChannelVolume.

STDMETHODIMP_(NTSTATUS) CMiniportWaveRT::SetDeviceChannelVolume(_In_ ULONG _ulNodeId, _In_ UINT32

_uiChannel, _In_ LONG _Volume)
{
NTSTATUS ntStatus = STATUS_INVALID_DEVICE_REQUEST;

PAGED_CODE ();

DPF_ENTER(("[CMiniportWaveRT::SetEndpointChannelVolume]"));
IF_TRUE_ACTION_JUMP(_ulNodeId != KSNODE_WAVE_AUDIO_ENGINE, ntStatus =
STATUS_INVALID_DEVICE_REQUEST, Exit);

// Snap the volume level to our range of steppings.

LONG lVolume = VOLUME_NORMALIZE_IN_RANGE(_Volume);

ntStatus = SetChannelVolume(_uiChannel, lVolume);

Exit:
return ntStatus;
}

8. Attempt to display the value at the memory location of IVolume by using the dt (Display Type)
command.

kd> dt dt lVolume
Local var @ 0xffffb780b7eee664 Type long
0n0

Because the variable is yet to be defined, it does not contain information.

9. Press F10 to run forward to the last line of code in SetDeviceChannelVolume.

return ntStatus;

10. Display the value at the memory location of IVolume by using the dt (Display Type) command.
 kd> dt lVolume
Local var @ 0xffffb780b7eee664 Type long
0n-6291456

Now that the variable is active, a value of 6291456 is displayed in this example.
11. You can also display the memory location of IVolume by using the ? (Evaluate Expression) command.

kd> ? lVolume
Evaluate expression: -79711507126684 = ffffb780`b7eee664

12. The address shown, ffffb780`b7eee664 is the address of the lVolume variable. Use the dd command to
display the contents of memory at that location.

kd> dd ffffb780`b7eee664
ffffb780`b7eee664 ffa00000 00000018 00000000 c52d7008
ffffb780`b7eee674 ffffc98e e0495756 fffff80e c52d7008
ffffb780`b7eee684 ffffc98e 00000000 fffff80e 00000000
ffffb780`b7eee694 ffffc98e ffa00000 ffffb780 b7eee710
ffffb780`b7eee6a4 ffffb780 00000000 00000000 c7477260
ffffb780`b7eee6b4 ffffc98e b7eee7a0 ffffb780 b7eee6f0
ffffb780`b7eee6c4 ffffb780 e04959ca fffff80e 00000000
ffffb780`b7eee6d4 00000000 00000028 00000000 00000002

13. You can display the first four bytes of an address by specifying the range parameter L4.

kd> dd ffffb780`b7eee664 l4
ffffb780`b7eee664 ffa00000 00000018 00000000 c52d7008

14. To see the different types of memory output displayed, type the du , da and db commands.

kd> du ffffb780`b7eee664
ffffb780`b7eee664 ""

kd> a ffffb780`b7eee664
ffffb780`b7eee664 ""

kd> db 0xffffae015ff97664
ffffae01`5ff97664 00 80 bc ff 18 00 00 00-00 00 00 00 08 50 e0 51 .............P.Q
ffffae01`5ff97674 00 c0 ff ff 56 57 da 56-0e f8 ff ff 08 50 e0 51 ....VW.V.....P.Q
ffffae01`5ff97684 00 c0 ff ff 00 00 00 00-0e f8 ff ff 00 00 00 00 ................
ffffae01`5ff97694 00 c0 ff ff aa 80 bc ff-01 ae ff ff 10 77 f9 5f .............w._
ffffae01`5ff976a4 01 ae ff ff 40 00 00 00-00 e6 ff ff 10 dc 30 55 [email protected]
ffffae01`5ff976b4 00 c0 ff ff a0 77 f9 5f-01 ae ff ff f0 76 f9 5f .....w._.....v._
ffffae01`5ff976c4 01 ae ff ff ca 59 da 56-0e f8 ff ff 00 00 00 00 .....Y.V........
ffffae01`5ff976d4 00 00 00 00 28 00 00 00-00 00 00 00 02 00 00 00 ....(...........

Use the df float option to display data as single-precision floating-point numbers (4 bytes).

df ffffb780`b7eee664
ffffb780`b7eee664 -1.#QNAN 3.3631163e-044 0 -2775.002
ffffb780`b7eee674 -1.#QNAN -5.8032637e+019 -1.#QNAN -2775.002
ffffb780`b7eee684 -1.#QNAN 0 -1.#QNAN 0
ffffb780`b7eee694 -1.#QNAN -1.#QNAN -1.#QNAN -2.8479408e-005

Write to memor y
Similar to the commands that are used for reading memory, you can use the e* commands to change memory
contents.

C OMMAND DESC RIP T IO N

ea ASCII string (not NULL-terminated)

eu Unicode string (not NULL-terminated

ew Word values (2 bytes)

eza NULL-terminated ASCII string

ezu NULL-terminated Unicode string

eb Byte values

ed Double-word values (4 bytes)

The following example shows how to overwrite memory.

1. First, locate the address of the lVolume that is used in the sample code.

kd> ? lVolume
Evaluate expression: -79711507126684 = ffffb780`b7eee664

2. Overwrite that memory address with new characters using the eb command.

kd> eb 0xffffb780`b7eee664 11 11 11 11 11

3. Display the memory location to confirm that the characters have been overwritten by typing the db
command.

kd> db 0xffffb780`b7eee664
ffffb780`b7eee664 11 11 11 11 11 00 00 00-00 00 00 00 08 70 2d c5 .............p-.
ffffb780`b7eee674 8e c9 ff ff 56 57 49 e0-0e f8 ff ff 08 70 2d c5 ....VWI......p-.
ffffb780`b7eee684 8e c9 ff ff 00 00 00 00-0e f8 ff ff 00 00 00 00 ................
ffffb780`b7eee694 8e c9 ff ff 00 00 a0 ff-80 b7 ff ff 10 e7 ee b7 ................
ffffb780`b7eee6a4 80 b7 ff ff 00 00 00 00-00 00 00 00 60 72 47 c7 ............`rG.
ffffb780`b7eee6b4 8e c9 ff ff a0 e7 ee b7-80 b7 ff ff f0 e6 ee b7 ................
ffffb780`b7eee6c4 80 b7 ff ff ca 59 49 e0-0e f8 ff ff 00 00 00 00 .....YI.........
ffffb780`b7eee6d4 00 00 00 00 28 00 00 00-00 00 00 00 02 00 00 00 ....(...........

Alternatively, you can modify the contents of the memory in a watch or locals window. For the watch window,
you may see variables that are out of context of the current frame. Modifying them is not relevant if they are not
in context.

Section 13: End the WinDbg session

<-On the host system
To end a user-mode debugging session, return the debugger to dormant mode, and set the target application to
run again, enter the qd (Quit and Detach) command.
Be sure and use the g command to let the target computer run code, so that it can be used. It also a good idea to
clear any break points using bc \ *, so that the target computer won't break and try to connect to the host
computer debugger.

0: kd> qd

For more information, see Ending a Debugging Session in WinDbg in the debugging reference documentation.

Section 14: Windows debugging resources

Additional information is available on Windows debugging. Note that some of these books will use older
versions of Windows such as Windows Vista in their examples, but the concepts discussed are applicable to
most versions of Windows.
Books
Advanced Windows Debugging by Mario Hewardt and Daniel Pravat
Inside Windows Debugging: A Practical Guide to Debugging and Tracing Strategies in Windows® by
Tarik Soulami
Windows Internals by Mark E. Russinovich, David A. Solomon and Alex Ionescu
Video
The Defrag Tools Show WinDbg Episodes 13-29 https://channel9.msdn.com/Shows/Defrag-Tools
Training Vendors:
OSR - https://www.osr.com/

See Also
Getting Started with Windows Debugging
 Debugging Using WinDbg Preview
6/16/2021 • 4 minutes to read • Edit Online

WinDbg Preview is the latest version of WinDbg with more modern visuals, faster windows, a full-fledged
scripting experience, built with the extensible debugger data model front and center. WinDbg Preview is using
the same underlying engine as WinDbg today, so all the commands, extensions, and workflows you're used to
will still work as they did before.

Major Features of WinDbg Preview

Here's some of the most notable things that have changed or are new in WinDbg Preview.

General features
Easier Connection Setup and Recall - The WinDbg Preview includes the ability to recall previous session
configuration information.
 Easy feedback channel - Your feedback will guide the development effort going forward. For more
information, see Providing Feedback
Dump file processor detection -Auto-detects processor architecture for easier managed debugging.
Performance Improvements Windows now load asynchronously and can be canceled - When you run
another command, WinDbg Preview will stop the loading of your locals, watch, or other windows.
Windowing improvements
Disassembly Window Improvements - The disassembly window is also improved, the highlight of
the current instruction remains where it is when you scroll.

Memor y window improvements - The memory window has highlighting and improved scrolling.
Locals and watch data model visualization - The locals and watch windows are both based off of the
data model that is used by the dx command. This means the locals and watch windows will benefit from
any NatVis or JavaScript extensions you have loaded, and can even support full LINQ queries, just like the
dx command.
Logs - This is a under the covers log of the WinDbg Preview internals. It can be viewed for
troubleshooting or to monitor long running processes.
For more information, see WinDbg Preview - View menu.
Command window - Use the command window provides easy access to toggle DML and clear the
debugger command window. All current debugger commands are compatible with and continue to work in
 WinDbg Preview.
Dark theme
Use File > Settings to enable the dark theme.

Ribbon Quick Access

Just pin the buttons you use the most and you can collapse the ribbon to save screen real estate.

Source code
The source code window has been updated to be much more in line with modern editors.

Highlighting
The command window has two new highlighting features. Selecting any text will give a subtle highlight to any
other instances of that text. You can then hit "Highlight/Un-highlight" or Ctrl+Alt+H to persist the highlighting.
Better keyboard navigation
Just hit Ctrl+Tab and you can easily navigate between windows with just your keyboard.

Integrated Time Travel Debugging (TTD)

If you need a TTD trace of your application, just check the "Record with Time Travel Debugging" box when
launching or attaching. WinDbgNext will set it up for TTD and open the trace when you're done recording.

For more information, see Time Travel Debugging - Overview.

Debugging App packages
Debugging your universal app or background task is now a single click or select.
For more information, see Launch App Package.
Attach to a process
The attach dialog provides more detail, includes a search dialog and is easier to use.

Enhanced breakpoint tracking

Enable/Disable breakpoints - The breakpoints window shows all your current breakpoints and provides
easy access to enabling and disabling them.
Hit count - The breakpoint window keeps a running total of each time the breakpoint is hit.
For more information, see Breakpoints.
Enhanced data model support
Built in data model suppor t - WinDbg Preview is written with built in data model support and the data
model is available through out the debugger.
Model window - The model window gives you an expandable and browsable version of ‘dx’ and ‘dx -g’,
letting you create powerful tables on-top of your NatVis, JavaScript, and LINQ queries.
For more information, see WinDbg Preview - Data model.
New scripting development UI
Script development UI - There is now a purpose built scripting window to make developing JavaScript and
NatVis scripts easier, with error highlighting and IntelliSense.

For more information, see WinDbg Preview - Scripting.

Backwards compatibility
Because the underling debugger engine is the same, all of the previous debugger commands and debugger
extensions continue to work.

Providing feedback
Your feedback will help guide WinDbg's development going forward.
If you have feedback such as a feature that you really want to see or a bug that makes something difficult,
use the Feedback Hub.
Team Blog
The debugger team blog, although now inactive, includes tips and tricks. /archive/blogs/windbg/

Videos
Watch these episodes of the Defrag Tools show to see Windbg Preview in action.
Defrag Tools #182 - Tim, Chad, and Andy go over the basics of WinDbg Preview and some of the features.
Defrag Tools #183 - Nick, Tim, and Chad use WinDbg Preview and go over a quick demo.
Defrag Tools #184 - Bill and Andrew walk through the scripting features in WinDbg Preview.
Defrag Tools #185 - James and Ivette provide and introduction to Time Travel Debugging.
Defrag Tools #186 - James and JCAB covers advanced Time Travel Debugging.

Next Steps
For information on what's new in the most recent release, see WinDbg Preview - What's New.
Review these topics to install and configure WinDbg Preview.
WinDbg Preview – Installation
WinDbg Preview – Command line startup options
WinDbg Preview – Settings and workspaces
WinDbg Preview – Keyboard shortcuts
These topics describe how to get connected to the environment that you want to debug.
WinDbg Preview – Start a user-mode session
WinDbg Preview – Start a kernel mode session
These topics describe some common tasks, organized by the menu tabs.
WinDbg Preview – File menu
WinDbg Preview – Home menu
WinDbg Preview – View menu
WinDbg Preview – Breakpoints
WinDbg Preview – Data model
WinDbg Preview – Scripting
 WinDbg Preview - What's New
6/16/2021 • 21 minutes to read • Edit Online

This topic provides information on what's new in the WinDbg Preview debugger.

1.2104.13002.0
Smart number selection and search
A convenient productivity feature of WinDbgNext is the ability to detect patterns in the command window. To do
this, select any text, and all other instances of that text highlighted. Because this highlighting is useful when
looking at memory patterns, it now will also highlight equivalent numbers in other radixes, no matter how the
number is formatted in hex, decimal, or scientific notation. For more information about numbering schemes, see
n (Set Number Base)).
Example:
When selecting 0x000001e2fb3f6160 , all other instances are highlighted no matter the format.

This feature works with semi-temporary highlights as well. Ctrl + Double Click on a number to highlight all its
instances. You can keep track of multiple important numbers throughout your command history this way (to
clear the highlight, Ctrl + Double Click on the number again). Finally, this feature also works when searching
numbers with Ctrl + F.
Source Code Extended Access
The source path command (.srcpath, .lsrcpath (Set Source Path))[-srcpath---lsrcpath--set-source-path-.md] has
been updated to include a new tag – DebugInfoD. For more information, see Source Code Extended Access.
Host and guest states of WOW processes in the data model
When debugging a 32-bit WOW process from a 64-bit context, users can now access both the host and guest
states within the data model.
32 bit guest state examples:
dx @$curprocess.Environment

dx @$curthread.Environment

dx @$curthread.Stack

64 bit host state examples:

dx @$curprocess.NativeEnvironment

dx @$curthread.NativeEnvironment
dx @$curthread.NativeStack

Javascript Debugging Improvements

Javascript loaded in the UI can now be directly debugged within the console using the .scriptdebug command.
For more information, see JavaScript Debugger Scripting - JavaScript Debugging.
Accessibility improvements
With WinDbgNext we are committed to building a debugger that is inclusive to engineers with disabilities, we
are continuously improving accessibility. The following improvements have been made.
Command window links can now be clicked via the keyboard (Shift+Enter)
Improved keyboard navigation of main menu
Improved keyboard navigation of ribbon
Increased contrast on UI elements
New “Overwrite” data access type for Time Travel Debugger
Time Travel Debugger (TTD) now provides an “Overwrite” data access type. Memory queries such as
dx @$cursession.TTD.Memory() now have an additional column showing the old values of writes.

Other fixes, improvements, and updates

Added feature to automatically detect and apply workaround for USB 3.1 hardware issue when both kernel
debugging host and target are USB 3.1 controllers.
Added a new UI shortcut: Ctrl + Shift + Click over a DML link will to copy it to the clipboard

1.0.2007.01003
Timeline Bookmarks
Bookmark important Time Travel positions in WinDbg instead of manually copy pasting the position to notepad.
Bookmarks make it easier to view at a glance different positions in the trace relative to other events, and to
annotate them.
You can provide a descriptive name for bookmarks.

Access Bookmarks via the Timeline window available in View > Timeline. When you hover over a bookmark, it
will display the bookmark name.

You can select and hold (or right-click) the bookmark to travel to that position, rename or delete the bookmark.
Modules Window
A new windows shows modules and their related information, it is available via the View ribbon. It displays:
The name of the module including the path location
The size in bytes of the loaded module
The base address that the module is loaded at
The file version

Thread names/descriptions available in live debugging

Thread names that are set from SetThreadDescription are now available when doing live user-mode debugging.
Thread names are available using the “~” command or the debugger data model.

0:000> ~
0 Id: 53a0.5ffc Suspend: 1 Teb: 000000b1`db1ed000 Unfrozen "Hello world!"
7 Id: 53a0.9114 Suspend: 1 Teb: 000000b1`db1ef000 Unfrozen
8 Id: 53a0.2cc4 Suspend: 1 Teb: 000000b1`db1f1000 Unfrozen
9 Id: 53a0.5c40 Suspend: 1 Teb: 000000b1`db1f3000 Unfrozen

0:000> dx @$curthread
@$curthread : ConsoleTestApp!ILT+25(mainCRTStartup) (00007ff7`fac7101e) [Switch To]
Id : 0x5ffc
Name : Hello world!
Stack
Registers
Environment

Por table PDB suppor t

Portable PDB support has been added. The Portable PDB (Program Database) format describes an encoding of
debugging information produced by compilers of Common Language Infrastructure (CLI) languages and
consumed by debuggers and other tools. For more information, see Portable PDB Symbols.
Other changes and bug fixes
WinDbg now supports AMD64 and Linux kernel dump debugging.
Time travel recording enhancements and other fixes.

1.0.1912.11001
TTD Timelines - We've added a new window that displays a visual representation of important events in your
trace: exceptions, breakpoints, function calls, and memory accesses. Timelines will automatically open and
display exceptions (if present) and breakpoints. For more information, see WinDbg Preview - Timeline.
Switched to default window chrome - The custom window chrome we were using, while prettier, was
causing some scaling and resizing issues for a notable number of people, so we’ve opted to remove it for the
time being.
File menu improved keyboard navigation - The file menu is now much easier to navigate with just a
keyboard.
Other changes and bug fixes
The stack and locals window will now be disabled when your target is running and won’t show “Unspecified
error” when there is no target.
Added a “Services” column to the attach dialog to easily find which services are running.
Fixed a bug that caused architecture detection to not work when launching applications with arguments.
The disassembly window has improved disassembly when private symbols are loaded.
jsprovider.dll is now loaded automatically, so we removed the “Load JSProvider” button from the scripting
ribbon.

1.0.1908.30002
Improvements to TTD Calls objects - Calls queries now include parameter names, types, and values. When
querying across traces for function calls you can get fully typed parameters and their values making it easy to
filter down results by parameters.
Suppor t for Open Enclave - WinDbg Preview can now debug Open Enclave (OE) applications for more
information, see Open Enclave debugging).
VS Code Extension - To make it easier to develop for Open Enclave, we’ve released a basic VS Code extension
to enable a quicker inner loop. Variables, Watch, and Call Stack windows all work as well as breakpoints and
source windows, any deeper debugging will need to use the console window.
You can find the extension in the VS Code Marketplace and report any issues to our WinDbg Feedback GitHub.
Note that while the extension may work for other scenarios, we’re only intending on fixing issues related to OE
scenarios at this point.
ELF Core Dumps - As part of supporting Open Enclave, WinDbg can open ELF core dumps and binaries as well
as DWARF symbols (DWARF 5 is not currently supported) from both Enclaves and Linux applications. When
opening a core dump from a non-Windows application, basic windows and commands should all work properly,
but most extensions and Windows-specific commands will not work. ELF and DWARF files will be downloaded
from symbol servers following the key conventions defined here. Enclaves are the only supported scenario, but
we’re open to feedback on opening other Linux core dumps.
TTD File format change - We’ve made a major update to the file format for TTD traces that breaks forward
compatibility. Previous versions of WinDbg Preview will not be able to open traces recorded with this (and
future) versions of WinDbg Preview, but this (and future) versions will be able to open both new and old traces.
Other changes
TTD will now use the 64-bit engine for indexing and the appropriate debugger engine bitness for replays to
minimize potential memory issues when indexing and SOS issues when replaying.
Running 'dx' without any parameters will now show the root namespace for easier browsability.
You can now modify the default symbol and source cache location via the settings menu.
Improved support for recording AVX-512 (recording of AVX-512 will cause a larger than normal slow-down).
We've enabled offline licensing.
1.0.1905.12001
Improvements to SymSetDiaSession error mitigation - Our fix last month to mitigate the error caused by
applications injecting DbgHelp into our process was still not working in some scenarios. We've made
improvements to it and will continue to monitor feedback on this error.
Accent color customization - A lot of scenarios need several instances of WinDbg open, and moving back
and forth between them can be confusing and take some time to figure out which one is the “right” one. We’ve
added the ability to change the blue accent color to help visually distinguish sessions and make swapping
between them easier.
Just select the View ribbon and select an option for Accent color in the last section. When future sessions are
launched from recent targets, the accent color will be persisted as part of the target’s workspace.
Source tokenization improvements - The source window now has basic support for tokenizing Rust source
files and C++ SEH __try/__except/__finally/__leave.
Coroutine improvements - Improved support for coroutine local variables and certain optimized variables.
Default symbol and source cache setting - Added an option to the settings menu under Debugging
settings to change the cache location for symbols. Note - There’s a known issue that making this blank will
cause source loading to fail. We’ll be adding validation to prevent this from happening in a future release.
-pv fixes - Fixed a bug that may have prevented -pv (non-invasive attach) from working in some circumstances.

1.0.1904.18001
Fix for SymSetDiaSession error - We've had reports for a while of an error that prevents WinDbg Preview
from being launched in some situations. There are a few external applications that attempt to inject a version of
DbgHelp into our process before we load it. Some of them are using a version of DbgHelp with missing
functionality, which causes this error when we attempt to use those features. We've added a fix for this and will
be tracking if there are still scenarios in which it occurs.
Font control - We've added settings for controlling font and font size. There are two different settings, one for
text windows (mono-spaced windows like disassembly, source, command, etc.) and one for tool windows (locals,
stack, etc.). There's still a few areas that aren't affected by these options that we'll be updating in the future.
Highlighting improvements - Persistent highlighting of text in the command window will now also highlight
text in the source and notes windows.
Source loading improvements - We've changed how loading source files works. Previously when opening a
source file, engine operations like running additional commands weren't possible or were unpredictable. We've
changed where the loading occurs to enable better parallelism and more reliable cancellation of source opening
operations.
Other changes and bug fixes:
Added "Go to disassembly" to the context menu of the source window.
Added a checkbox to "Follow current instruction" in disassembly window.
Fixed a bug that caused the command window to perform slowly when outputting lots of text.
Changed page up and page down keys to perform similar to Visual Studio.
When an ASM file is opened in the source window it will now have basic comment, string, and directive
highlighting

1.0.1812.12001
This version includes these updates.
Debugger data model C++ header - There is a new C++ header, DbgModel.h, included as part of the
Windows SDK for extending the debugger data model via C++. You can find more information in Debugger
Data Model C++ Overview. This release includes a new extension that adds some more "API style" features to
the debugger data model that can be accessed through the 'dx' command, JavaScript, and the new DbgModel.h
header. This extension extensions the data model to include knowledge about assembly and code execution
through the Debugger.Utility.Code namespace, and the local file system through the Debugger.Utility.FileSystem
namespace.
Synthetic types extension With this new API extension, we have a new sample up on our GitHub repo here -
https://github.com/Microsoft/WinDbg-Samples/tree/master/SyntheticTypes. This JavaScript extension reads
basic C header files and defines synthetic type information for the structures and unions defined in the header.
Through the dx command, memory can then be viewed structured as if you had a PDB with type information for
those types.
Other changes and bug fixes:
WinDbg Preview will now more intelligently handle bringing source windows or the disassembly window to
the foreground when stepping.
Re-arranged WinDbgNext's window title to have more important information at the start when kernel
debugging.
The alternating background contrast in the command window should be slightly more noticeable.

1.0.1810.2001
This version includes these updates.
New Settings dialog that is accessed from the File menu or the Home ribbon.
Events and exceptions settings dialog. This menu changes how the debugger handles events and exceptions,
the equivalent of the 'sx' commands or WinDbg's event filters dialog. Select Settings on the home ribbon,
then hit "Events and Exceptions" on the left to manage those.
Improved TTD indexer with better performance. This increases the performance of indexing TTD trace files,
making the indexing process much faster (between 2x-10x) while making index files much smaller (~50%
smaller). The perf improvements are most noticeable for traces over 4GB in size, or when using a machine
with many CPU cores (8+). The new indexer makes it more feasible to debug very large traces (50GB+).
New debugArch launch flag for specifying architecture. WinDbg Preview attempts to launch the debugger
engine with the correct bitness to the target to better support debugging managed code. There are
circumstances where it can't determine the right bitness or you may want to override what it decides. Use -
debugArch x86|amd64 to control the architecture of debugger engine.
Other changes and bug fixes:
Fixed a bug that would cause black bars to appear on a full screen debugger with a floating window open.
Fixed a bug that would cause symbol options to be cleared unintentionally.
Command history is now preserved when launching from recent targets.
In the data model window, you can now edit values.
Un-indexed TTD traces will now be more clear that they're un-indexed.
Improved performance of the locals window
Added a ribbon button to save the command window logs to a file.
Added . SelectMany() to the default set of LINQ methods.

1.0.1807.11002
This version includes these updates.
Automatic saving and loading of breakpoints . This is a first step to replace workspaces. We’re starting
down that route by enabling the saving and loading of breakpoints. Launching something you’ve debugged
previously from the “Recents” tab in the file menu will now load the breakpoints from that session. The plan is to
expand this functionality to preserve more information across sessions. Hardware breakpoints (ba) and other
various properties on breakpoints like thread and process specific contexts as well as conditions are not
currently being saved.
Minor changes and bug fixes:
Added command-line options -x, -xe, -xd, -xn, and -xi for controlling the handling of exceptions and events.
These command-line options behave just like their command counter-parts.
The notes window now supports bold, underline, and italics formatting.
Fixed some zoom and scrolling issues.
Selecting text in the command, memory, sources, or disassembly windows will now show a light highlight
over other instances of the selected text.
Fixed a bug where interrupting symbol loading would cause symbol loading to fail for the rest of the session.
NatVis will now reload properly on restarting a session.

1.0.1805.17002
This version includes these updates.
New disassembly window - The disassembly window now includes:
Scrolling up or down will continuously load more disassembly whenever possible.
Syntax highlighting for numbers, code addresses, and opcodes.
Selecting a code symbol will jump the disassembly window to that location.
Hovering over numbers will show a tooltip that converts that number to other bases.
Headers signifying the start of a function.
Faster source window - The source window has been updated to be faster and more resource efficient.
Minor changes and bug fixes:
Fixed issues around symbol caching
Fixed some cases where toggle initial break wasn’t usable when the target isn't broken in
If you hit tab in the command window with nothing available, the cursor will now stay in the input field
WinDbgNext will now auto-detect bitness when opening CAB files

1.0.1804.18003
This version includes these updates.
Symbol status and cancellation improvements - There are time where the debugger display BUSY loading
symbols and it’s difficult to determine what it’s doing and why without !sym noisy enabled. We’ve updated
WinDbg Preview to have some better communication around what it’s doing when loading symbols to help
troubleshoot any issues. In addition to easily seeing exactly what’s happening, we’ve made some changes that
should make cancelling symbols more reliable and the Logs window will contain some of the details that’s
normally output when !sym noisy is enabled. If you hit View -> Logs you’ll get the full noisy symbol loading
output without having to turn it on and attempt to reload the symbols.
Experimental notes window - WinDbg Preview now has a window for taking notes. Just hit View -> “Notes”
to open it. If you copy/paste into it, DML links will be preserved and still work as if it was the command window.
You can also save and load notes files from the “Notes” ribbon when the window is open.
Experimental faster source window - To help improve the performance of WinDbg Preview there us a
experimental new source window that is quite a bit more efficient. There’s still a few gaps around context menus
and syntax highlighting, but we want to give everyone the option of trying it out before it’s finished to give us
early feedback. Run $UseFastSourceWindow to use it. If you want to go back to the old one, run
$UseMonacoSourceWindow. The setting will preserve across sessions, you will need to close and re-open
source windows to get the new version.
JSProvider API version 1.2 - For JavaScript extensions that declare support for API version 1.2:
Any object with a .compareTo method which exits the script will have a custom comparator on it (comparison
operators will work in the DX evaluator and elsewhere: e.g.: IModelObject::Compare)
Any object with a .equals method which exits the script will have a custom equality operator on it (== and !=
will work in the DX evaluator and elsewhere: e.g.: IModelObject::IsEqualTo)
Native or data model objects which enter the script will have .compareTo and .equals on them which allow
access to any custom comparator or custom equality implementations.
Minor changes and bug fixes:
.server will now list fully qualified domain name for easier use when there’s domain issues around short
names.
Ctrl+G now works in the source window.
Added address bar to the disassembly window.
WinDbg Preview will now handle _NT_SYMBOL_PATH in a more expected way.
Added -server command-line option.
TTD data model queries can now be displayed progressively, so if you interrupt it you’ll still see some results.
This feature is still experimental and optional. Run dx @$cursession.TTD.AsyncQueryEnabled = 1 to enable it.
The ‘dps’ command now has links to the source files it refers to.

1.1801.19001.0
This version includes these updates.
Text Highlighting - You can now highlight all instances of selected text directly in the debugger. To use this
feature, just select some text in the command window and then select “Highlight” in the command ribbon or hit
CTRL+ALT+H. Using one of those on already highlighted text will remove the highlighting.
If you prefer using commands, you can use the “$hl” command:
$hl ["someValueHere"] - Highlight give text (or un-highlight if already highlighted)
$hl clearAll – Clear all highlighted entries
$hl caseSensitive [1|0] - Set highlight matching to case sensitive or case insensitive (default is case
insensitive)
This release also includes some minor bug fixes.

1.1712.15003.0
This version includes these updates.
TTD memor y queries - You can now query TTD for memory accesses similar to how you query for calls today.
This allows you to find all of the reads, writes and execution which access a specific range of memory.
Read and write example: dx @$cursession.TTD.Memory(startAddress, endAddress, "rw")

Unique execution example: dx @$cursession.TTD.Memory(startAddress, endAddress, "ec")

Settings changes - WinDbg Preview will now automatically save settings between sessions, including your
symbol path and source path.
JavaScript Improvements
64-bit numbers and numerics in JavaScript now contain a modulo method allowing a true 64-bit modulo
operation.
Objects defined in JavaScript can now implement a custom comparable or equatable notion which will work
in dx using standard C++ operators or in LINQ operations. In order to utilize this, the script must declare in
the initializeScript array that it supports a new version of the host API by inserting a record “new
host.apiVersionSupport(1, 2)”. After you’ve done that you can use these functions in any ‘dx’ or Data Model
Window LINQ query. If the method implements .compareTo(other), it is comparable (comparison operators
work in dx and LINQ). If the method returns a negative value, such as “this < other”. If the method returns
zero, “this == other”. If the method returns a positive value “this > other”. If the method implements
.equals(other), it is equatable (== works in dx and LINQ). The method must return either true or false.
Minor changes and bug fixes:
Fixed a bug where the stack and locals windows weren’t working during boot debugging
Updated the output of LM to more accurately report ProductVersion and similar fields
Enabled the “step out back” button during TTD sessions
Added support for -lsrcpath
The headers in the locals, watch, and model windows now don’t disappear when scrolling down
When ALT+Tabbing back to WinDbg Preview, the command window will properly preserve cursor location
Added CTRL+ALT+V shortcut for toggling verbose mode
You can now disable auto-scrolling of the command window by selecting and holding (or right-clicking) the
command window tab and choosing “turn off auto scrolling”
You can now debug child processes through the launch executable advanced page.

1.0.14.0
This version includes these updates.
Improved process ser ver experience - A new notification in the File menu to show what process server
you’re connected to and interacting with has been added. As part of these changes, when ending a debugging
session, the process server connection will persist and can be disconnected in the File menu.
New pre-set layout options in the View ribbon - There is a new “Layouts” option in the “View” ribbon.
There are currently three layouts: the default, one focused on disassembly, and one minimal.
Time Travel Debugging ribbon - There is an enhanced Time Travel ribbon that will show up when debugging
a time travel debugging trace.
Metadata from JavaScript scripts - JavaScript extensions can now return metadata for properties and other
constructs. This means that the extension can provide help strings, indicate the display radix for values, and
more. Metadata is provided by placing a metadata descriptor on an object via either presence of
Symbol.metadataDescriptor or an explicit call to host.metadata.defineMetadata. Function returns, iterated values,
and other value contexts can return metadata for their value via host.metadata.valueWithMetadata.
JavaScript API updates - Some potentially source level breaking changes were made to the APIs within the
JavaScript provider (including new projected methods and properties on native objects). Existing extensions will
not see any of the potentially breaking changes without indicating that they support a new version of the
JsProvider API. Support for the new API version is indicated by placing a host.apiVersionSupport record in the
array returned by initializeScript with a claim of supporting version 1.1. maybe? .. with a value indicating
support for version 1.1.
Changes in API version 1.1 include:
host.getModuleSymbol and host.getModuleType return null if they cannot find the symbol instead of
throwing an exception.
All native objects have the address property on them in addition to .targetLocation. If the object does not
have an address, an exception will be thrown when accessing the property.
All native objects have new .getObjectValue and .setObjectValue methods on them to access properties on
the object which may conflict with names JavaScript places on the object (e.g.: ‘address’) .
Additional JavaScript changes
JavaScript extensions can now add and remove properties on data model objects via Object.defineProperty
and the delete operator. Adding or registering a JavaScript class as a parent model or type signature is still
the strongly preferred way of manipulating the object model.
JavaScript extensions can now modify global variables within modules in the debug target through a new
host.setModuleSymbol API.
All of the math functions which are on the 64-bit library type (e.g.: .add, .subtract, .multiply, .divide, etc…) are
now present on JavaScript numbers as well.
JavaScript functions and properties can now return values which are enums through custom marshaling. A
function or property accessor can return host.typeSystem.marshalAs(value, type…) in order to evoke such
custom marshaling.
The breakpoint command in the script debugger can now break on function names in addition to
line/column positions.
Type objects in JavaScript extensions have access to their containing module through the .containingModule
property.
Minor changes and bug fixes:
Fixed formatting of conditional ribbon tabs to be less confusing.
Re-worked DML to be stricter in parsing to improve performance.
Various fixes with the performance and behavior of CTRL+F.
Added a warning when running un-elevated prior to trying to use TTD.
Added the option to override automatic target bitness detection.
Disabled various file menu and ribbon options when they can’t be used (like “Go” when in a dump file).
Known issues:
SOS will not work on x86 traces.

1.0.13.0
This version adds Time Travel Tracing. Time Travel Debugging, allows you to record a process, then replay it later
both forwards and backwards. Time Travel Debugging (TTD) can help you debug issues easier by letting you
"rewind" your debugger session, instead of having to reproduce the issue until you find the bug. For more
information, see Time Travel Debugging - Overview.

1.0.12.0
This version was the first release of WinDbg Preview. For general information on the features available in
WinDbg Preview, Debugging Using WinDbg Preview.

See Also
WinDbg Preview – Installation
WinDbg Preview – Command line startup options
 WinDbg Preview - Installation
6/16/2021 • 2 minutes to read • Edit Online

Installation

This section describes how to install the WinDbg Preview debugger.

The WinDbg Preview debugger is available in the Microsoft Store. It requires Windows 10 Anniversary Update
to install. To install it, open the Microsoft Store and search for "WinDbg Preview", or use the following link to
navigate directly to WinDbg Preview.
Once the app is a located, select it to download and install.

Checking for updates

1. Open the Store app and select your account picture next to the search box.
2. Select Downloads and Updates to check for updates.
3. On the downloads and updates page, select Get updates .

Debugger coexistence
The WinDbg preview coexists with the classic WinDbg debugger on the same machine, so you can work with
both versions at the same time.

See Also
Debugging Using WinDbg Preview
WinDbg Preview – Command line startup options
 WinDbg Preview - Command line startup options
6/16/2021 • 4 minutes to read • Edit Online

Starting WinDbg Preview

After WinDbg Preview is installed, WinDbgX.exe is available to run from any directory location.

Command line startup options

WinDbgX [options]

This following tables summarizes the available command line options.

General Options

O P T IO N DESC RIP T IO N

-c "command" Executes a command line after the debugger is attached.

This command must be enclosed in quotation marks.
Multiple commands can be separated with semicolons.

-v Enables verbose output in the debugger.

-T Title Sets the window title.

-logo LogFile Log Open. Begins logging information to a log file. If the file
exists, it will be overwritten.

-loga LogFile Log Append. Begins logging information to a log file. If the
file exists, it will be appended to.

-e EventHandle Signals the event with the given handle after the next
exception in a target.

-? Displays a summary of commands available.

Kernel Options

O P T IO N DESC RIP T IO N

-k [ConnectType] Starts a kernel debugging session. If -k is used without any

ConnectType options following it, it must be the final entry
on the command line.

-kqm Starts KD in quiet mode.

 O P T IO N DESC RIP T IO N

-kl Starts a kernel debugging session on the same machine as

the debugger.

-kx ExdiOptions Starts a kernel debugging session using an EXDI driver.

-d After a reboot, the debugger will break into the target

computer as soon as a kernel module is loaded.

User Mode Options

O P T IO N DESC RIP T IO N

-o Debugs all processes launched by the target application

(child processes).

-g Ignores the initial breakpoint in target application.

-G Ignores the final breakpoint in target application.

-pv Specifies that the debugger should attach to the target

process noninvasively.

-hd Specifies that the debug heap should not be used.

-cimp Specifies that any processes created will use an implicit

command-line set by the server instead of a user-given
command-line string from the client.

Target Options

O P T IO N DESC RIP T IO N

-remote ClientTransport Connects to a debugging server that is already running. For

an explanation of the possible ClientTransport values, see
Activating a Debugging Client. When this parameter is used,
it must be the first parameters on the command line.

-server ServerTransport Creates a debugging server that can be accessed by other

debuggers. For an explanation of the possible
ServerTransport values, see Activating a Debugging Server.

-premote SmartClientTransport Creates a smart client, and connects to a process server that
is already running. For an explanation of the possible
SmartClientTransport values, see Activating a Smart Client.

-p PID Specifies the decimal process ID to be debugged.

-tid TID Specifies the thread ID of a thread to be resumed when the

debugging session is started.

-psn ServiceName Specifies the name of the service contained in the process to
be debugged. This is used to debug a process that is already
running.
 O P T IO N DESC RIP T IO N

-pn ProcessName Specifies the name of the process to be debugged.

-z DumpFile Specifies the name of a crash dump file to debug. If the path
and file name contain spaces, this must be surrounded by
quotation marks.

-debugArch x86 -or- amd64 Override the autodetect behavior and set the target bitness
for the debugger.

-loadSession Load a saved session configuration file.

-setupFirewallRules Configures the required firewall rules on the local system to

allow kernel debugging using KDNET.

-openPrivateDumpByHandle Handle Microsoft internal use only. Specifies the handle of a crash
dump file to debug.

-benchmarkStartup Microsoft internal use only. Runs a startup benchmark and

appends the result to a file.

Symbol Options

O P T IO N DESC RIP T IO N

-y SymbolPath Specifies the symbol path to use. Separate multiple paths

with a semicolon (; ). If the path contains spaces, it should be
enclosed in quotation marks. For details, and for other ways
to change this path, see Symbol Path.

-n Noisy symbol load. Enables verbose output from symbol

handler.

-i ImagePath Sets the image search path to use.

-sdce Causes the debugger to display 'File access error' messages

during symbol load.

-ses Causes the debugger to perform a strict evaluation of all

symbol files and ignore any questionable symbols.

-sicv Causes the symbol handler to ignore the CV record

-sins Causes the debugger to ignore the symbol path and

executable image path environment variables.

-snc Causes the debugger to turn off C++ translation.

-snul Disables automatic symbol loading for unqualified names.

-sup Causes the symbol handler to search the public symbol table
during every symbol search

-sflags Sets all the symbol handler options at once.

Source Path Options

O P T IO N DESC RIP T IO N

-srcpath Specifies the source path to use on the debugging server.

-lsrcpath Specifies the source path to use on the local client.

If you are in a local debugger session, srcpath and lsrcpath are effectively the same (your “server” is your local
session). For remote debugging there are situtations where you may want to set these to different values. For
more information about remote debugging see, Remote Debugging.
Exception handling

O P T IO N DESC RIP T IO N

-x Enable second-chance handling only for access violation

exceptions.

-xe Exception Enable first-chance exception handling for the specified

exception.

-xd Exception Enable second-chance exception handling for the specified

exception.

-xn Exception For the given exception, disable first- and second-chance-
handling, and only display a message on the console.

-xi Exception Completely ignore the given exception, disabling first- and
second-chance handling, and not outputing anything to the
console.

For a list of exceptions that can be specified, see Event Definitions and Defaults.
Post Mor tem

O P T IO N DESC RIP T IO N

-I Sets WinDbg Preview as the default post-mortem debugger

for the system.

-IS Sets WinDbg Preview as the default post-mortem debugger

for the system silently, with only errors being reported.

Deprecated Options

O P T IO N DESC RIP T IO N

-Q Deprecated command-line option.

-QY Deprecated command-line option.

-QS Deprecated command-line option.

-QSY Deprecated command-line option.

 O P T IO N DESC RIP T IO N

-WX Deprecated command-line option.

For general information on the startup parameters, see WinDbg Command-Line Options.
You can use -? to list the supported command line options.

See Also
Debugging Using WinDbg Preview
 WinDbg Preview - Settings and workspaces
6/16/2021 • 3 minutes to read • Edit Online

This section describes how to setup and configure the WinDbg Preview debugger.

Settings
Use the settings menu to set things such as the source and symbol path as well as choose the light and dark
theme for the debugger.

There are currently six settings dialog panels:

General
Command Window
Debugging Settings
Disassembly windows
Events & exceptions
Source window
For more information on setting the paths, see Accessing Symbols for Debugging and Source Code Debugging
in WinDbg.

Workspaces
Workspaces allows you to save configuration information in the target connection information file.
The options in workspaces are saved upon closing the debugger or can be manually saved using File -> Save
Workspace.
Workspaces are automatically loaded when launching from the recent targets list or they can be manually
loaded in the file menu.
In addition to the target connection information, the following settings are stored in the workspaces file.
General Settings

NOTE
This list and format isn't final and is subject to change.

SET T IN G DEFA ULT DESC RIP T IO N

FinalBreak true If true, ignores the final breakpoint (-g

command-line option).

SourceDebugging true Toggles between source or assembly

mode.

DebugChildProcesses false (User mode only) If true will debug

child processes launched by the target
application. (-o command-line option).

Noninvasive false Specifies non-invasive attach (-pv

command-line option).

NoDebugHeap false Specifies the debug heap should not

be used (-hd command-line option).

Verbose false When verbose mode is turned on,

some display commands (such as
register dumping) produce more
detailed output. (-v command-line
option).

Elevate - Used internally by WinDbg - Do not

modify.

Restartable - Used internally by WinDbg - Do not

modify.

UseImplicitCommandLine false Use implicit command-line (-cimp

command-line option). This starts the
debugger with an implicit command
line instead of an explicit process to
run.

For more information about the command line options, see WinDbg Command-Line Options.
Symbol Settings

SET T IN G DEFA ULT DESC RIP T IO N

SymbolOptionsOverride 0 An explicit symbol option mask, in the

form of a single hex number.
 SET T IN G DEFA ULT DESC RIP T IO N

ShouldOverrideSymbolOptions false If set to true override all of the symbol

options listed below with the provided
symbol option mask, described above.

SymOptExactSymbols false This option causes the debugger to

perform a strict evaluation of all
symbol files.

SymOptFailCriticalErrors false This symbol option causes file access

error dialog boxes to be suppressed.

SymOptIgnoreCvRec false This option causes the symbol handler

to ignore the CV record in the loaded
image header when searching for
symbols.

SymOptIgnoreNtSympath false This option causes the debugger to

ignore the environment variable
settings for the symbol path and the
executable image path.

SymOptNoCpp false This symbol option turns off C++

translation. When this symbol option is
set, :: is replaced by __ in all symbols.

SymOptNoUnqualifiedLoads false This symbol option disables the

symbol handler's automatic loading of
modules. When this option is set and
the debugger attempts to match a
symbol, it will only search modules
which have already been loaded.

SymOptAutoPublics false This symbol option causes DbgHelp to

search the public symbol table in a
.pdb file only as a last resort. If any
matches are found when searching the
private symbol data, the public
symbols will not be searched. This
improves symbol search speed.

SymOptDebug false This symbol option turns on noisy

symbol loading. This instructs the
debugger to display information about
its search for symbols.

For more information on symbol options, see Symbol Options.

Window layout settings
Window layout is saved globally and are not saved in the workspaces file.
Workspaces XML file
The workspace and target connection information is stored in XML format.
The following file, shows an example workspaces configuration file.
 <?xml version="1.0" encoding="utf-8"?>
<TargetConfig Name="C:\paint.dmp" LastUsed="2017-08-03T21:34:20.1013837Z">
<EngineConfig />
<EngineOptions>
<Property name="FinalBreak" value="true" />
<Property name="SourceDebugging" value="true" />
<Property name="DebugChildProcesses" value="false" />
<Property name="Noninvasive" value="false" />
<Property name="NoDebugHeap" value="false" />
<Property name="Verbose" value="false" />
<Property name="SymbolOptionsOverride" value="0" />
<Property name="ShouldOverrideSymbolOptions" value="false" />
<Property name="SymOptExactSymbols" value="false" />
<Property name="SymOptFailCriticalErrors" value="false" />
<Property name="SymOptIgnoreCvRec" value="false" />
<Property name="SymOptIgnoreNtSympath" value="false" />
<Property name="SymOptNoCpp" value="false" />
<Property name="SymOptNoUnqualifiedLoads" value="false" />
<Property name="SymOptAutoPublics" value="false" />
<Property name="SymOptDebug" value="false" />
<Property name="Elevate" value="false" />
<Property name="Restartable" value="true" />
<Property name="UseImplicitCommandLine" value="false" />
</EngineOptions>
<TargetOptions>
<Option name="OpenDump">
<Property name="DumpPath" value="C:\paint.dmp" />
</Option>
</TargetOptions>
</TargetConfig>

Note that this file format continues to evolve as more features are added to the WinDbg Preview debugger.

See Also
Debugging Using WinDbg Preview
 WinDbg Preview keyboard shortcuts
6/16/2021 • 2 minutes to read • Edit Online

This section summarizes the keyboard shortcuts for the WinDbg preview debugger.
All of the ribbon menu options are available using the Alt + the first letter of the option. For example Alt + H to
go to the home menu, Alt + H + S to stop debugging.

Flow control
K EY ST RO K E DESC RIP T IO N

F5 Continue

F10 Step over

F11 Step Into

Shift+F11 Step out

F7 Run to line

Ctrl+Shift+I Set instruction pointer to highlighted line

Ctrl+Break or Alt+Del Break

Ctrl+Shift+F5 Restart

Shift+F5 Stop debugging

Alt+H,D Detach

Setup
K EY ST RO K E DESC RIP T IO N

F6 Attach to process

Ctrl+R Connect to remote

Ctrl+D Open dump file

 K EY ST RO K E DESC RIP T IO N

Ctrl+K Attach to kernel debugger

Ctrl+E Launch process

Ctrl+P Launch app package

Breakpoints
K EY ST RO K E DESC RIP T IO N

F9 Toggle breakpoint on highlighted line

Ctrl+Alt+K Toggle initial break

Alt+B,A Add breakpoint

Windowing
K EY ST RO K E DESC RIP T IO N

Ctrl+Tab Open window changer

Ctrl+1 Open/focus on command window

Ctrl+2 Open/focus on watch window

Ctrl+3 Open/focus on locals window

Ctrl+4 Open/focus on registers window

Ctrl+5 Open/focus on memory window

Ctrl+6 Open/focus on stack window

Ctrl+7 Open/focus on disassembly window

Ctrl+8 Open/focus on breakpoints window

Ctrl+9 Open/focus on thread window

Scripting
K EY ST RO K E DESC RIP T IO N

Ctrl+Shift+O Open script

Ctrl+Shift+Enter Execute script

Ctrl+S Save script

Alt+S,N New script

 K EY ST RO K E DESC RIP T IO N

Alt+S,U Unlink script

Stack navigation
K EY ST RO K E DESC RIP T IO N

Ctrl+↑ / ↓ Move up/down a stack frame

Help
K EY ST RO K E DESC RIP T IO N

F1 Open help file

Shift+F1 Search selection online (source window)

Misc.
K EY ST RO K E DESC RIP T IO N

Ctrl+Alt+V Toggle Verbose Mode

See Also
Debugging Using WinDbg Preview
 WinDbg Preview - Start a user mode session
6/16/2021 • 2 minutes to read • Edit Online

This section describes how to start a user mode session with the WinDbg preview debugger.
Select File, Start debugging, and select either of these four options:
Launch Executable - Starts an executable and attaches to it by browsing for the target.
Launch Executable (advanced) - Starts an executable and attaches to it using a set of dialog boxes with
advanced options.
Attach to a process - Attaches to an existing process.
Launch App Package - Launches and attaches to an app package.
All four options are described here.

Launch Executable
Use this option to starts an executable and attach to it.
Browse to the desired executable in the provided file dialog and open it.

Launch Executable (advanced)

Use this option to start an executable and attach to it using a set of text boxes with advanced options.
Specify the following options:
Path to the executable, such as C:\Windows\notepad.exe
Optional arguments to provide to the executable when launched
Optional start directory location
Target bitness, auto 32 or 64.
Enable Debug child process
Record with Time Travel Debugging
Attach to a process
Use this option to attach to an existing process.
Select Show process from all users to show additional processes.
Use the search box to filter down the process list, for example by searching for SystemApps.

NOTE
Items with a UAC shield will need the debugger to be elevated to attach.

Use the pull down dialog on the Attach button to select non-invasive attach.

Launch App Package

Use this option to launch and attach to an app package using either the Applications of Background Task tabs.
Use the search box to locate a specific app or background task. Use the Package Details button to display
information about the package.
See Also
Debugging Using WinDbg Preview
 WinDbg Preview - Starting a kernel mode session
6/16/2021 • 2 minutes to read • Edit Online

This topic describes how to start a kernel mode session with WinDbg Preview.
The process is very similar to how it has been done with previous versions of WinDbg. Select the tab for the
type of transport you're using, fill in the required fields, and click OK.

NOTE
Local kernel debugging requires WinDbg Preview to be launched elevated.

The Paste tab allows you to paste in custom connection strings.

If you are not familiar with setting up a debugger kernel mode session, see Getting Started with WinDbg
(Kernel-Mode)

See Also
Debugging Using WinDbg Preview
 WinDbg Preview - Start a remote, process server
and dump file session
6/16/2021 • 2 minutes to read • Edit Online

This section describes how to start a remote, process server and dump file session with the WinDbg preview
debugger.

Remote Debug Server

Use this option to connect to a remote debugging server.

Remote debugging involves two debuggers running at two different locations. The debugger that performs the
debugging is called the debugging server. The second debugger, called the debugging client, controls the
debugging session from a remote location. To establish a remote session, you must set up the debugging server
first and then connect to it with the the debugging client.
For more information about remote sessions, see Remote Debugging Using WinDbg.

Process Debug Server

Remote debugging through a process server involves running a small application called a process server on the
server computer. Then a user-mode debugger is started on the client computer. Since this debugger will be
doing all of the actual processing, it is called the smart client.
For more information about process server sessions, see Process Servers (User Mode).

Open a dump file

To open a dump file, browse to the desired file in the provided file dialog and open it.
For more information about the different types of dump files, see Analyze crash dump files by using WinDbg.

See Also
Debugging Using WinDbg Preview
 WinDbg Preview - File Menu
6/16/2021 • 2 minutes to read • Edit Online

This topic describes how to how to use the file menu.

Start debugging
When you first open the file menu, you'll see Start debugging and your recent debugger targets. Use Start
debugging to configure new and open previous debugger sessions.
Recent
The recent list contains a list of your recent workspaces and debugger connections. For more information on
working settings an workspaces see WinDbg Preview Setup – Settings and workspaces.
You can use the right click menu to manage your workspaces, like pinning, renaming and moving them. As well
as editing them in notepad.

Start a new session

Use the other tabs in the Start debugging section to start a new debugger session, like attaching or launching a
process. For more information on starting a new session see WinDbg Preview - Start a user-mode session and
WinDbg Preview - Start a kernel mode session
Save workspace
Use Save workspace to save the current workspace.
Session connection information is stored in workspace configuration files. Workspace files are stored with a
.debugTarget file extension.
The default location for workspace files is:

C:\Users\*UserName*\AppData\Local\DBG\targets

Open source file

Use Open source file to open a source file. Do this when you want to work with additional source files that have
not been loaded because of code execution. For more information on working with source files, see Source Code
Debugging in WinDbg
Open script
Use Open script to open an existing Javascript or NatVis script. For more information on working with scripts
see WinDbg Preview - Scripting Menu.
Settings
Use the settings menu to set the source and symbol path as well as choose the light and dark theme for the
debugger. For more information on settings see WinDbg Preview Setup – settings and workspaces.
About
Use About to display build version information for the debugger. You can use also use this screen to view the
Microsoft privacy statement.
Exit
Use Exit to exit the debugger.

See Also
Debugging Using WinDbg Preview
 WinDbg Preview - Home Menu
6/16/2021 • 2 minutes to read • Edit Online

This topic describes how to work with the home menu.

Flow Control
Use the Flow Control buttons to break into a connected debugging target, resume code execution on the target
and step in to and out of code.

Reverse Flow Control

Use the Reverse Flow Control buttons to travel back in time. For more information, see Time Travel Debugging -
Overview.

End
Use the End buttons to restart, detach and stop debugging.

Preferences
Use Preferences buttons to toggle between source code and assembly views and to access the Settings menu.

Help (Support)
Use Help buttons to do the following:
Review Local Help - Offline
Online Help - Most up to date
Feedback Hub
Send Feedback (For more information on sending feedback to improve WinDbg, see Providing feedback.)

See Also
Debugging Using WinDbg Preview
 WinDbg Preview - View Menu
6/16/2021 • 2 minutes to read • Edit Online

This section describes how work with the view menu in WinDbg Preview.

The view menu will open a new Window for each item, or bring focus to the existing Window, if one is already
open.

Command
The command Window allows you to enter debugger commands. For more information about debugger
commands, see Debugger Commands.

Watch
The watch Window allows you to watch local variables and registers.
The locals and watch windows are both based off of the data model that is used by the dx command. This means
the locals and watch windows will benefit from any NatVis or JavaScript extensions you have loaded, and
support full LINQ queries, just like the dx command. For more information about the data model, see WinDbg
Preview - Data Model.

Locals
The locals window displays information about all of the local variables in the current scope. The locals window
will highlight values that have changed during the previous code execution.

Registers
Registers displays the contents of the processors registers when they are available. For more information about
registers, see Registers and Viewing and Editing Registers in WinDbg.

Memory
Use the memory window to display memory locations. In addition to providing a memory address, you can use
the Pseudo-Register values such as $scopeip and $eventip to examine memory. Pre-append the @ symbol to
use the pseudo-register values in the memory window, for example, @$scopeip . For more information, see
Pseudo-Register Syntax

Stack
Use the stack Window to view the current call stack. The stack window provides basic highlighting of the current
frame.

Disassembly
The disassembly window highlights the current instruction and retains that position when you scroll.

Threads
The threads window highlights the current thread.

Breakpoints
Use the breakpoints window to view, enable and clear breakpoints.

Logs
This log is of the WinDbg Preview internals. It can be viewed to monitor long running processes and for
troubleshooting the debugger itself.
You can continue to create a traditional debugger command log, using the .logopen command. For more
information on that, see Keeping a Log File in WinDbg.
Notes
Use the Notes option to open a note taking window.

Timelines
Use Timelines to open or bring focus to the timelines window. For more information on timelines, see WinDbg
Preview - Timelines.

Modules
Use modules to display loaded modules and their related information. Modules displays the following:
The name of the module including the path location
The size in bytes of the loaded module
The base address that the module is loaded at
The file version

Layouts
Use the Layouts pull down menu to select from three window layouts.

Reset Windows
Use this function to reset the debugger windows to their default positions.

Accent Color
Use the pull down menu to set the accent color for the debugger.

See Also
Debugging Using WinDbg Preview
 WinDbg Preview - Breakpoints Menu
6/16/2021 • 2 minutes to read • Edit Online

This section describes how to work with breakpoints using the WinDbg preview debugger.

Breakpoints Menu
Use the breakpoints menu to create new and remove existing breakpoints as well as toggle the initial breakpoint
(initial breakpoint is currently kernel only).

Breakpoints Window
Use the breakpoints window, opened via the View menu, to view, set and clear breakpoints. You can also double-
click a breakpoint to open its source file.

The breakpoint window keep a running total of each time the breakpoint is hit.
The general process of working with breakpoints is similar to previous versions of WinDbg. For more
information about setting breakpoints, see Setting Breakpoints in WinDbg.
 WinDbg Preview - Time Travel Menu
6/16/2021 • 2 minutes to read • Edit Online

This section describes how work with the time travel menu in WinDbg Preview.

For more information about time travel see Time Travel Debugging - Overview.

Trace
Index Trace
Use the Index Trace option to force a re-index of a time travel trace.
Events
Use the Events pull down to display either Exceptions or Module load events.

Position
Time travel to start
Use Time travel to start to move to the start of a time travel trace file.
Time travel to end
Use Time travel to start to move to the end of a time travel trace file.

Misc
Information
Use Information to display information about the trace, such as size and number of threads.
Timelines
Use the to Timelines option to access debugger timelines. For more information see WinDbg Preview Timelines.

See Also
Debugging Using WinDbg Preview
 WinDbg Preview - Data Model Menu
6/16/2021 • 2 minutes to read • Edit Online

This section describes how to work with the data model menu in the WinDbg Preview debugger.

New Model Query

Use the New Model Query dialog to create a new model query. You can put anything here you'd put into a
normal dx command.
For example, specify Debugger.Sessions to examine the debugger sessions objects.

For general information about the debugger objects refer to dx (Display Debugger Object Model Expression).
Use LINQ queries to dig deeper into the session. This query shows the top 5 processes running the most
threads.

Debugger.Sessions.First().Processes.Select(p => new { Name = p.Name, ThreadCount = p.Threads.Count()

}).OrderByDescending(p => p.ThreadCount),5

Data Model Explorer

Use the data model explorer to quickly browse every data model object in the Debugger namespace.
Display Mode
Use display mode to toggle between grid and hierarchy display mode. You can right-click column headers to
hide or show more columns.
Grid mode can be useful to dig down in the objects. For example, here is the previous top threads query in grid
view.

When you click on any underlined item a new tab is opened and a query is run to display that information.
This query shows the devices in the plug and play device tree grouped by the name of the physical device
object's driver for a kernel session.

Debugger.Sessions.First().Devices.DeviceTree.Flatten(n => n.Children).GroupBy(n => n.PhysicalDeviceObject-

>Driver->DriverName.ToDisplayString())
Change Query
Use change query to change the query that is used in the active data model window.

See Also
dx (Display Debugger Object Model Expression)
Debugging Using WinDbg Preview
 WinDbg Preview - Scripting Menu
6/16/2021 • 2 minutes to read • Edit Online

This section describes how to use the scripting support in the WinDbg Preview.

The WinDbg Preview script window features basic syntax highlighting, IntelliSense, and error recognition.
Use the ribbon buttons to:
Create a new script
Open an existing script
Execute a script
Save a script
Unlink a script
You can also automatically execute scripts by right-clicking in the script window and selecting Execute Script on
Save. When you successfully load a script, a green check box will appear on the script title bar. If there are errors
in the script, a red x will be displayed.

JavaScript Scripting
To start using JavaScript, you must first be debugging a target. When you're ready to start working on your
JavaScript, click "Load JavaScript Provider". After that you can create a new JavaScript, by picking between these
two types of script templates.
Extension Script - A script which is designed to act as an extension to the debugger. It manipulates the
object model of the debugger and provides continued functionality. No action happens upon hitting the
Execute button on the ribbon.
Imperative Script - A script which is designed to perform an action each and every time the Execute
button is clicked on the ribbon. Such a script does not generally modify the object model of the debugger.
For more information about working with JavaScript, see these topics:
JavaScript Debugger Scripting
Native Debugger Objects in JavaScript Extensions
JavaScript Debugger Example Scripts

NatVis Scripting
Use New Script > NatVis to open the following blank NatVis template.
 <AutoVisualizer xmlns="https://schemas.microsoft.com/vstudio/debugger/natvis/2010">
<Type Name="">
</Type>
</AutoVisualizer>

For more information about working with NatVis, see Debugger Objects in NatVis.

See Also
Debugging Using WinDbg Preview
 WinDbg Preview - Notes, Command, Memory and
Source Menus
1/17/2020 • 2 minutes to read • Edit Online

This section describes how work with the Notes, Command, Memory and Source menus in WinDbg Preview.

Notes
Use the menu to:
Open a notes file
Save a notes file

Command
Use the command menu to:
Prefer DML
Highlight and Un-highlight the current text selection (CTRL+ALT+H)
Clear the command window text
Save window text to a dml file

Memory
Use the memory menu to:
Set a data model memory query
Set the memory size, for example to byte or long
Set the display format, for example hex or signed
Set the text display format, for example to ASCII

Source
Use the source menu to:
Open a source file
Set an instruction pointer
Run to cursor
Close all source windows

See Also
Debugging Using WinDbg Preview
 WinDbg Preview Basics
6/16/2021 • 2 minutes to read • Edit Online

T IT L E DESC RIP T IO N

WinDbg Preview - What's New What's new with WinDbg Preview

The debugger data model

T IT L E DESC RIP T IO N

dx command Interactive command to display a debugger object model

expression

Using LINQ With the debugger objects SQL like query language

Native Debugger Objects in NatVis Using the objects with NatVis

WinDbg Preview - Data model How to use the built in data model support in WinDbg
Preview

Extending the data model

T IT L E DESC RIP T IO N

JavaScript Debugger Scripting How to use JavaScript to create scripts that understand
debugger objects

WinDbg Preview - Scripting Using the WinDbg Preview built in scripting

https://github.com/Microsoft/WinDbg-Samples The debugger team GitHub site where they share the latest
JavaScript (and C++) sample code.

Native Debugger Objects in JavaScript Extensions Describes how to work with common objects and provides
reference information on their attributes and behaviors.

TTD Basics
T IT L E DESC RIP T IO N

Time Travel Debugging - Overview TTD Overview

Time Travel Debugging - Sample App Walkthrough To give time travel a try checkout this tutorial
TTD queries
T IT L E DESC RIP T IO N

Introduction to Time Travel Debugging objects. You can use the data model to query time travel traces.

https://github.com/Microsoft/WinDbg- A tutorial on how to debug C++ code using TTD queries to

Samples/blob/master/TTDQueries/tutorial-instructions.md find the problematic code

https://github.com/Microsoft/WinDbg- All of the code used in the lab is available here.

Samples/tree/master/TTDQueries/app-sample

Videos
Watch these episodes of Defrag Tools to see Windbg Preview in action.

T IT L E DESC RIP T IO N

Defrag Tools #182 Tim, Chad, and Andy go over the basics of WinDbg Preview
and some of the features

Defrag Tools #183 Nick, Tim, and Chad use WinDbg Preview and go over a
quick demo

Defrag Tools #184 Bill and Andrew walk through the scripting features in
WinDbg Preview

Defrag Tools #185 James and Ivette provide and introduction to Time Travel
Debugging

Defrag Tools #186 James and JCAB covers advanced Time Travel Debugging

Installation and getting connected

T IT L E DESC RIP T IO N

WinDbg Preview – Installation Installation directions

WinDbg Preview – Start a user-mode session User Mode

WinDbg Preview – Start a kernel mode session Kernel Mode

 Time Travel Debugging - Overview
6/16/2021 • 7 minutes to read • Edit Online

What is Time Travel Debugging?

Time Travel Debugging, is a tool that allows you to record an execution of your process running, then replay it
later both forwards and backwards. Time Travel Debugging (TTD) can help you debug issues easier by letting
you "rewind" your debugger session, instead of having to reproduce the issue until you find the bug.
TTD allows you to go back in time to better understand the conditions that lead up to the bug and replay it
multiple times to learn how best to fix the problem.
TTD can have advantages over crash dump files, which often are missing the code execution that led up to the
ultimate failure.
In the event you can't figure out the issue yourself, you can share the trace with a co-worker and they can look at
exactly what you're looking at. This can allow for easier collaboration than live debugging, as the recorded
instructions are the same, where the address locations and code execution will be different on different PCs. You
can also share a specific point in time to help your co-worker figure out where to start.
TTD is efficient and works to add as little as possible overhead as it captures code execution in trace files.
TTD includes a set of debugger data model objects to allow you to query the trace using LINQ. For example, you
can use TTD objects to locate when a specific code module was loaded or locate all of the exceptions.

Comparison of Debugging Tools

This table summarizes the pros and cons of the different debugging solutions available.

A P P RO A C H P RO S C ONS

Live debugging Interactive experience, sees flow of Disrupts the user experience, may
execution, can change target state, require effort to reproduce the issue
familiar tool in familiar setting. repeatedly, may impact security, not
always an option on production
systems. With repro difficult to work
back from point of failure to determine
cause.

Dumps No coding upfront, low-intrusiveness, Successive snapshot or live dumps

based on triggers. provide a simple “over time” view.
Overhead is essentially zero if not
used.

Telemetry & logs Lightweight, often tied to business Issues arise in unexpected code paths
scenarios / user actions, machine (with no telemetry). Lack of data
learning friendly. depth, statically compiled into the
code.

Time Travel Debugging (TTD) Great at complex bugs, no coding Large overhead at record time. May
upfront, offline repeatable debugging, collect more data that is needed. Data
analysis friendly, captures everything. files can become large.

TTD Availability
TTD is available on Windows 10 after installing the WinDbg Preview app from the Store. WinDbg Preview is an
improved version of WinDbg with more modern visuals, faster windows, a full-fledged scripting experience,
with built in support for the extensible debugger data model. For more information on downloading WinDbg
Preview from the store, see Debugging Using WinDbg Preview.

Administrator rights required to use TTD

To use TTD, you need to run the debugger elevated. Install WinDbg Preview using an account that has
administrator privileges and use that account when recording in the debugger. In order to run the debugger
elevated, select and hold (or right-click) the WinDbg Preview icon in the Start menu and then select More > Run
as Administrator.

Video Training
To learn more about TTD see these videos.
Defrag Tools 185 - Ivette and JamesP go over the basics of TTD and demo some features in WinDbg Preview
Defrag Tools 186 - Jordi and JCAB demo more great features of TTD in WinDbg Preview
CppCon (YouTube) - Jordi, Ken and JamesM presented TTD in WinDbg Preview at CppCon 2017

Trace file basics

Trace file size
The trace file can get big and the user of TTD needs to make sure that there is adequate free space available. If
you record a program for even a few minutes, the trace files can quickly grow to be several gigabytes. TTD does
not set a max