AI Meets WinDBG

You should check out ChatDBG project - which AFAICT goes much further than this work, though in a different direction, and which, among other things, lets the LLM drive the debugging process - has been out since early 2023. We initially did a WinDBG integration but have since focused on lldb&#x2F;gdb and pdb (the Python debugger), especially for Python notebooks. In particular, for native code, it integrates a language server to let the LLM easily find declarations and references to variables, for example. We spent considerable time developing an API that enabled the LLM to make the best use of the debugger’s capabilities. (It also is not limited to post mortem debugging). ChatDBG’s been out since 2023, though it has of course evolved since that time. Code is here [1] with some videos; it’s been downloaded north of 80K times to date. Our technical paper [2] will be presented at FSE (top software engineering conference) in June. Our evaluation shows that ChatDBG is on its own able to resolve many issues, and that with some slight nudging from humans, it is even more effective.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;plasma-umass&#x2F;ChatDBG">https:&#x2F;&#x2F;github.com&#x2F;plasma-umass&#x2F;ChatDBG</a> (north of 75K downloads to date) [2] <a href="https:&#x2F;&#x2F;arxiv.org&#x2F;abs&#x2F;2403.16354" rel="nofollow">https:&#x2F;&#x2F;arxiv.org&#x2F;abs&#x2F;2403.16354</a>

I do a lot of Windows troubleshooting and still thinking about incorporating AI in my work. The posted project looks interesting and it&#x27;s impressive how fast it was created. Since it&#x27;s using MCP it should be possible to bind it with local models. I wonder how performant and effective it would be. When working in the debugger, you should be careful with what you send to the external servers (for example, Copilot). Process memory may contain unencrypted passwords, usernames, domain configuration, IP addresses, etc. Also, I don’t think that vibe-debugging will work without knowing what eax registry is or how to navigate stack&#x2F;heap. It will solve some obvious problems, such as most exceptions, but for anything more demanding (bugs in application logic, race conditions, etc.), you will still need to get your hands dirty.<p>I am actually more interested in improving the debugger interface. For example, AI assistant could help me create breakpoint commands that nicely print function parameters when you only partly know the function signature and do not have symbols. I used Claude&#x2F;Gemini for such tasks and they were pretty good at it.<p>As a side note, I recall Kevin Gosse also implemented a WinDbg extension [1][2] which used OpenAI API to interpret the debugger command output.<p>[1] <a href="https:&#x2F;&#x2F;x.com&#x2F;KooKiz&#x2F;status&#x2F;1641565024765214720" rel="nofollow">https:&#x2F;&#x2F;x.com&#x2F;KooKiz&#x2F;status&#x2F;1641565024765214720</a><p>[2] <a href="https:&#x2F;&#x2F;github.com&#x2F;kevingosse&#x2F;windbg-extensions">https:&#x2F;&#x2F;github.com&#x2F;kevingosse&#x2F;windbg-extensions</a>

this is pretty cool but ultimately it won&#x27;t be enough to debug real bugs that are nested deep within business logic or happening because of long chains of events across multiple services&#x2F;layers of the stack<p>imo what AI needs to debug is either:<p>- train with RL to use breakpoints + debugger or to do print debugging, but that&#x27;ll suck because chains of action are super freaking long and also we know how it goes with AI memory currently, it&#x27;s not great<p>- a sort of omniscient debugger always on that can inform the AI of all that the program&#x2F;services did (sentry-like observability but on steroids). And then the AI would just search within that and find the root cause<p>none of the two approaches are going to be easy to make happen but imo if we all spend 10+ hours every week debugging that&#x27;s worth the shot<p>that&#x27;s why currently I&#x27;m working on approach 2. I made a time travel debugger&#x2F;observability engine for JS&#x2F;Python and I&#x27;m currently working on plugging it into AI context the most efficiently possible so it debugs even super long sequences of actions in dev &amp; prod hopefully one day<p>it&#x27;s super WIP and not self-hostable yet but if you want to check it out: <a href="https:&#x2F;&#x2F;ariana.dev&#x2F;" rel="nofollow">https:&#x2F;&#x2F;ariana.dev&#x2F;</a>

Claiming to use WinDBG for debugging a crash dump and the only commands I can find in the MCP code are these ? I am not trying to be a dick here, but how does this really work under the covers ? Is the MCP learning windbg ? Is there a model that knows windbg ? I am asking becuase I have no idea.<p><pre><code> results[&quot;info&quot;] = session.send_command(&quot;.lastevent&quot;) results[&quot;exception&quot;] = session.send_command(&quot;!analyze -v&quot;) results[&quot;modules&quot;] = session.send_command(&quot;lm&quot;) results[&quot;threads&quot;] = session.send_command(&quot;~&quot;) </code></pre> You cannot debug a crash dump only with these 4 commands, all the time.

