BSOD 0x9F in NTOSKRNL.EXE

Anonymous
2013-04-19T06:40:47+00:00

I'm getting somewhat frequent BSODs these days.

WinDbg reports:

*******************************************************************************

*                                                                             *

*                        Bugcheck Analysis                                    *

*                                                                             *

*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 9F, {4, 12c, 86a6c340, 809b4b54}

Implicit thread is now 86a6c340

Probably caused by : ntkrpamp.exe ( nt!KiSwapContext+19 )

Followup: MachineOwner


0: kd> !analyze -v

*******************************************************************************

*                                                                             *

*                        Bugcheck Analysis                                    *

*                                                                             *

*******************************************************************************

DRIVER_POWER_STATE_FAILURE (9f)

A driver has failed to complete a power IRP within a specific time (usually 10 minutes).

Arguments:

Arg1: 00000004, The power transition timed out waiting to synchronize with the Pnp

 subsystem.

Arg2: 0000012c, Timeout in seconds.

Arg3: 86a6c340, The thread currently holding on to the Pnp lock.

Arg4: 809b4b54, nt!TRIAGE_9F_PNP on Win7

Debugging Details:


Implicit thread is now 86a6c340

DRVPOWERSTATE_SUBCODE:  4

FAULTING_THREAD:  86a6c340

DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT

BUGCHECK_STR:  0x9F

PROCESS_NAME:  System

CURRENT_IRQL:  2

LAST_CONTROL_TRANSFER:  from 81bfb22f to 81ba3699

STACK_TEXT: 

d88f7aec 81bfb22f 00002000 86a6c398 86a6c340 nt!KiSwapContext+0x19

d88f7b60 81bfd058 86a6c340 86a6c420 00000002 nt!KiCommitThreadWait+0x280

d88f7bfc 81c19a81 84ef4710 0000001b 00000000 nt!KeWaitForSingleObject+0x26c

d88f7c60 81c02406 81c54ee0 84ef4710 81c39578 nt!ExpWaitForResource+0xd2

d88f7ca8 81d04d68 81c54ee0 00000001 81c39578 nt!ExAcquireResourceExclusiveLite+0x191

d88f7cc4 81ad36f9 00000001 81c39578 86a6c340 nt!PpDevNodeLockTree+0x43

d88f7d1c 81c01c95 00000000 86a6c340 00000000 nt!PnpDeviceActionWorker+0x3d

d88f7d74 81ae5aaa 00010000 c8c30dc3 00000000 nt!ExpWorkerThread+0x111

d88f7db0 81ba3f19 81c01b88 00010000 00000000 nt!PspSystemThreadStartup+0x4a

00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19

STACK_COMMAND:  .thread 0xffffffff86a6c340 ; kb

FOLLOWUP_IP:

nt!KiSwapContext+19

81ba3699 8b2c24          mov     ebp,dword ptr [esp]

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  nt!KiSwapContext+19

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

IMAGE_NAME:  ntkrpamp.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  513809e8

BUCKET_ID_FUNC_OFFSET:  19

FAILURE_BUCKET_ID:  0x9F_4_nt!KiSwapContext

BUCKET_ID:  0x9F_4_nt!KiSwapContext

Followup: MachineOwner


The file ntoskrnl.exe is dated March 7 and has the following version information:

c:/windows/system32/ntoskrnl.exe:

File Version:  6.2.9200.16551

Product Version: 6.2.9200.16551

File Flags:  

File OS:  NT_WINDOWS32

File Type:  APP

Language: English (United States), Code Page: Unicode

 CompanyName: Microsoft Corporation

 FileDescription: NT Kernel & System

 FileVersion: 6.2.9200.16551 (win8_gdr.130306-1502)

 InternalName: ntkrpamp.exe

 LegalCopyright: © Microsoft Corporation. All rights reserved.

 OriginalFilename: ntkrpamp.exe

 ProductName: Microsoft® Windows® Operating System

 ProductVersion: 6.2.9200.16551

