WinDbg-Samples: extending the debugger with JavaScript, data model and TTD scripts

A sample shelf for the WinDbg extension surface

WinDbg-Samples is a collection of extensions and sample scripts for extending WinDbg, published by Microsoft, with the primary language listed as C++ and the licence at MIT. The project describes itself plainly: it is a collection of extensions and sample scripts, and more samples and extensions will be added over time.

That framing matters for what you should expect. There is no packaged product here, no installer and no release. The repository has no GitHub releases, so the way to consume it is to clone it, open the folder you need and read the code. The last push was on 2026-10-15, so the collection is still being worked on, but it moves without version tags.

The audience is narrow and specific: developers debugging on Windows who want to extend the debugger rather than just use it. A native debugger extension, a JavaScript script, a data model type, a time travel query. Each of those has a learning curve, and the repository exists to shorten it by showing a working example you can adapt.

For the file layout, the top level of the repository is the map. It holds .gitignore, CONTRIBUTING.md, a CodeFlow directory, DataModelHelloWorld, DbgX, Exdi, FileSystem, ImageInfo, Manifest, SyntheticTypes, TTD, TTDQueries, TargetComposition, a LICENSE file, a SECURITY.md, a Third Party Notices.txt file and the README itself. The individual sample folders carry the detail, and the project states that each script has its own README with more detailed usage information.

Loading a JavaScript extension into a live session

The Getting Started section gives a five step procedure, and it is short enough to follow exactly.

Download the script file locally. Ensure you have a recent version of WinDbg, which the project links from aka.ms/WinDbg. Start your debugging session. The JavaScript extension, called JSProvider, should load automatically, and you validate this by running the .scriptproviders command and checking whether JavaScript is on the list. If it is not there, you load it yourself:

.load jsprovider

Finally you run either of two commands, one to load a script into the session and one to run it:

.scriptload <path to script>
.scriptrun <path to script>

The distinction between those two is worth internalising. .scriptload brings the script into the debugger so its commands and functions become available, and .scriptrun executes it. A script that defines a command therefore has to be loaded before that command can be typed, which is a different workflow from a script whose whole purpose is to do one thing when run.

One practical note on the paths. The commands take a path to the script, and the project frames the whole flow around scripts you have downloaded locally, so the path has to be one the debugger can read on your machine. The repository does not describe any packaging or signing step for a script before you load it.

.scriptproviders is the check that saves the debugging session

One command in that procedure earns its own attention, because it is the difference between a working script and a mystery.

.scriptproviders lists the script providers currently loaded in the session. The project uses it as the validation step for the automatic loading of JSProvider, and suggests .load jsprovider as the fallback when JavaScript does not appear in the list.

That fallback matters because the automatic load depends on the debugger you are running. The procedure assumes a recent version of WinDbg, and the repository does not document which versions ship the provider by default or what the failure looks like on an older build. Having .scriptproviders in your fingers means you can answer the question in one line instead of guessing at whether the problem is the provider, the path, or the script itself.

The ordering in the documented procedure also encodes a sensible debugging habit. Check the provider first, then load the script, then run it. Skipping to the third step when the first one has not been confirmed is how people end up concluding that a sample is broken when the extension host was never running.

The Scripting ribbon runs scripts without the command line

There is a second path to the same scripts, and for anyone who does not want to memorise debugger commands it is the friendlier one.

The project explains that if you want to learn more about a script, you can open it in WinDbg by hitting the Scripting ribbon and clicking Open Script. It notes that this view has intellisense support for JavaScript and for NatVis, and that you can load a script by hitting Execute in the scripting ribbon.

The intellisense point is the substantive one. A data model visualisation in JavaScript is written against a fairly wide API surface, and having completion and signature information while editing turns a documentation lookup into an inline hint. NatVis support in the same editor means the same workflow applies to the visualisers, where the object model is described in XML and the data model in JavaScript.

So there are two usable modes. The command line, with .scriptload and .scriptrun, for a session where you already know the script and want to get on with the debugging. The ribbon, for a script you are still learning and want to read with completion support. Neither replaces the other, and the project describes both.

For the wider reference, the project points to the Microsoft documentation on JavaScript support for the debugger, hosted on learn.microsoft.com, as the place with more background on how the scripting host itself works.

Folder names that map the extension surface

The top level layout of the repository is the clearest description of what kinds of extension exist for WinDbg, because the directory names are descriptive.

There are directories named CodeFlow, DataModelHelloWorld, DbgX, Exdi, FileSystem, ImageInfo, SyntheticTypes and TargetComposition, alongside the two debugging scenario folders TTD and TTDQueries. Each name points at a different extension mechanism or area of the debugger: a data model hello world, synthetic types, target composition, and the DbgX extension model are four distinct surfaces, and Exdi points at the older EXDI extension model for the kernel debugger.

That is as far as the top-level documentation goes. The project does not describe what each directory contains or how the samples differ from one another, and the README says the detail is in the per script README. Anyone assessing this repository for a specific need should therefore look at the individual folders rather than the index.

What the layout does tell you is the shape of the surface area. The extension points are not a single mechanism with different options, they are several distinct models, which is exactly why a repository of worked examples is useful in the first place. A contributor adding to the collection would be adding to one of these models rather than inventing a new one.

Time travel debugging scenarios sit beside the extension samples

Two of the top level directories are named TTD and TTDQueries, which points at time travel debugging examples in the collection, and it is the part of the repository that differs most from the rest.

The other directories hold extensions, in other words things that extend the debugger itself. A TTDQueries folder suggests a different kind of artifact: recorded or reusable queries against a time travel session, which are answers to questions rather than instruments for asking them.

If that reading is right, the distinction is useful. An extension changes what the debugger can do, permanently, for anyone who loads it. A saved query captures one investigation, reproducible by anyone with the same trace, and inert until someone runs it. Both belong in a debugging workflow, and they have different risk and reuse profiles.

It has to be said that the repository does not document these folders. Nothing published here states what TTD contains, whether the traces are included, or how the queries are meant to be run against a recording. If time travel debugging is your reason for looking at this repository, the individual folder is where the answer is, and you should expect to read code rather than documentation.

Fixes are welcome, new samples are not

The contribution policy is unusual enough to read twice. The project states that all the samples and extensions it publishes are open to contributions of fixes and improvements, and that at this point it is not open to accepting new scripts and extensions from the community. The suggested alternative is to make your own repository and share them that way.

In practice that means the repository is a curated set rather than a community dumping ground. If you have found a bug in one of the published samples, a fix is welcome. If you have written a new extension, you publish it yourself and the relationship between your work and the official collection is one of reference rather than of upstream merge.

For an engineer deciding whether to build on this, the practical effect is that you should treat every sample as reference code that you copy and adapt rather than as a dependency you import. Nothing here is packaged, versioned or released, so there is no upgrade path and no compatibility promise to track. The licence is MIT and the LICENSE file sits at the root of the repository, which is permissive enough for most uses, and the presence of a Third Party Notices.txt file alongside it means you should read that too, since samples that pull in third party components can carry terms of their own.

The SECURITY.md file is another sign of how the project is run. It is the right place to look before filing anything about a problem in a sample.

Editorial conclusion

WinDbg-Samples suits developers who already use WinDbg and want a working reference for a specific extension technique, particularly in the data model, synthetic types and time travel debugging areas, and who can read the per script README that carries the actual usage detail. It is the wrong choice if you want a supported tool with a release channel, since the repository publishes no releases and the samples are reference code, and the wrong choice if you need to submit a new extension upstream, because the project states it is not accepting new scripts and extensions at the moment. Verify three things before you depend on any of it: that your WinDbg version is recent enough to ship the JavaScript provider, that the sample you need still matches the debugger you run, and that the Third Party Notices.txt file does not impose terms that conflict with your own build.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. microsoft/WinDbg-Samples on GitHub
4. README