&gt; Crash dump analysis has traditionally been one of the most technically demanding and least enjoyable parts of software development.<p>I for one enjoy crashdump analysis because it is a technically demanding rare skill. I know I&#x27;m an exception but I enjoy actually learning the stuff so I can deterministically produce the desired result! I even apply it to other parts of the job, like learning to currently used programming language and actually reading the documentation libraries&#x2F;frameworks, instead of copy pasting solutions from the &quot;shortcut du jour&quot; like stack overflow yesterday and LLMs of today!

I feel like current top models (Gemini Pro 2.5 etc) would already be good developers if they had the feedback cycle and capabilities that real developers have:<p>* reading the whole source code<p>* looking up dependency documentation and code, search related blog posts<p>* getting compilation&#x2F;linter warnings ands errors<p>* Running tests<p>* Running the application and validating output (eg, for a webserver, start the server, send requests, get the response)<p>The tooling is slowly catching up, and you can enable a bunch of this already with MCP servers, but we are nowhere near the optimum yet.<p>Expect significant improvements in the near future, even if the models don&#x27;t get better.

This is one of the most exciting and practical applications of AI tooling I&#x27;ve seen in a long time. Crash dump analysis has always felt like the kind of task that time forgot—vital, intricate, and utterly user-hostile. Your approach bridges a massive usability gap with the exact right philosophy: augment, don&#x27;t replace.<p>A few things that stand out:<p>The use of MCP to connect CDB with Copilot is genius. Too often, AI tooling is skin-deep—just a chat overlay that guesses at output. You&#x27;ve gone much deeper by wiring actual tool invocations to AI cognition. This feels like the future of all expert tooling.<p>You nailed the problem framing. It’s not about eliminating expertise—it’s about letting the expert focus on analysis instead of syntax and byte-counting. Having AI interpret crash dumps is like going from raw SQL to a BI dashboard—with the option to drop down if needed.<p>Releasing it open-source is a huge move. You just laid the groundwork for a whole new ecosystem. I wouldn’t be surprised if this becomes a standard debug layer for large codebases, much like Sentry or Crashlytics became for telemetry.<p>If Microsoft is smart, they should be building this into VS proper—or at least hiring you to do it.<p>Curious: have you thought about extending this beyond crash dumps? I could imagine similar integrations for static analysis, exploit triage, or even live kernel debugging with conversational AI support.<p>Amazing work. Bookmarked, starred, and vibed.

Curious how you&#x27;re handling multi-step flows or follow-ups, seems like thats where MCP could really shine especially compared to brittle CLI scripts. We&#x27;ve seen similar wins with browser agents once structured actions and context are in place.

Author built an MCP server for windbg: <a href="https:&#x2F;&#x2F;github.com&#x2F;svnscha&#x2F;mcp-windbg">https:&#x2F;&#x2F;github.com&#x2F;svnscha&#x2F;mcp-windbg</a><p>Knows plenty of arcane commands in addition to the common ones, which is really cool &amp; lets it do amazing things for you, the user.<p>To the author: most of your audience knows what MCP is, may I suggest adding a tl;dr to help people quickly understand what you&#x27;ve done?

Built this around 2023 mid and found interesting results!

Sounds really neat!<p>How does it compare to using the Ghidra MCP server?

Watching a guy type at 30 WPM in a chatbox reminds me of those old YouTube tutorials where some dude is typing into into a notepad window, and showing you how to make a shortcut to &quot;shutdown -s -t 0&quot; on your school computer and give it the Internet Explorer icon. It&#x27;s only missing Linkin Park blasting in the background.<p>If you&#x27;re debugging from a crash dump you probably have a large, real world program, that actual people have reviewed, deemed correct and released in the wild.<p>Current LLMs can&#x27;t produce a sane program over 500 lines, the idea that they can understand a correct looking program several orders of magnitude larger, well enough to diagnose and fix a subtle issue that the people who wrote the it missed, is absurd.

My word, that&#x27;s one of the most beautiful sites I&#x27;ve ever encountered on mobile.

Considering AI is trained on the average human experience, I have a hard time believing it would be able to make any significant difference in this area. The best experience I’ve had debugging at this level was using Microsoft’s time travel debugger which allows stepping forward and back.