[JanneVee]

> Crash dump analysis has traditionally been one of the most technically demanding and least enjoyable parts of software development.

I for one enjoy crashdump analysis because it is a technically demanding rare skill. I know I'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/frameworks, instead of copy pasting solutions from the "shortcut du jour" like stack overflow yesterday and LLMs of today!

[criddell]

Are you using WinDbg? What resources did you use to get really good at it?

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.

[muststopmyths]

so, debuggers are really just tools. To get "good" at analyzing crashdumps, you have to understand the OS and its process/threading model, the ABI of the platform, a little (to a lot) of assembler etc.

There's no magic to getting good at it. Like anything else, it's mostly about practice.

People like Bruce and Raymond Chen had a little bit of a leg up over people outside Microsoft in that if you worked in the Windows division, you got to look at more dumps than you'd have wanted to in your life. That plus being immersed in the knowledge pool and having access to Windows source code helps to speed up learning.

Which is to say, you will eventually "bridge the gap" with them with experience. Just keep plugging at it and eventually you'll understand what to look for and how to find it.

It helps that in a given application domain the nature of crashes will generally be repeated patterns. So after a while you start saying "oh, I bet this is a version of that other thing I've seen devs stumble over all the time".

A bit of a rambling comment to say don't worry. you'll "get really good at it" with experience.

[JanneVee]

I didn't say that I was any good, just that I enjoyed it.

I have a dog eared copy of Advanced Windows Debugging that I've used, but I've also have books around reverse engineering, disassembly and a little bit of curiosity and practice. I have also the .NET version which I haven't used as much. I also enjoyed the Vostokov books, even though there is a lack of editing in them.

Edit to add: It is not as much focus on usage of the tool as it is about understanding what is going on in the dump file, you are ahead in knowledge if you can do stack traces and look at exception records.