At my wit's end with windbg

[Camsie 1]

I'm having some program crashes that are producing dmp files and I want to read these files to understand what's causing the problem. My research indicates that the go-to program for reading dmp files is windbg, which comes as part of a large package of Windows debugging tools. However, I've recently learned that this damn program doesn't come complete from Microsoft.

 

First of all, it was whining to me about missing "symbol files" that for some reason didn't come in it's installer, requiring me to manually type in a website address where it's supposed to download these files (why this parameter wasn't configured by default, I have no idea. The software is worse then useless without it configured).

 

Now it's whining about the fact that it can't find .natvis files in it's installation directory, which it aparrently needs to do it's job. (GRRRR!!!! D:<) Looking online, it seems that these files can be found somewhere on the C: drive on Windows 10, which does me bugger-all good as a Windows 7 user.

 

Does anyone know where I can download these files (and any files they might depend on)? Preferably without having to also download a whole heap of other rubbish that I don't need?

 

All I want to do is read dmp files to figure out what caused the crashes they document. As far as I'm concerned, this should be a pretty simple task that a lone exe file ought to be able to accomplish on it's own. But this simple task is becoming almost as complicated as filling out a damn tax form! :'''(

[Rybags 949]

I should think that complete symbol files to cover every possible OS module not to mention extension stuff like C, BV, .NET runtime libraries etc. would add up to a fairly enormous amount of space.

 

As such it would seem you can use symbol servers which will provide symbol information if it's not locally available.

 

More info https://msdn.microsoft.com/en-us/library/windows/desktop/ee416588%28v=vs.85%29.aspx

[Camsie 1]

I should think that complete symbol files to cover every possible OS module not to mention extension stuff like C, BV, .NET runtime libraries etc. would add up to a fairly enormous amount of space.

 

As such it would seem you can use symbol servers which will provide symbol information if it's not locally available.

 

More info https://msdn.microsoft.com/en-us/library/windows/desktop/ee416588%28v=vs.85%29.aspx

But seriously, isn't the most common symbol library just the standard unicode library that (in theory) is bundled with Windows anyway? Okay, yes, there are probably a million variants, but I'd bet that 99.9% of the world's population would be covered by the unicode library. And probably most of the outliers are in third world villages that don't even have computer/internet access.

[Rybags 949]

In the context of dump analysis and debugging, symbols refer to variables, routine and branch targets within program modules.

So it's not just a couple of files required. Likely that cross reference files would be needed per folder worth of program files at the least.

[Rybags 949]

A bit more info, ie another quick and dirty explanation https://en.wikipedia.org/wiki/Debug_symbol

 

So, yeah - if the symbol data was to be included in verbose form, you'd end up with exponential growth in the overall size of an application.

[Camsie 1]

Man, this is getting way too technical for me. :( All I really want is to know which file is breaking down and causing my crashes, so that I might have some idea of how to go about fixing the problem.

 

Basically, what I need is an effective tool that translates dmp files into english. Like I say, everything I read says that windbg is the best tool for that, but it doesn't seem to install in a "ready for action" state. It's still missing it's .natvis file(s) and I seem to have to download/install them seperately.

[SquallStrife 482]

Man, this is getting way too technical for me.

This is what I was thinking from the outset. If you don't understand what is meant by "Symbol files" and such, then the info provided by windbg is not likely to make much sense to you.

[Rybags 949]

Following caller trails can be full of red herrings anyway. Often the root cause of problems is way back in history and it'll be pure pot luck that you happen to spot it.

[rs727 18]

Maybe bluescreenview http://nirsoft.net/utils/blue_screen_view.html

 

Shows the info in a dmp file in a friendly manner. Quickly points out the main points that might be of interest. If you need any more than that then you might need to start delving back into windbg.