WinDBG symbols

[Laith]

I meant that using the 7 SDK and Win7 worked like a charm, when upgrading to Win10 and using the Win7 SDK it gave me problems sometimes.

Hope they fix this dang problem, it's driving me nuts. I can't solve any BSODs either.

 

[Anak]

On Windows 7 WinDBG worked like a charm with no errors, but with upgrading it gave me errors and all kinds o' stuff.

It had nothing to do with windows 10, we have three different OS's all getting the same thing.

This is still happening in quite a few dumps, I'm starting to think some update has altered something.

View attachment 369587

As soon as Microsoft gets enough complaints about this they will probably fix it.

You might be on to it Derek, But like you mentioned, it's still early yet and MS hasn't received enough complaints:

After applied updates from Microsoft Security Bulletin for August 2015 (e.g. kb3071756) on Windows 7 SP1, kernel version becomes 6.1.7601.18933 or 6.1.7601.23136; in kd, command 'dt nt!*' shows nothing.

Source: Windows 7 SP1 kernel symbol (ntkrnlmp.pdb) has no information for data types but functions

I checked for: c:\symbols\ntkrnlmp.pdb\47ACF8EA3A4C4C04A44C87BCD487D12F2\ntkrnlmp.pdb like in the source link and didn't have it, but It may be different for win7 so I tested by uninstalling KB3071756 and re-running Laith's .dbg file but reached the same result: "Your debugger is not using the correct symbols" so its not that particular update.

 

[Laith]

I'm gonna be honest right now, i would have stayed at 7 and with the 7 SDK if i knew that it would give me problems, i only upgraded to 10 because i thought the dump system was gonna be changed and i couldn't analyze no more.

 

[Anak]

The dump system was changed there is a new one for 10, see about half way down here: https://Download kits and tools for Windows 10 | msdn.microsoft.com

Not sure if it means anything, but in checking compatibility I was successful in opening some dumps from the win10 bsod forum with my 7debugger.

Use debugging tools

Debugging Tools for Windows 10 (WinDbg)

If you just need the Debugging Tools for Windows 10, and not WDK 10 or Visual Studio Community 2015, you can install the tools as a standalone component from Windows SDK. In the installation wizard, select Debugging Tools for Windows, and deselect all other components.

The link to: Get Debugging Tools for Windows (WinDbg) (from the SDK) is a direct d/l link.

If you're still with win10; You could try reinstalling or repairing the 7SDK go to:

• Programs and features, I believe its called Apps now in 10?

• Look for Debugging tools for Windows.

• Right click and pick change or repair, you can also repair from the change setting.

If that doesn't work try uninstalling the 7SDK and install the one above.

 

[Laith]

Well, i don't get the message that the debugger is not using the right symbols, i get another one now. I tried your steps with your SDK with no luck.

*************************************************************************
***                                                                   ***
***                                                                   ***
***    Either you specified an unqualified symbol, or your debugger   ***
***    doesn't have full symbol information.  Unqualified symbol      ***
***    resolution is turned off by default. Please either specify a   ***
***    fully qualified symbol module!symbolname, or enable resolution ***
***    of unqualified symbols by typing ".symopt- 100". Note that     ***
***    enabling unqualified symbol resolution with network symbol     ***
***    server shares in the symbol path may cause the debugger to     ***
***    appear to hang for long periods of time when an incorrect      ***
***    symbol name is typed or the network symbol server is down.     ***
***                                                                   ***
***    For some commands 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                                     ***
***                                                                   ***
*************************************************************************

 

[derekimo]

I doubt it is anything to do with the version of your or anyone else's debugger, I'm using the win 8 version and I'm getting the same thing in your above post.

 

[Anak]

Laith, I ran the .dbg file you provided thru an: Online Crash Dump Analysis Service and it came up with a lot more info on the file, but strangely enough it to had the "unqualified symbol" warning. If you re-run the file you can see more at the end of the report where the plus (+) signs are, just click on them.

From the limited data the FAILURE_BUCKET_ID: X64_0x7E_nt!KxWaitForLockOwnerShip+12 means there is a device driver waiting to access data that is "locked". The lock is not getting released because a hardcoded breakpoint or assertion was hit. As it says below in the analysis "this shouldn't happen because developers should never have hardcoded breakpoints in retail code, but ..."; and this goes hand in hand with the .pdb warnings about symbols being unqualified or the debugger doesn't have full symbol information.

Now whether this is a fault of the developer taking shortcuts in his or her programming or if it is the fault of the debugger or if it is caused by a Windows Update is still open for discussion, me? I'm going to sit tight and wait to see if there is any more info that surfaces about this.

If you're still trying to help this member, I'd suggest:

• Stop any overclocking, reset bios to defaults.

