That’s kinda beside the point then, if you want to do Windows debugging. Or am I missing something?

Like you said, running over a stream of events, states and data for that debugging scenario is probably way more helpful. It would also be great to prime the context with business rules and history for the company. Otherwise LLMs will make the same mistake devs make, not knowing the "why" something is and thinking the "what" is most important.

I'm looking at this as a better way to get the humans pointed in the right direction. Ariana.dev looks interesting!

These kind of demos were cool 2 years ago - then we got function calling in the API, it became super easy to build this stuff - and the reality hit that LLMs were kind of shit and unreliable at using even the most basic tools. Like oh woow you can get a toy example working on it and suddenly it's a "natural language interface to WinDBG".

I am excited about progress in this front in any domain - but FFS show actual progress or something interesting. Show me an article like this [1] where the LLM did anything useful. Or just show what you did that's not "oh I built a wrapper on a CLI" - did you fine tune the model to get better performance ? Did you compare which model performs better by setting up some benchmark and found one to be impressive ?

I am not shitting on OP here because it's fine to share what you're doing and get excited about it - maybe this is step one, but why the f** is this a front page article ?

[1]https://cookieplmonster.github.io/2025/04/23/gta-san-andreas...

Just had a quick look at the code: https://github.com/svnscha/mcp-windbg/blob/main/src/mcp_serv...

I might be wrong, but at first glance I don't think it is only using those 4 commands. It might be using them internally to get context to pass to the AI agent, but it looks like it exposes:

    - open_windbg_dump
    - run_windbg_cmd
    - close_windbg_dump
    - list_windbg_dumps

    elif name == "run_windbg_cmd":
        args = RunWindbgCmdParams(**arguments)
        session = get_or_create_session(
            args.dump_path, cdb_path, symbols_path, timeout, verbose
        )
        output = session.send_command(args.command)
        return [TextContent(
            type="text",
            text=f"Command: {args.command}\n\nOutput:\n```\n" + "\n".join(output) + "\n```"
        )]

After that, all that is required is interpreting the results and connecting it with the source code.

Still impressive at first glance, but I wonder how well it works with a more complex example (like a crash in the Windows kernel due to a broken driver, for example)

Analyzing crash dumps is a small part of my job. I know enough to examine exception context records and associated stack traces and 80% of the time, that’s enough. Bruce Dawson’s blog has a lot of great stuff but it’s pretty advanced.

I’m looking for material to help me jump that gap.

It definitely does allow models to do more.

However, the high-level planning, reflection and executive function still aren't there. LLMs can nowadays navigate very complex tasks using "intuition": just ask them to do the task, give them tools, and they do a good job. But if the task is too long or requires too much information, the context length deteriorates the performance significantly, so you have to switch to a multi-step pipeline with multiple levels of execution.

This is, perhaps unexpectedly, where things start breaking down. Having the LLM write down a plan lossily compresses the "intuition", and LLMs (yes, even Gemini 2.5 Pro) cannot understand what's important to include in such a grand plan, how to predict possible externalities, etc. This is a managerial skill and seems distinct from closed-form coding, which you can always RL towards.

Errors, omissions, and assumptions baked into the plan get multiplied many times over by the subsequent steps that follow the plan. Sometimes, the plan heavily depends on the outcome of some of the execution steps ("investigate if we can..."). Allowing the "execution" LLM to go back and alter the plan results in total chaos, but following the plan rigidly leads to unexpectedly stupid issues, where the execution LLM is trying to follow flawed steps, sometimes even recognizing that they are flawed and trying to self-correct inappropriately.

In short, we're still waiting for an LLM which can keep track of high-level task context and effectively steer and schedule lower-level agents to complete a general task on a larger time horizon.

For a more intuitive example, see how current agentic browser use tools break down when they need to complete a complex, multi-step task. Or just ask Claude Code to do a feature in your existing codebase (that is not simple CRUD) the way you'd tell a junior dev.

Domain expertise remains crucial though. As complexity increases, you need to provide guidance to the LLM. However, when the model understands specialized tools well - like WinDBG in my experience - it can propose valuable next steps. Even when it slightly misses the mark, course correction is quick.

I've invested quite some time using WinDBG alongside Copilot (specifically Claude in my configuration), analyzing memory dumps, stack frames, variables, and inspect third-party structures in memory. While not solving everything automatically, it substantially enhances productivity.

Consider this as another valuable instrument in your toolkit. I hope tool vendors like Microsoft continue integrating these capabilities directly into IDEs rather than requiring external solutions. This approach to debugging and analysis tools is highly effective, and many already incorporate AI capabilities.

What Copilot currently lacks is the ability to configure custom Agents with specific System Prompts. This would advance these capabilities significantly - though .github/copilot-instructions.md does help somewhat, it's not equivalent to defining custom system prompts or creating a chart participant enabling Agent mode. This functionality will likely arrive eventually.

Other tools already allowing system prompt customization might yield even more interesting results. Reducing how often I need to redirect the LLM could further enhance productivity in this area.

The whole point of this was me chatting with Copilot about a crash dump and I asked him about what the command for some specific task is, because I didn't remember and it suggested me which commands I could further try to investigate something and I was like - wait, what if I let him do this automatically?

That's basically the whole idea behind. Me being too lazy to copy-paste Copilot's suggestions to my WinDBG and while this was just a test at first, becoming a proof of concept and now, almost overnight got quite a lot of attention. I am probably excited the same way as you are.

A disassembler takes compiled binaries and displays the assembly code the machine executes.

A decompiler translates the disassembled code back to pseudocode (e.g. disassembly -> C).

A debugger lets you step through the disassembly. Windbg is a debugger which is pretty powerful, but has the downside of a pretty unintuitive syntax (but I'm biased coming from gdb/llvm debuggers).

Both the MCP servers can probably be used together, but they both do different things. A neat experiment would be to see if they're aware of each other and can utilize each other to "vibe reverse"