Dump analysis with Claude AI

WINDBG
1

Hello,

Did anyone try analyzing a full memory dump with claude ?

I just tried it, not with an installed agent on my computer, but just asking him how to proceed and feeding it the results of the commands, for system freeze, and driver crashes, and it seems to be doind really well !

I would have never tought that it could perform so well at doing this...

Do any of you use it ? If so do you still need to check if it is wrong or not ?

2

Yes, it's gotten quite good. Last week I pointed it to a dump and to cdb.exe and in a minute it had diagnosed the crash. Symbols were already configured.

A bit sad really, after spending so many years practicing crash dump analysis. But also less frustrating. When it works. :joy:

Alnoor

3

I've been using Claude for both analysis of memory dump files (kernel-mode & process dumps) with excellent results for about 5 months now. If I ensure that it's provided with the relevant PDB symbol files and source code, it does a fantastic job of tearing through the dump file contents, decoding it, analyzing it and presenting meaningful findings. There is an MCP available on GitHub which allows Claude to use cdb.exe to directly access a '.dmp' file to facilitate the dump file analysis.

In the case of performing live debugging, it's also been very good at providing commands to issue via the console for WinDbg and then taking the resulting console output via copy & paste back into Claude for analysis, or saving to a file which Claude can then read.

Using Claude in this manner has easily saved me 100+ hours of debugging effort in the past few months.

4

@chuckchopp I just started using it, so I don't know already how much accurate it is, how deep it can go into the analysis, and if it is wrong sometimes...

@Alnoor_Allidina I feel the same, spending 6 years learning this skill... the most frustrating is that I love analysing dumps, but I won't do it anymore, Claude is just way faster.

5

I've spent the last 26 years (and counting!) trying to figure out how to debug system crashes. You'd think I'd have it all figured out by now, but I'm a slow learner :joy:

I'm a heavy Claude and Codex user. The agent of your choosing can certainly run WinDbg commands and parse the output. And much like all things agent, things get more interesting/efficient if you remove the meat proxy and allow the agent to drive the debugger engine directly. Ingesting vast amounts of data is how these things are birthed so they're more than happy to collect every conceivable data point and turn it into something you can query with natural language.

My best uses cases thus far for agent + WinDbg are:

  1. Our CI system automatically copies crash dumps to a network share. If a dump happens can point the agent at it and categorize it as a new thing or something we already have a Jira ticket for
  2. Given a dump or customer issue, help come up with a repro...This can be writing test code to stress certain things or annoying IT stuff (e.g. we had an issue reported recently that only showed up with DFS configured...Claude had no problem getting that set up waaaay faster than it would have taken one of us).
  3. Writing lots and lots of tests for all the weird edge cases you can think of. Best when paired with code coverage, so you just keep having it iterate on whatever it wants to make the coverage numbers go up. Not exactly debugging, but it hopefully means fewer crashes in the future.
  4. Writing my NatVis for me! If you have complex data structures in your driver having NatVis is super helpful. But it also looks like this :cry:
      <!-- All SCBs on this volume: linked via _FE2_SCB::VolumeList -->
      <Synthetic Name="Streams">
        <DisplayString>all SCBs on volume</DisplayString>
        <Expand>
          <CustomListItems>
            <Variable Name="entry" InitialValue="StreamList.Flink"/>
            <Variable Name="count" InitialValue="0"/>
            <Loop Condition="entry != &amp;StreamList &amp;&amp; count &lt; 1000">
              <Item Name="[{count}]">
                *(_FE2_SCB*)((unsigned char*)entry - (unsigned __int64)&amp;((_FE2_SCB*)0)->VolumeList)
              </Item>
              <Exec>count = count + 1</Exec>
              <Exec>entry = entry->Flink</Exec>
            </Loop>
          </CustomListItems>
        </Expand>
      </Synthetic>

And I think the question of "is it accurate and can it be wrong" answers itself if you've used any of the models in anger. If you allow the agent to review the dump and make a patch without understanding the dump yourself you're in for a world of pain. They'll happily hallucinate and lean into a wrong solution and turn things into spaghetti. In a sealed off test environment that's fine because they can just keep iterating until they get it, but if you have a real-world crash from a client then you want to make sure you're root causing something and not just spot fixing. I spend a lot of time in my terminal sessions getting the agents to "prove their work" if you will and having them write tests to confirm assumptions.