Windows 8.1 Crashes while attempting to go to sleep

Hi, I have been experiencing this issue for the last month or so where I get a BSOD soon after I order my PC to sleep. The BSOD creates a dump file and then my computer restarts. Interestingly, this does not happen every time I want the computer to go to sleep. Rather, it seems quite random. I have tried to look for a solution and some places suggested that this was an issue with AMD drivers. I have an Intel processor but a ATI video card and I have tried reinstalling it but it does not resolve the issue. I have cliked on 'update driver' for every single component in my device list and this does not solve the issue either. Last I have also tried to access the dump file and in it, I seems to be the SYSTEM file that is actually crashing. Any ideas of how to solve this?

Hi Patrick,

So it has been two days since I uninstalled Daemon Tools and I have not had this problem at all! Therefore, I will assume this was the problem unless it occurs again, which then I will try your other solutions (bluetooth, memory card).

Thanks for your help!

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.


Magnificent, thank you!

Sorry for the very late reply, it took a very long time to download. I am unsure as to why, as it generally goes very fast. I digress!

BugCheck 9F, {4, 12c, ffffe00005f30040, fffff8034bc28960}

1st parameter = 0x4.

Let's take a look at the call stack:

0: kd> kv
Child-SP          RetAddr           : Args to Child                                                           : Call Site
fffff803`4bc28928 fffff803`4a3eb57e : 00000000`0000009f 00000000`00000004 00000000`0000012c ffffe000`05f30040 : nt!KeBugCheckEx
fffff803`4bc28930 fffff803`4a5916ca : 00000000`00000000 fffff803`00000000 fffff803`4a509100 ffffd000`28f06780 : nt!PnpBugcheckPowerTimeout+0x6a
fffff803`4bc28990 fffff803`4a2c8f64 : ffffd000`28f06740 00000000`00000001 fffff803`4bc28a39 00000000`00000002 : nt!PopBuildDeviceNotifyListWatchdog+0x16
fffff803`4bc289c0 fffff803`4a2c9478 : 00000000`00000002 ffffe000`04dce3f0 fffff803`4a509180 fffff803`4a50d700 : nt!KiProcessExpiredTimerList+0x1d8
fffff803`4bc28aa0 fffff803`4a325478 : fffff803`4a509180 00000000`00da7a64 fffff803`00110794 00000000`001107ac : nt!KiExpireTimerTable+0x218
fffff803`4bc28b40 fffff803`4a275abc : ffffe000`00000000 00001f80`00000001 00000044`1e51f438 00000000`00000002 : nt!KiTimerExpiration+0x148
fffff803`4bc28bf0 fffff803`4a36c7ea : fffff803`4a509180 fffff803`4a509180 00000000`001a3fe0 fffff803`4a561a80 : nt!KiRetireDpcList+0x19c
fffff803`4bc28d60 00000000`00000000 : fffff803`4bc29000 fffff803`4bc23000 00000000`00000000 00000000`00000000 : nt!KiIdleLoop+0x5a

Not really much info, just a few PnP/DPC routines that call into the bugcheck eventually. No driver in the stack, etc.

Let's run !locks to see what's going on:

0: kd> !locks
KD: Scanning for held locks..

Resource @ nt!IopDeviceTreeLock (0xfffff8034a4ea260)    Shared 1 owning threads
    Contention Count = 1
     Threads: ffffe000041e42c0-01<*>
KD: Scanning for held locks.

Resource @ nt!PiEngineLock (0xfffff8034a4ea360)    Exclusively owned
    Contention Count = 61
    NumberOfExclusiveWaiters = 7
     Threads: ffffe000041e42c0-01<*>
     Threads Waiting On Exclusive Access:
              ffffe00002902540       ffffe00002a9b880       ffffe00002960880       ffffe000057eb380       
              ffffe00005f30040       ffffe00006226340       ffffe00000984880

0: kd> !thread ffffe000041e42c0
THREAD ffffe000041e42c0  Cid 0004.100c  Teb: 0000000000000000 Win32Thread: 0000000000000000 WAIT: (Executive) KernelMode Non-Alertable
    ffffe0000441d448  SynchronizationEvent
