Debugger Programming Extension APIs
This section includes:
Customizing Debugger Output Using DML
Using JavaScript to Extend the Capabilities of the Debugger
Develop KDNET transport extensibility modules
This documentation describes how to use interfaces such as those provided by the debugger engine to write extensions that will run in WinDbg, KD, CDB, and NTSD. These debugger extensions can be used when performing user-mode or kernel-mode debugging.
Debugger Engine
The debugger engine provides an interface for examining and manipulating debugging targets in user-mode and kernel-mode.
The debugger engine can acquire targets, set breakpoints, monitor events, query symbols, read and write memory, and control threads and processes in a target.
You can use the debugger engine to write both debugger extension libraries and stand-alone applications. Such applications are debugger engine applications. A debugger engine application that uses the full functionality of the debugger engine is a debugger. For example, WinDbg, CDB, NTSD, and KD are debuggers; the debugger engine provides the core of their functionality.
The debugger engine API is specified by the prototypes in the header file dbgeng.h.
For more information, see Debugger Engine Overview and Using the Debugger Engine API.
Extensions
You can create your own debugging commands by writing and building an extension DLL. For example, you might want to write an extension command to display a complex data structure.
There are three different types of debugger extension DLLs:
DbgEng extension DLLs. These are based on the prototypes in the dbgeng.h header file. Each DLL of this type may export DbgEng extension commands. These extension commands use the Debugger Engine API and may also use the WdbgExts API.
For more information, see Writing DbgEng Extensions.
EngExtCpp extension DLLs. These are based on the prototypes in the engextcpp.h and dbgeng.h header files. Each DLL of this type may export DbgEng extension commands. These extension commands use both the Debugger Engine API and the EngExtCpp extension framework, and may also use the WdbgExts API.
WdbgExts extension DLLs. These are based on the prototypes in the wdbgexts.h header file. Each DLL of this type exports one or more WdbgExts extension commands. These extension commands use the WdbgExts API exclusively. For more information see Writing WdbgExts Extensions.
The DbgEng API can be used to create extensions or stand-alone applications. The WdbgExts API contains a subset of the functionality of the debugger engine API and can be used only by extensions.
All debugger extensions should be compiled and built using Visual Studio.
Extension code samples are installed as part of the Debugging Tools for Windows package if you perform a custom installation and select the SDK component and all its subcomponents. They can be found in the sdk\samples subdirectory of the Debugging Tools for Windows installation directory.
The easiest way to write new debugger extensions is to study the sample extensions. Each sample extension includes makefile and sources files for use with the Build utility. Both types of extensions are represented in the samples.
Writing Custom Analysis Debugger Extensions
You can extend the capabilities of the !analyze debugger command by writing an analysis extension plugin. By providing an analysis extension plugin, you can participate in the analysis of a bug check or an exception in a way that is specific to your own component or application. When you write an analysis extension plugin, you also write a metadata file that describes the situations for which you want your plugin to be called. When !analyze runs, it locates, loads, and runs the appropriate analysis extension plugins. For more information, see Writing Custom Analysis Debugger Extensions
Customizing Debugger Output Using DML
You can customize debugger output using DML. For more information see Customizing Debugger Output Using DML.
Using JavaScript to Extend the Capabilities of the Debugger
Use JavaScript to create scripts that understand debugger objects and extend and customize the capabilities of the debugger. JavaScript providers bridge a scripting language to the debugger's internal object model. The JavaScript debugger scripting provider, allows the for use of JavaScript with the debugger. For more information, see JavaScript Debugger Scripting.
Develop KDNET transport extensibility modules
The KDNET transport can be extended to run on any hardware through the use of a separate hardware driver extensibility module dll. KDNET transport extensibility modules are developed by network card vendors to add kernel debugging support to specific network cards.
KDNET is a kernel debug transport that enables kernel debugging of windows over a network. It is designed so that the hardware support layer is built into a separate module from the network packet processing and kernel interface layer. This hardware driver support layer is called a KDNET extensibility module. For more information, see Develop KDNET transport extensibility modules.
Feedback
Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback.
Submit and view feedback for