• Update graphics drivers.

• Update USB drivers.

• Update wireless and or network drivers.

• Run Memtest.

• Run Driver Verifier

• CHKDSK and or SFC scans are optional but worth the effort.

Test run of dmp file at post #12

Crash Dump Analysis provided by OSR Open Systems Resources, Inc. (http://www.osr.com)
Online Crash Dump Analysis Service
See http://www.osronline.com for more information
Windows 7 Kernel Version 7601 (Service Pack 1) MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 7601.18933.amd64fre.win7sp1_gdr.150715-0600
Machine Name:
Kernel base = 0xfffff800`03406000 PsLoadedModuleList = 0xfffff800`0364d730
Debug session time: Mon Aug 17 23:00:08.210 2015 (UTC - 4:00)
System Uptime: 0 days 0:27:59.568
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M (1000007e)
This is a very common bugcheck.  Usually the exception address pinpoints
the driver/function that caused the problem.  Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003.  This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG.  This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG.  This will let us see why this breakpoint is
happening.
Arguments:
Arg1: ffffffffc0000005, The exception code that was not handled
Arg2: fffff800034aada2, The address that the exception occurred at
Arg3: fffff880033e06d8, Exception Record Address
Arg4: fffff880033dff30, Context Record Address

Debugging Details:
------------------

*************************************************************************
***                                                                   ***
***                                                                   ***
***    Either you specified an unqualified symbol, or your debugger   ***
***    doesn't have full symbol information.  Unqualified symbol      ***
***    resolution is turned off by default. Please either specify a   ***
***    fully qualified symbol module!symbolname, or enable resolution ***
***    of unqualified symbols by typing ".symopt- 100". Note that   ***
***    enabling unqualified symbol resolution with network symbol     ***
***    server shares in the symbol path may cause the debugger to     ***
***    appear to hang for long periods of time when an incorrect      ***
***    symbol name is typed or the network symbol server is down.     ***
***                                                                   ***
***    For some commands 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                                     ***
***                                                                   ***
*************************************************************************
TRIAGER: Could not open triage file : e:\dump_analysis\program\triage\modclass.ini, error 2
*************************************************************************
***                                                                   ***
***                                                                   ***
***    Either you specified an unqualified symbol, or your debugger   ***
***    doesn't have full symbol information.  Unqualified symbol      ***
***    resolution is turned off by default. Please either specify a   ***
***    fully qualified symbol module!symbolname, or enable resolution ***
***    of unqualified symbols by typing ".symopt- 100". Note that   ***
***    enabling unqualified symbol resolution with network symbol     ***
***    server shares in the symbol path may cause the debugger to     ***
***    appear to hang for long periods of time when an incorrect      ***
***    symbol name is typed or the network symbol server is down.     ***
***                                                                   ***
***    For some commands 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                                     ***
***                                                                   ***
*************************************************************************
*************************************************************************
***                                                                   ***
***                                                                   ***
***    Either you specified an unqualified symbol, or your debugger   ***
***    doesn't have full symbol information.  Unqualified symbol      ***
***    resolution is turned off by default. Please either specify a   ***
***    fully qualified symbol module!symbolname, or enable resolution ***
***    of unqualified symbols by typing ".symopt- 100". Note that   ***
***    enabling unqualified symbol resolution with network symbol     ***
***    server shares in the symbol path may cause the debugger to     ***
***    appear to hang for long periods of time when an incorrect      ***
***    symbol name is typed or the network symbol server is down.     ***
***                                                                   ***
***    For some commands 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                                     ***
***                                                                   ***
*************************************************************************

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".

FAULTING_IP: 
nt!KxWaitForLockOwnerShip+12
fffff800`034aada2 48890a          mov     qword ptr [rdx],rcx

EXCEPTION_RECORD:  fffff880033e06d8 -- (.exr 0xfffff880033e06d8)
ExceptionAddress: fffff800034aada2 (nt!KxWaitForLockOwnerShip+0x0000000000000012)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 0000000000000000
   Parameter[1]: ffffffffffffffff
Attempt to read from address ffffffffffffffff

CONTEXT:  fffff880033dff30 -- (.cxr 0xfffff880033dff30)
rax=0000000000000006 rbx=fffff80003636f70 rcx=fffff880033e09c0
rdx=0012800000000000 rsi=fffff88002fe6180 rdi=fffff880033e09c0
rip=fffff800034aada2 rsp=fffff880033e0910 rbp=00000003e919d385
 r8=fffff880033e09c0  r9=0000000000000001 r10=0000000000000002
r11=fffffa80058171a8 r12=00000000e919d385 r13=0000058000000000
r14=0000000000000001 r15=2aaaaaaaaaaaaaab
iopl=0         nv up ei ng nz na po nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00010286
nt!KxWaitForLockOwnerShip+0x12:
fffff800`034aada2 48890a          mov     qword ptr [rdx],rcx ds:002b:00128000`00000000=????????????????
Resetting default scope

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  WIN7_DRIVER_FAULT

BUGCHECK_STR:  0x7E

CURRENT_IRQL:  0

LAST_CONTROL_TRANSFER:  from fffff8000348356e to fffff800034aada2

STACK_TEXT:  
fffff880`033e0910 fffff800`0348356e : fffff800`03636f70 00000000`00000246 fffff880`033e0960 00000000`00000018 : nt!KxWaitForLockOwnerShip+0x12
fffff880`033e0940 fffff800`0348abae : 00000003`e919d385 fffffa80`059eb1a8 fffff800`03636f50 fffffa80`059eb1a0 : nt!KeAcquireInStackQueuedSpinLockAtDpcLevel+0x7e
fffff880`033e0990 fffff800`034b2b4e : fffffa80`059eb1a8 fffffa80`00802860 fffff880`03071178 fffffa80`0000008f : nt!MiUnlinkPageFromLockedList+0x2ee
fffff880`033e0a10 fffff800`034b3148 : 00000000`00000000 fffffa80`05817090 fffffa80`00000000 fffff8a0`0b0d1000 : nt!MiGatherMappedPages+0x5be
fffff880`033e0b10 fffff800`037128e2 : fffffa80`04ff5b50 00000000`00000080 fffffa80`04e615d0 00000000`00000000 : nt!MiMappedPageWriter+0x198
fffff880`033e0c00 fffff800`0346af46 : fffff800`035f9e80 fffffa80`04ff5b50 fffff800`03607cc0 00000000`00000000 : nt!PspSystemThreadStartup+0x5a
fffff880`033e0c40 00000000`00000000 : fffff880`033e1000 fffff880`033db000 fffff880`033e0790 00000000`00000000 : nt!KxStartSystemThread+0x16


FOLLOWUP_IP: 
nt!KxWaitForLockOwnerShip+12
fffff800`034aada2 48890a          mov     qword ptr [rdx],rcx

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  nt!KxWaitForLockOwnerShip+12

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

IMAGE_NAME:  ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  55a6901f

STACK_COMMAND:  .cxr 0xfffff880033dff30 ; kb

FAILURE_BUCKET_ID:  X64_0x7E_nt!KxWaitForLockOwnerShip+12

BUCKET_ID:  X64_0x7E_nt!KxWaitForLockOwnerShip+12

Followup: MachineOwner
---------


This free analysis is provided by OSR Open Systems Resources, Inc.
Want a deeper understanding of crash dump analysis? Check out our Windows Kernel Debugging and Crash Dump Analysis Seminar (opens in new tab/window)
+ Show DivCrash Code Links
+ Show DivLoaded Module List
+ Show DivRaw Stack Contents
+ Show DivDump Header Information
+ Show DivStrings

 

[Laith]

Okay, i will do that. But this is driving me nuts, i can't debug. I'm almost giving up BSOD debugging now.

 

[Laith]

Bump, is anyone still here? I still need help...

 

[z3r010]

I've got nothing

 

[Laith]

Well, i can analyze a little, but it's so annoying as i have to go the top and get the bugcheck and go to the bottom to get the driver and put it in the CODE tags, it's very annoying. I'm doing my best though till i get a fix. I can't give up when i'm so far away, can i?

 

[Anak]

Laith, where is this thread that you're helping on, do you have a link? If there is more than one lets start with the one that is bugging you the most.

A warning though; I'm busy until 7 or 8pm my time so I won't be able to get back until later, but I will see how I can help.

I'll be checking replies for the next 15" then I have other matters that need attending to.

 

[Laith]

Well, there's no need to at all. I can analyze the dumps perfectly expect the symbol crap comes up, i don't really care, i just find that very annoying, else i can analyze dumps perfectly.

 

[essenbe]

Laith, I think Derek was right. Many of the dump files are doing that. It seems to have started around the 16th of August. I've even gone through DM Logs with a lot of dumps. I couldn't run any of them until I got to earlier than 8/16. So, I would suspect that it was an update on or around that date. I have Windows 7 and 10 installed and it does the same on both operating systems.

 

[Laith]

Ah, hope they'll fix this soon though.

 

[essenbe]

We all hope so.

 

[Laith]

We do indeed.

 

[axe0]

It looks like it has been fixed, I can read new dump files normally.

I hope I don't cheer too soon

 

[Anak]

It looks like it has been fixed, I can read new dump files normally.

I hope I don't cheer too soon

Can you read the one in Laith's post #12 "normally"?

 

[axe0]

No, but I can read others at 10forums from the same date.