Not impersonating
DeviceMap                 ffffc0000000c250
Owning Process            ffffe0000007d040       Image:         System
Attached Process          N/A            Image:         N/A
Wait Start TickCount      1853224        Ticks: 19201 (0:00:05:00.015)
Context Switch Count      320            IdealProcessor: 1  NoStackSwap
UserTime                  00:00:00.000
KernelTime                00:00:00.031
Win32 Start Address nt!ExpWorkerThread (0xfffff8034a2bbf04)
Stack Init ffffd00028a45d90 Current ffffd00028a45500
Base ffffd00028a46000 Limit ffffd00028a40000 Call 0
Priority 15 BasePriority 12 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5
Child-SP          RetAddr           : Args to Child                                                           : Call Site
ffffd000`28a45540 fffff803`4a2bf90e : fffff803`4a509180 ffffe000`041e42c0 00000000`fffffffe 00000000`fffffffe : nt!KiSwapContext+0x76
ffffd000`28a45680 fffff803`4a2bf3a7 : ffffe000`041e42c0 ffffe000`041e43c0 ffffe000`00c43520 00000000`00000000 : nt!KiSwapThread+0x14e
ffffd000`28a45720 fffff803`4a2569a8 : ffffe000`00000008 ffffe000`041e4400 ffffe000`057dbf20 ffffd000`28a45830 : nt!KiCommitThreadWait+0x127
ffffd000`28a45780 fffff803`4a3c5635 : ffffe000`0441d448 ffffd000`00000000 00000000`00000000 00000000`00000000 : nt!KeWaitForSingleObject+0x248
ffffd000`28a45820 fffff800`03e98e81 : ffffe000`0441d440 ffffe000`0441d420 ffffe000`0441d420 ffffe000`0637f010 : nt! ?? ::FNODOBFM::`string'+0x4c495
ffffd000`28a45860 fffff800`03e98165 : ffffe000`0637f010 fffff800`03eb3102 ffffe000`0637f010 fffff800`03eb3102 : bthport!BthHandleRemoveDevice+0x125
ffffd000`28a45900 fffff800`03e98011 : ffffe000`0637f010 fffff803`4a4e8b01 fffff800`03eb3190 00000000`c00000bb : bthport!BthHandlePnp+0x105
ffffd000`28a45960 fffff803`4a5f9a42 : ffffe000`0441d2d0 00000000`00000000 ffffe000`0637f010 ffffd000`201e7180 : bthport!BthDispatchPnp+0x71
ffffd000`28a459b0 fffff803`4a6a7544 : 00000000`00000002 ffffd000`28a45a79 ffffe000`0687e010 ffffe000`070b0060 : nt!IopSynchronousCall+0xfe
ffffd000`28a45a20 fffff803`4a30d72b : ffffc000`14ebe2a0 00000000`0000000a ffffe000`0687e010 00000000`0000000a : nt!IopRemoveDevice+0xe0
ffffd000`28a45ae0 fffff803`4a6a7065 : ffffe000`070b0060 ffffe000`0687e010 ffffc000`0ed2d010 ffffc000`05d98da0 : nt!PnpRemoveLockedDeviceNode+0x1a7
ffffd000`28a45b40 fffff803`4a6a6fde : 00000000`00000000 ffffc000`0ed2d010 ffffe000`0687e010 fffff803`4a6a6d01 : nt!PnpDeleteLockedDeviceNode+0x4d
ffffd000`28a45b80 fffff803`4a6f0d60 : ffffe000`070b0060 ffffe000`00000002 ffffe000`042b9b90 ffffe000`00000000 : nt!PnpDeleteLockedDeviceNodes+0x9a
ffffd000`28a45c00 fffff803`4a2bc1b9 : fffff803`4a6f0c9c ffffd000`28a45cd0 ffffe000`042b9b90 ffffe000`041e42c0 : nt!PnpDelayedRemoveWorker+0xc4
ffffd000`28a45c50 fffff803`4a2a82e4 : 028ddc20`028ddc20 ffffe000`041e42c0 ffffe000`041e42c0 ffffe000`0007d040 : nt!ExpWorkerThread+0x2b5
ffffd000`28a45d00 fffff803`4a36f2c6 : fffff803`4a509180 ffffe000`041e42c0 ffffe000`035e3700 028ddc20`028ddc20 : nt!PspSystemThreadStartup+0x58
ffffd000`28a45d60 00000000`00000000 : ffffd000`28a46000 ffffd000`28a40000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16

^^ Here we have a bit more of an informative stack. We can see a few Bluetooth Bus driver routines being called. Unfortunately, we don't have an IRP list to check. With that said, this is as far as we can go.


1. Ensure all of your Bluetooth drivers are up to date via Dell's website -

2. In your loaded drivers list, dtsoftbus01.sys is listed which is the Daemon Tools driver. Daemon Tools is a very popular cause of BSOD's in 7/8 based systems. Please uninstall Daemon Tools. Alternative imaging programs are: MagicISO, Power ISO, etc.

3. rimmpx64.sys - Fri Nov 17 20:49:50 2006

^^ Ricoh Memory Card Reader driver (OEM). There are no updates for this, so you'll want to uninstall the software (disable as well if possible, or remove the device if it's not built-in). The drivers are way too old to function with the OS.

4. If you're still crashing after all of the above, please enable Driver Verifier (and keep the next crash as a kernel-dump):

Driver Verifier:

What is Driver Verifier?

Driver Verifier is included in Windows 8/8.1, 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 NOT 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. To expand on this a bit more for the interested, specifically what Driver Verifier actually does is it looks for any driver making illegal function calls. When and/if this happens, system corruption occurs if allowed to continue. When Driver Verifier is enabled, it is monitoring all 3rd party drivers (as we have it set that way) and when it catches a driver attempting to do this, it will quickly flag that driver as being a troublemaker, and bring down the system safely before any corruption can occur.

- 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 detect it in violation almost straight away, 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 > 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.

If your OS became corrupt or you cannot boot into Windows after disabling verifier via Safe Mode:

- 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.

-- Note that Safe Mode for Windows 8 is a bit different, and you may need to try different methods: 5 Ways to Boot into Safe Mode in Windows 8 & Windows 8.1

How long should I keep Driver Verifier enabled for?

I recommend keeping it enabled for at least 24 hours. If you don't BSOD by then, disable Driver Verifier. I will usually say whether or not I'd like for you to keep it enabled any longer.

My system BSOD'd with Driver Verifier enabled, 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 February 12, 2018 Views 390 Applies to: