Driver_power_state_failure after upgrade to Windows 8.1 x64

Since upgrading to Windows 8.1, my network connection is continually dropping. Running the Network troubleshooting wizard causes the Broadcom Gigabit Ethernet Adaptor to hang/become disabled.

Rebooting either before or after the network connection drops fixes the connection but if the troubleshooting wizard was run, the reboot results in a BSOD with DRIVER_POWER_STATE_FAILURE error.

I downloaded the latest Broadcom drivers but Windows insists that the default driver is current and won't allow installation of the vendor driver (which is an earlier version number, but has a more recent date than default WIndows driver).

I've uploaded the latest two minidumps and a full dump to Skydrive. (

Any help would be appreciated.

All of the attached DMP files are of the DRIVER_POWER_STATE_FAILURE (9f) bug check.

This bug check indicates that the driver is in an inconsistent or invalid power state.

Unfortunately, there's no blocked IRP address in the 4th parameter of the bug check itself to run an !irp on to see which device driver caused it, so we'll need to go a bit further. If we run a !thread on the 3rd parameter of the bug check (thread currently holding on to the Pnp lock), we get the following call stack:

Child-SP          RetAddr           : Args to Child                                                           : Call Site
ffffd000`38736ba0 fffff800`69257dae : ffffd000`201e7180 ffffe000`0117e040 00000000`fffffffe 00000000`fffffffe : nt!KiSwapContext+0x76
ffffd000`38736ce0 fffff800`69257847 : ffffe000`0117e040 fffff800`69265732 00000000`18864402 00000000`002b99bb : nt!KiSwapThread+0x14e
ffffd000`38736d80 fffff800`69262a74 : ffffe000`0117e040 ffffffff`ffffffff 00000000`00000034 00000000`00000004 : nt!KiCommitThreadWait+0x127
ffffd000`38736de0 fffff800`0338b35c : ffffe000`00c010b8 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KeDelayExecutionThread+0x434
ffffd000`38736e60 fffff800`0338afa9 : 00000000`00000000 ffffffff`ff63c000 00000000`00000000 ffffd000`38737054 : mslldp!lldpWaitForValueToZero+0x30
ffffd000`38736e90 fffff800`033890b5 : ffffe000`00c01000 00000000`00000000 ffffe000`0095ace0 ffffd000`38737110 : mslldp!lldpWaitForTxCompletion+0x69
ffffd000`38736ed0 fffff800`00d5f922 : ffffe000`038d7c10 00000000`00000008 ffffe000`0389dc10 ffffd000`38737110 : mslldp!lldpProtNetPnPEvent+0x325
ffffd000`38736f00 fffff800`00d5f87b : ffffe000`0095ace0 ffffd000`38737110 ffffe000`0389dc10 ffffe000`01624ae0 : ndis!ndisInvokeNetPnPEvent+0x42
ffffd000`38736f40 fffff800`00d9d4f6 : 00000000`c00000bb ffffe000`0389dc10 ffffe000`038d7c10 ffffd000`387370e0 : ndis!ndisDeliverNetPnPEventSynchronously+0x47
ffffd000`38736f80 fffff800`00d5f985 : ffffd000`38737110 ffffd000`38737189 ffffe000`00c341a0 ffffe000`038d7c10 : ndis!ndisPnPNotifyBinding+0x86
ffffd000`387370a0 fffff800`00d63a3b : ffffe000`038d7c10 ffffe000`00c341a0 00000000`00000002 fffff800`00d5fe4e : ndis!ndisPnPNotifyBindingUnlocked+0x35
ffffd000`387370f0 fffff800`00d5fcf7 : 00000000`00000000 00000000`00000000 ffffc000`043220d0 ffffd000`38737330 : ndis!ndisPauseProtocolInner+0x6b
ffffd000`387371f0 fffff800`00d618a6 : ffffe000`00c341a0 ffffd000`38737330 ffffe000`00c355e8 00000000`00000000 : ndis!ndisPauseProtocol+0x5f
ffffd000`38737230 fffff800`00d60024 : ffffe000`00c341a0 ffffe000`00c341a0 ffffd000`38737400 ffffe000`00c355e8 : ndis!Ndis::BindEngine::Iterate+0x2f6
ffffd000`38737440 fffff800`00d62630 : ffffe000`00c355e8 ffffd000`387375f0 ffffd000`387374c0 ffffd000`387375f0 : ndis!Ndis::BindEngine::UpdateBindings+0x64
ffffd000`38737470 fffff800`00d5faf3 : ffffe000`00c355e8 ffffe000`00c355e8 ffffe000`031af390 fffff800`00d5fbcd : ndis!Ndis::BindEngine::DispatchPendingWork+0x50
ffffd000`387374a0 fffff800`00da0e3b : ffffe000`00c341a0 ffffe000`00c341a0 ffffe000`014cc4c0 ffffe000`031af390 : ndis!Ndis::BindEngine::ApplyBindChanges+0x33
ffffd000`387374f0 fffff800`00d63479 : ffffe000`00c341a0 ffffe000`00c34050 ffffe000`00c341a0 ffffe000`00c34050 : ndis!ndisPnPRemoveDevice+0x18b
ffffd000`38737740 fffff800`00da8b69 : 00000000`00000000 ffffe000`00c34050 ffffe000`013deca0 ffffe000`00c34100 : ndis!ndisPnPRemoveDeviceEx+0x59
ffffd000`38737770 fffff800`00d5f7f2 : ffffe000`013deca0 ffffd000`38737810 ffffe000`00c341a0 00000000`00000000 : ndis!ndisPnPIrpRemoveDevice+0x7c05
ffffd000`387377d0 fffff800`6963a74a : ffffe000`00c34001 ffffe000`00c34050 ffffd000`38737801 fffff800`69508180 : ndis!ndisPnPDispatch+0x1d2
ffffd000`38737840 fffff800`696a2088 : 00000000`00000002 ffffd000`38737909 ffffe000`01624c30 ffffe000`01624060 : nt!IopSynchronousCall+0xfe
ffffd000`387378b0 fffff800`693032f7 : ffffc000`0536e540 00000000`0000000a ffffe000`01624c30 00000000`0000000a : nt!IopRemoveDevice+0xe0
ffffd000`38737970 fffff800`696a1af9 : ffffe000`01624060 ffffe000`01624c30 ffffc000`0da37370 ffffe000`01624060 : nt!PnpRemoveLockedDeviceNode+0x1a7
ffffd000`387379d0 fffff800`696a1a72 : 00000000`00000000 ffffc000`0da37370 ffffe000`01624c30 00000000`3f051397 : nt!PnpDeleteLockedDeviceNode+0x4d
ffffd000`38737a10 fffff800`696a0c7f : ffffe000`01624060 ffffd000`00000002 00000000`00000000 00000000`00000000 : nt!PnpDeleteLockedDeviceNodes+0x9a
ffffd000`38737a90 fffff800`696451fd : ffffc000`0536e500 00000000`00000001 ffffc000`00000000 ffffe000`ffffffff : nt!PnpProcessQueryRemoveAndEject+0x4ef
ffffd000`38737bf0 fffff800`69645537 : ffffc000`0536e540 00000000`00000000 00000000`00000000 fffff800`69645218 : nt!PnpProcessTargetDeviceEvent+0x9d
ffffd000`38737c30 fffff800`6925465d : fffff800`69645218 ffffc000`0d703dc0 ffffd000`38737d10 ffffe000`0186b160 : nt!PnpDeviceEventWorker+0x31f
ffffd000`38737c90 fffff800`692fdc80 : 00000000`00000000 ffffe000`0117e040 ffffe000`0117e040 ffffe000`000d9440 : nt!ExpWorkerThread+0x2b5
ffffd000`38737d40 fffff800`6936e2c6 : ffffd000`20640180 ffffe000`0117e040 ffffd000`2064c240 00000000`00000000 : nt!PspSystemThreadStartup+0x58
ffffd000`38737da0 00000000`00000000 : ffffd000`38738000 ffffd000`38732000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16

In this call stack, there are PLENTY of ndis.sys calls. ndis.sys -  Network Driver Interface Specification (NDIS) is an application programming interface (API) for network interface cards (NICs).

Usually when we have network related issues like this, it's caused by one of two things:

1. Network drivers themselves need to be updated to latest version -

2. 3rd party antivirus or firewall software causing network conflicts (i.e NETBIOS ports).

Do you have any antivirus or firewall software installed and/or enabled? If not, let's go ahead and enable Driver Verifier:

Driver Verifier:

What is Driver Verifier?

Driver Verifier is included in Windows 8, 7, Windows Server 2008 R2, Windows Vista, Windows Server 2008, Windows 2000, Windows XP, and Windows Server 2003 to promote stability and reliability; you can use this tool to troubleshoot driver issues. Windows kernel-mode components can cause system corruption or system failures as a result of an improperly written driver, such as an earlier version of a Windows Driver Model (WDM) driver.

Essentially, if there's a 3rd party driver believed to be at issue, enabling Driver Verifier will help flush out the rogue driver if it detects a violation.

Before enabling Driver Verifier, it is recommended to create a System Restore Point:

Vista - START | type rstrui - create a restore point
Windows 7 - START | type create | select "Create a Restore Point"
Windows 8 -

How to enable Driver Verifier:

Start > type "verifier" without the quotes > Select the following options -

1. Select - "Create custom settings (for code developers)"
2. Select - "Select individual settings from a full list"
3. Check the following boxes -
- Special Pool
- Pool Tracking
- Force IRQL Checking
- Deadlock Detection
- Security Checks (Windows 7 & 8)
- DDI compliance checking (Windows 8)
- Miscellaneous Checks
4. Select  - "Select driver names from a list"
5. Click on the "Provider" tab. This will sort all of the drivers by the provider.
6. Check EVERY box that is [B]NOT[/B] provided by Microsoft / Microsoft Corporation.
7. Click on Finish.
8. Restart.

Important information regarding Driver Verifier:

- If Driver Verifier finds a violation, the system will BSOD.

- After enabling Driver Verifier and restarting the system, depending on the culprit, if for example the driver is on start-up, you may not be able to get back into normal Windows because Driver Verifier will flag it, and as stated above, that will cause / force a BSOD.

If this happens, do not panic, do the following:

- Boot into Safe Mode by repeatedly tapping the F8 key during boot-up.

- Once in Safe Mode - Start > type "system restore" without the quotes.

- Choose the restore point you created earlier.
If you did not set up a restore point, do not worry, you can still disable Driver Verifier to get back into normal Windows:

- Start > Search > type "cmd" without the quotes.

- To turn off Driver Verifier, type in cmd "verifier /reset" without the quotes.
・    Restart and boot into normal Windows.

How long should I keep Driver Verifier enabled for?

It varies, many experts and analysts have different recommendations. Personally, I recommend keeping it enabled for at least 24 hours. If you don't BSOD by then, disable Driver Verifier.

My system BSOD'd, where can I find the crash dumps?

They will be located in %systemroot%\Minidump

Any other questions can most likely be answered by this article:


Debugger/Reverse Engineer.

Was this reply helpful?

Sorry this didn't help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this reply?

Thanks for your feedback.


Question Info

Last updated November 19, 2018 Views 1,860 Applies to: