A Windows Debug Adapter Protocol server
backed by the Windows debug engine (dbgeng / dbghelp). It lets DAP clients such as VS Code
debug native Windows user-mode processes (launch, attach, remote attach) and kernel targets.
C++20, CMake + Ninja, vcpkg manifest mode. Windows-only.
- Launch, attach, remote (
dbgsrv), and kernel debugging through one adapter. - Breakpoints (line + conditional), stepping (over/into/out, instruction-level), call stack, variables/scopes/registers, set variable, disassembly view, and expression evaluation via the engine.
- Native DbgEng APIs throughout - no fragile text scraping of WinDbg output.
- A built-in session-trace recorder that doubles as the project's replay-test format.
See Supported features for the full, honest list of what is and isn't advertised.
Published at svnscha.github.io/dap-dbgeng from
docs/ on every push to main. Build it locally with npm run docs (live preview) or
npm run docs:build:
Contributors: see CONTRIBUTING.md and CLAUDE.md (architecture and conventions).
The Ninja build needs the MSVC toolchain. The npm scripts enter the Visual Studio developer shell automatically, so they run from any shell:
npm run configure # configure (Ninja, vcpkg from VCPKG_ROOT)
npm run build # build DebugEquivalently, from an "x64 Native Tools for VS" prompt (so cl/link are on PATH):
cmake --preset windows-x64
cmake --build --preset windows-debugvcpkg comes from $env:VCPKG_ROOT. The developer shell sets that to the copy bundled with
Visual Studio, so no separate vcpkg install is needed; set it yourself to use a different one.
npm test # ctest --preset windows-debug
npm run test:replay # just the recorded-session replay tests
npm run test:release # configure the release tree first (npm run configure:release), then ctestThe test debuggees under test-targets/testapp always build unoptimized with full
debug info (even in Release), so their line tables and locals stay stable for the
recorded sessions and source-line assertions. Tests resolve the adapter and
debuggees relative to the test binary, so both the Debug and Release trees run
end-to-end.
The suite is unit/integration GoogleTests plus out-of-process replay tests that spawn
dap-dbgeng.exe and replay recorded sessions against the test-targets/testapp debuggees
(built as part of the tree). Tests that need dbgeng.dll or the native debuggees skip cleanly
when those are unavailable.
src/protocol/ is generated from protgen/schema/debugAdapterProtocol.json. Regenerate with
npm run generate rather than hand-editing.
test-targets/sys is a small WDK control-device kernel driver for manually exercising
kernel-mode attach. It is a separate Visual Studio + WDK build (it does not build under Ninja and is not part
of the automated tests): npm run build:sys, or configure the main tree with the VS generator and
-DDAP_DBGENG_BUILD_KERNEL_DRIVER=ON. See test-targets/sys/README.md.
pwsh scripts/Format.ps1 # changed files only (git-aware)
pwsh scripts/Format.ps1 -Path srcBugs and feature requests go through the
issue tracker (templates guide what to
include). For code changes, run npm run check and see CONTRIBUTING.md.
| Remote process | Kernel driver | Local program |
|---|---|---|
 |
 |
 |
- Install from the VS Code Marketplace
- Deep dive: Native Windows kernel and remote debugging in VS Code
- Discussion: r/vscode on Reddit
- Announcement: on LinkedIn
MIT.