WinDBG symbols

Hi Laith,

Has this been happening on all of the .dmp's you've tried to open since your "upgrade" or is it just certain ones like your example?

I'm thinking in the same vein as John, and if you can open "other .dmp's" I wouldn't be so quick to blame it on win10:

z3r010 said:

That doesn't work for me either, but I've not had an issue opening any on the forums

When I open your example I get:

Code:

*************************************************************************
***                                                                   ***
***                                                                   ***
***    Your debugger is not using the correct symbols                 ***
***                                                                   ***
***    In order for this command to work properly, your symbol path   ***
***    must point to .pdb files that have full type information.      ***
***                                                                   ***
***    Certain .pdb files (such as the public OS symbols) do not      ***
***    contain the required information.  Contact the group that      ***
***    provided you with these symbols if you need this command to    ***
***    work.                                                          ***
***                                                                   ***
***    Type referenced: nt!_KPRCB                                     ***
***                                                                   ***
*************************************************************************

, but all the others open normally.


The clue here is the .pdb files, .pdb files are created when a developer writes his or her own code for a program and if you don't have access to that code; You are up a creek without the proverbial paddle.

The most important thing all developers need to know: PDB files are as important as source code! Yes, that’s red and bold on purpose. I’ve been to countless companies to help them debug those bugs costing hundreds of thousands of dollars and nobody can find the PDB files for the build running on a production server. Without the matching PDB files you just made your debugging challenge nearly impossible. With a huge amount of effort, my fellow Wintellectuals and I can find the problems without the right PDB files, but it will save you a lot of money if you have the right PDB files in the first place.

Source: PDB Files: What Every Developer Must Know

My interpretation of your and Hacb's problem is the both of you are trying to help members that have installed open source/freelanced, call it what you want programs that are causing the BSOD's and I would guide these members to uninstall, particularly, any recent programs that have been developed by lesser known entities.

yep, that mesage looks like what i'm seeing sometimes.

Good ol' Mr. Cranky Pants! That's the tack I saw:

IMO - start by assuming it's a 3rd party driver (non-Windows)
Once you rule that out, then start in on hardware problems/diagnostics
The last thing to check (assuming Windows is fully updated) is Windows.

But I am going to have to rethink this.

From Derek's link and searching myself, not only on the web but into my own HDD I found that I do have pdb files at C:\symbols, but are they the right ones to decipher Laith's sample file?

I tested using various cmds in the debugger cmd line that I found in the kernel_debugging_tutorial.doc (copy that .doc name into your search box) that accompanies the debugger when you install it, with no luck.

I did some testing in the symbols folder following this: Windbg Symbols for ntoskrnl.exe even creating a ntoskml.pdb folder and coping files to it:

to fix this, you need to go into
the SYMBOLS\EXE folder and copy file 'ntkrnlmp.pdb'
to 'ntoskrnl.pdb'.

with no success.

I'm going to do more reading and testing and see if I can come up with an answer. Like why don't I have ntoskml.pdb to begin with?