unloaded driver stack

kemical

kemical

BSOD Kernel Dump Senior Analyst
Joined
Feb 25, 2014
Posts
31
Location
London
Hi guy's,
I keep seeing this issue pop up and cannot work out why it's happening. Basically I'll ask the user to set their settings to produce small memory dump (256k) but still the dump files produced will be 'mini kernel dumps' with no unloaded drivers listed. Does anyone know why this happens?
 
Are they specific bugchecks?

Certain dump files such as 0x117 aren't proper bugchecks but rather Windows Error Reporting saying there is a problem, it does normally turn off the display
ay so a hard reset is still required. (It's a kernel event located in the event viewer which is a log when a reset of the display has taken place, if it fails a 0x116 is generated), AFAIK anyway.
 
Last edited:
I've seen this 'issue' more with Bugcheck 124 than anything else but that may be just down to coincidence. I've looked on the net via google but not much seems to be written about this and really if you look is the advanced system settings there isn't even a setting for 'mini kernel dump'. I've tried searching the term also 'mini kernel dump' but to no avail. I can still read the dump file and all but just wondered why it happened and if it was down to something particular like page file size.....
 
0x124s don't save the module list, only the WHEA error record.
Mini kernel dumps are created and logged in the even viewer, not by the blue screen itself.
I'm unsure if the 0x124s contain the module information as a Kernel memory dump but definately not as a minidump.
 
0x124s don't save the module list, only the WHEA error record.
Click to expand...

They do, and that's often how I come to find that certain users have bloatware OEM software installed that predates Vista timestamps.
 
Patrick said:
0x124s don't save the module list, only the WHEA error record.
Click to expand...

They do, and that's often how I come to find that certain users have bloatware OEM software installed that predates Vista timestamps.
Click to expand...

I've just checked... They do.. Strange, I recall not being able to access it.
 
Also if they're from the event viewer why do the dump files appear in the mindump folder. Are you saying that it's the Event viewer which is creating these dumps? Hmm... not sure that sounds right to be honest...

An example..
I had one user a while ago who was getting such errors (Bugcheck 124) and his dump file had all the info I'd asked with commands, unloaded driver list ect but once he'd updated his driver and bios his dump files then changed to these damn mini kernel dumps. Now what had changed on his system I'm not sure but all he did was update his drivers and bios. After that no unloaded driver list.... I need to know what parameter is being changed to affect the dump files so..
 
My bad, they're actually logged in the event viewer from the live Kernel event which creates minidumps.
They're not 'proper' blue screens as they don't really bring down the system in the typical manner from what I've seen.
Typically 0x117s are mini kernel dumps that are created when the display driver doesn't respond, a TDR unsuccessful but it hasn't blue screened, it just shuts off the display with a reboot as the only option.
 
Also I don't think I've seen this issue with TDR bugchecks if anything it's almost always Bugcheck 124
 
The dump file is being generated no problem... It's the type of dump file which is the concern. My user has his settings set to create small memory dumps (256k) but instead his dump files are mini kernel dumps which do not contain an unloaded driver list... Why?
 
I've just been on Windows Forums

He means this:

Code: 
Loading Kernel Symbols
................................................
Loading User Symbols
[COLOR="#FF0000"]Mini Kernel Dump does not contain unloaded driver list[/COLOR]
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 124, {0, fffffa8007b5c8f8, 0, 0}

Probably caused by : AuthenticAMD

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

2: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

WHEA_UNCORRECTABLE_ERROR (124)
A fatal hardware error has occurred. Parameter 1 identifies the type of error
source that reported the error. Parameter 2 holds the address of the
WHEA_ERROR_RECORD structure that describes the error conditon.
Arguments:
Arg1: 0000000000000000, Machine Check Exception
Arg2: fffffa8007b5c8f8, Address of the WHEA_ERROR_RECORD structure.
Arg3: 0000000000000000, High order 32-bits of the MCi_STATUS value.
Arg4: 0000000000000000, Low order 32-bits of the MCi_STATUS value.

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


BUGCHECK_STR:  0x124_AuthenticAMD

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  WIN7_DRIVER_FAULT

PROCESS_NAME:  System

CURRENT_IRQL:  0

ANALYSIS_VERSION: 6.3.9600.17029 (debuggers(dbg).140219-1702) amd64fre

STACK_TEXT:  
fffff880`033705b0 fffff800`02eded29 : fffffa80`07b5c8d0 fffffa80`06c58040 00000000`00000001 00000000`00000000 : [COLOR="#FF0000"]nt!WheapCreateLiveTriageDump+0x6c[/COLOR]
fffff880`03370ad0 fffff800`02dbe217 : fffffa80`07b5c8d0 fffff800`02e38658 fffffa80`06c58040 00000000`00000000 : [COLOR="#FF0000"]nt!WheapCreateTriageDumpFromPreviousSession+0x49[/COLOR]
fffff880`03370b00 fffff800`02d25865 : fffff800`02e9a3a0 00000000`00000001 00000000`00000000 fffffa80`06c58040 : nt!WheapProcessWorkQueueItem+0x57
fffff880`03370b40 fffff800`02ca5a21 : fffff880`01250f00 fffff800`02d25840 fffffa80`06c58000 00000000`0000055a : nt!WheapWorkQueueWorkerRoutine+0x25
fffff880`03370b70 fffff800`02f38cce : 00000000`00000000 fffffa80`06c58040 00000000`00000080 fffffa80`06b9e890 : nt!ExpWorkerThread+0x111
fffff880`03370c00 fffff800`02c8cfe6 : fffff880`03189180 fffffa80`06c58040 fffff880`031940c0 00000000`00000000 : nt!PspSystemThreadStartup+0x5a
fffff880`03370c40 00000000`00000000 : fffff880`03371000 fffff880`0336b000 fffff880`03370590 00000000`00000000 : nt!KiStartSystemThread+0x16


STACK_COMMAND:  kb

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: AuthenticAMD

IMAGE_NAME:  AuthenticAMD

DEBUG_FLR_IMAGE_TIMESTAMP:  0

IMAGE_VERSION:  

FAILURE_BUCKET_ID:  X64_0x124_AuthenticAMD_PROCESSOR_BUS_PRV

BUCKET_ID:  X64_0x124_AuthenticAMD_PROCESSOR_BUS_PRV

ANALYSIS_SOURCE:  KM

FAILURE_ID_HASH_STRING:  km:x64_0x124_authenticamd_processor_bus_prv

FAILURE_ID_HASH:  {78c2f422-5335-4ef3-5cef-a28518da5023}

Followup: MachineOwner
 
Does the OP have the OS + pagefile on the same drive?

The following criteria needs to be met:

1. Windows key + Pause key. This should bring up System. Click Advanced System Settings on the left > Advanced > Performance > Settings > Advanced > Ensure there's a check-mark for 'Automatically manage paging file size for all drives'.

2. Windows key + Pause key. This should bring up System. Click Advanced System Settings on the left > Advanced > Startup and Recovery > Settings > System Failure > ensure there is a check mark next to 'Write an event to the system log'.

Ensure Kernel Memory Dump is selected and ensure the path is %systemroot%\MEMORY.DMP.

3. Double check that the WERS is ENABLED:

Start > Search > type services.msc > Under the name tab, find Windows Error Reporting Service > If the status of the service is not Started then right click it and select Start. Also ensure that under Startup Type it is set to Automatic rather than Manual. You can do this by right clicking it, selecting properties, and under General selecting startup type to 'Automatic', and then click Apply.


Code: 
===============================================================================
Section 0     : Processor Generic
-------------------------------------------------------------------------------
Descriptor    @ fffffa8007303978
Section       @ fffffa8007303a50
Offset        : 344
Length        : 192
Flags         : 0x00000001 Primary
Severity      : Fatal

Proc. Type    : x86/x64
Instr. Set    : x64
[COLOR=#ff0000]Error Type    : BUS error[/COLOR]
Operation     : Generic
Flags         : 0x00
Level         : 3
CPU Version   : 0x0000000000600f20
Processor ID  : 0x0000000000000000

Code: 
===============================================================================
Section 2     : x86/x64 MCA
-------------------------------------------------------------------------------
Descriptor    @ fffffa8007303a08
Section       @ fffffa8007303b90
Offset        : 664
Length        : 264
Flags         : 0x00000000
Severity      : Fatal

[COLOR=#ff0000]Error         : BUSLG_GENERIC_ERR_*_TIMEOUT_ERR (Proc 0 Bank 4)[/COLOR]
  Status      : 0xfe00000000070f0f
  Address     : 0x00000000fe9f8024
  Misc.       : 0xc00a0fff01000000

It's a generic timeout error, and it's somewhere along the bus. In every dump I took a look at it was processor #0 (primary core) and cache bank #4. Given the constant consistency even after replacing the video card, it's likely a faulty CPU, bad RAM (possibly a bad stick in slot #4 of the board), or bad DIMM slots (likely #4 if this is the case).
 
In fact the user does have two os one on each drive. I wondered if this could be a factor. Much thanks for your insights Patrick. I'm also going to post this thread up so the user can read your results rather than me take any glory..lol Thanks once again.

Edit:
The only puzzling thing I guess is the fact with his old gpu card his system ran fine. Only with the new card is he getting the bsod. Is it possible the extra strain on the system is revealing the fault?
 
I'm going to use an old 0x124 I've found on this forum, Patrick actually solved this in 2012.

Here's what we need to note, the callstack itself.

Code: 
fffff880`033705b0 fffff800`02eded29 : fffffa80`07b5c8d0 fffffa80`06c58040 00000000`00000001 00000000`00000000 : [COLOR="#FF0000"]nt!WheapCreateLiveTriageDump+0x6c[/COLOR]
fffff880`03370ad0 fffff800`02dbe217 : fffffa80`07b5c8d0 fffff800`02e38658 fffffa80`06c58040 00000000`00000000 : [COLOR="#FF0000"]nt!WheapCreateTriageDumpFromPreviousSession+0x49[/COLOR]
fffff880`03370b00 fffff800`02d25865 : fffff800`02e9a3a0 00000000`00000001 00000000`00000000 fffffa80`06c58040 : nt!WheapProcessWorkQueueItem+0x57
fffff880`03370b40 fffff800`02ca5a21 : fffff880`01250f00 fffff800`02d25840 fffffa80`06c58000 00000000`0000055a : nt!WheapWorkQueueWorkerRoutine+0x25
fffff880`03370b70 fffff800`02f38cce : 00000000`00000000 fffffa80`06c58040 00000000`00000080 fffffa80`06b9e890 : nt!ExpWorkerThread+0x111
fffff880`03370c00 fffff800`02c8cfe6 : fffff880`03189180 fffffa80`06c58040 fffff880`031940c0 00000000`00000000 : nt!PspSystemThreadStartup+0x5a
fffff880`03370c40 00000000`00000000 : fffff880`03371000 fffff880`0336b000 fffff880`03370590 00000000`00000000 : nt!KiStartSystemThread+0x16

In this dump file on windows forum the WHEA is creating live triage dumps, in the other dump file we have something totally different.

Code: 
fffff880`02f6ba58 fffff800`02814a3b : 00000000`00000124 00000000`00000000 fffffa80`04de5028 00000000`b2000000 : [COLOR="#0000FF"]nt!KeBugCheckEx[/COLOR]
fffff880`02f6ba60 fffff800`029d87d3 : 00000000`00000001 fffffa80`04de6ea0 00000000`00000000 fffffa80`04de6ef0 : [COLOR="#0000FF"]hal!HalBugCheckSystem+0x1e3[/COLOR]
fffff880`02f6baa0 fffff800`02814700 : 00000000`00000728 fffffa80`04de6ea0 fffff880`02f6be30 fffff880`02f6be00 : [COLOR="#FF0000"]nt!WheaReportHwError+0x263[/COLOR]
fffff880`02f6bb00 fffff800`02814052 : fffffa80`04de6ea0 fffff880`02f6be30 fffffa80`04de6ea0 00000000`00000000 : [COLOR="#FF0000"]hal!HalpMcaReportError+0x4c[/COLOR]
fffff880`02f6bc50 fffff800`02813f0d : 00000000`00000004 00000000`00000001 fffff880`02f6beb0 00000000`00000000 : hal!HalpMceHandler+0x9e
fffff880`02f6bc90 fffff800`02807e88 : 00000000`1b32a628 00000000`00000400 00000000`00000000 00000000`00000000 : hal!HalpMceHandlerWithRendezvous+0x55
fffff880`02f6bcc0 fffff800`028c9f2c : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : hal!HalHandleMcheck+0x40
fffff880`02f6bcf0 fffff800`028c9d93 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KxMcheckAbort+0x6c
fffff880`02f6be30 000007fe`f153b2a5 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiMcheckAbort+0x153
00000000`001ddc00 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x000007fe`f153b2a5

It's physically reporting the error to the operating system and calling the bugcheck.
Now reading up on Kernel triage dumps it basically takes a small snapshot of a process and it's user mode threads, AFAIK it doesn't restrict you to the kernel memory like typical kernel dump files but there is far less memory to be examined one of the things not stored is the kernel unloaded modules.
This type of dump isn't created via a bugcheck but rather creating a small dump file with a pre set amount of information, mainly stacks and threads.
This is created when a kernel debugger is attached but it is careful not to crash the actual system in the process.

Does he have a debugger attached?
 
Are you saying that minidumps do not contain the unloaded driver list, but a full kernel does (for the same user; same BSOD)?

I always have users set crash dumps to full kernel, which produces a full kernel dump + a mini dump.
 
jcgriff2 said:
Are you saying that minidumps do not contain the unloaded driver list, but a full kernel does (for the same user; same BSOD)?

I always have users set crash dumps to full kernel, which produces a full kernel dump + a mini dump.
Click to expand...

Ah yes I forgot about that, when setting to kernel memory dumps they actually create minidumps as well as the kernel memory dump so there's no need to change it.
 
Patrick actually solved this in 2012.
Click to expand...

A blast from the past! :grin1:

Only with the new card is he getting the bsod.
Click to expand...

Either the new GPU is faulty or his PSU. If he freezes, crashes, etc, under idle and not just load, I doubt it's PSU as much as it is a faulty GPU itself.
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top