IMO the main reason Raymond Chen is so good at that, he does that a lot. Unless you work for Microsoft, it’s very unlikely your job requires analyzing thousands of crash dumps of random third-party programs.
I do that very rarely, and I only analyze the dumps of the programs I made. Of course, Raymond is way better than me at that, but I’m fine with it. People pay me to develop software for them; I only debug stuff when I have to.
He has obviously decades of experience, but the basics of debugging with windbg aren't actually that difficult to start with. I remember trying to look into some memory dumps we got from crashes of our application from internal users, and was able to get relevant information pretty quickly just from some basic built-in diagnostic commands I picked up from his and the old NTDebugging blog (which seems to be sadly gone).
Maybe not, but I think he does a pretty good job of showing how he is “just” taking logical steps towards understanding what is going on. Some of them probably didn’t pan out and were omitted but most of this debugging work is simply trying to understand more and iteratively zeroing in on the bug.
He argued that most proofs really only involve one insightful step. Really difficult ones might require two.
The rest is just 'turning the wheel'; each step is just doing the only thing you can do. The point of practice is to make those steps obvious; to learn to turn the wheel.
I guess when it comes to looking at core dumps, I don't even know where the wheel is, let alone how to turn it because it's something I have never done. It maintains that air of magic to me.
I do that very rarely, and I only analyze the dumps of the programs I made. Of course, Raymond is way better than me at that, but I’m fine with it. People pay me to develop software for them; I only debug stuff when I have to.
BTW, couple years ago I wrote an article on the topic: http://const.me/articles/windbg/windbg-intro.pdf