Jump to content
Sign in to follow this  
Camsie

At my wit's end with windbg

Recommended Posts

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! :'''(

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×