I have a full memory dump available.

How should I troubleshoot this (other than the tedious msconfig / disable stuff / enable stuff /... process)?

Windows for home | Previous Windows versions | Performance and system failures

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.

0 comments No comments

79 answers

Sort by: Newest
  1. Anonymous
    2015-06-04T14:03:03+00:00

    There are some older drivers on the system in particular the giveo.sys (Speedfan) which appears dated 1996 and the Apowersoft_AudioDevice.sys (Wondershare) which appears to be from 2008.

    Before running the Driver Verifier I might suggest to try uninstalling these two software.

    If the BSODs continue then enabling the Driver Verifier on all-non-Microsoft drivers as you did before may be advised.

    If you cannot start Windows after enabling the Driver Verifier you can launch the Driver Verifier (verifier.exe > Delete existing settings > Finish) from a command prompt by booting recovery media.

    That may be what you did before.

    Hopefully a dump file will be created which would identify the offending driver.

    Was this answer helpful?

    0 comments No comments
  2. Anonymous
    2015-06-03T05:05:29+00:00

    Thx for the links.

    Generation of the memory dump works fine with no pagefile on C: and the previously mentioned settings (I'm assuming uploading yet another dump is useless at this point. I get at least one BSOD per day...)

    Yes the issue looks similar to the one in the Dell article, but it refers to a Windows 7 QFE whose code/logic I assume is built into [recent] Windows 8.1 code.

    What older drivers on my systems are you referring to?

    I can't say that I'm familiar with Driver Verifier. I know the principle of operation, and once followed the advice in an article that suggested to enable it for all non-Microsoft drivers, with quite a bunch of checks turned on. All this got me was a non-bootable system (endless reboot loop) and it was quite difficult to recover (needed to use a bootable USB key to disable DV from WinPE).

    Which drivers do you suggest to turn DV on for, and with which checks?

    What is the recommended approach for determining the faulty driver using DV? Plain old dichotomy?

    Was this answer helpful?

    0 comments No comments
  3. Anonymous
    2015-06-02T21:38:51+00:00

    From my understanding in Windows 8 if you use the DedicatedDumpFile registry value you do not need a page file on C: or any other paging file.

    You shouldn't have to make any change at the CrashControl\MachineCrash key as the system should modify that with a new crash.

    There is some good information on this in the following article:

    https://support.microsoft.com/en-us/kb/969028

    What you are experiencing with the BSODs and USB devices not being detected seems to match what is discussed in the following article from Dell but the article is for Windows 7:

    http://www.dell.com/support/article/us/en/19/SLN295673/EN

    Perhaps a similar issue may exist in certain setups in Windows 8 or the issue may be from another, perhaps third party, driver.

    There are some older drivers loaded on your system which have the potential to be problematic.

    Are you familiar with using the Driver Verifier?

    Was this answer helpful?

    0 comments No comments
  4. Anonymous
    2015-06-02T05:21:16+00:00

    I'm going to try:

    DumpFile d:\dumps\MEMORY.DMP

    DedicatedDumpFile d:\dumps\DedicatedDumpFile.Ddmp

    I presume with this it's now OK to not have any pagefile on C:, correct?

    Do I also have to change the settings under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl\MachineCrash?

    For now I have:

    DumpFile C:\Windows\MEMORY.DMP

    FinalDumpFileLocation C:\Windows\MEMORY.DMP

    there...

    Was this answer helpful?

    0 comments No comments
  5. Anonymous
    2015-06-01T05:54:27+00:00

    New BSOD upon shutdown, due to a similar symptom: "safely remove" of an inserted USB key just... hung...

    Dump at http://1drv.ms/1SPyYH9

    How can one determine which driver doesn't respond to the removal or power state change IRP?

    Was this answer helpful?

    0 comments No comments