This blog is focused on a simple but effective lesson.
Descriptions about BSOD error codes are from my own opinion based on 1.5+ year BSOD debugging experience.
I don’t know much about DPC’s, wait operations, attach processes and yields. While analyzing the issue I have not been able to analyze the related dump in-depth. Information provided could be incorrect, but are from my own thoughts about the situation.
Some information about the situation:

The problem description:
I have previously backed up successfully without issues. Last night I tried backing up, expecting to see successful completion in the morning, but instead I found my computer had restarted. I downloaded the latest version of AOMEI Backupper & tried again. This time I was sitting in front of the computer when I got the BSOD.

I have a Dell Precision M4800 running Windows 10. Was attempting to back up to a Seagate Backup Plus 5TB drive. Same hardware as I have used successfully in the past.

I’ve attached the output of the Log Collector and a photo of the BSOD.

Will much appreciate any help in tracking this down and eliminating it.


The BSOD present with usual causes
– 0xB8,

  • Device driver

I have little experience with this BSOD, I’ve seen it 2-3 times, so I again can’t tell from my own experience what possible causes could be related to it.

Having no idea what this BSOD is about, I decided to just dive into the BSOD dump.
* *
* Bugcheck Analysis *
* *

Use !analyze -v to get detailed debugging information.

BugCheck 100000B8, {fffff801a99bf940, ffff80059b716080, 0, 0}

*** WARNING: Unable to verify timestamp for ambakdrv.sys
*** ERROR: Module load completed but symbols could not be loaded for ambakdrv.sys
Probably caused by : ambakdrv.sys ( ambakdrv+1835 )

Followup: MachineOwner

A wait operation, attach process, or yield was attempted from a DPC routine.
This is an illegal operation and the stack track will lead to the offending
code and original DPC routine.
Arg1: fffff801a99bf940, Original thread which is the cause of the failure
Arg2: ffff80059b716080, New thread
Arg3: 0000000000000000, Stack address of the original thread
Arg4: 0000000000000000

Debugging Details:

0: kd> kb
# RetAddr : Args to Child : Call Site
00 fffff801`a9667f5c : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSwapContext+0x76
01 fffff801`a96679ff : ffff8005`a7f11702 ffffe440`02cdffa0 00000000`00000000 00000000`00000000 : nt!KiSwapThread+0x17c
02 fffff801`a96697c7 : 00000041`00000000 ffff8005`a79c6800 00000000`00000004 00000000`00000000 : nt!KiCommitThreadWait+0x14f
03 fffff80e`2e3c1835 : ffff8005`ac4d4f50 ffff8005`00000000 ffff8005`aaefca00 fffff80e`00000000 : nt!KeWaitForSingleObject+0x377
04 ffff8005`ac4d4f50 : ffff8005`00000000 ffff8005`aaefca00 fffff80e`00000000 00000000`00000000 : ambakdrv+0x1835
05 ffff8005`00000000 : ffff8005`aaefca00 fffff80e`00000000 00000000`00000000 00000000`00004000 : 0xffff8005`ac4d4f50
06 ffff8005`aaefca00 : fffff80e`00000000 00000000`00000000 00000000`00004000 ffff8005`ac07a678 : 0xffff8005`00000000
07 fffff80e`00000000 : 00000000`00000000 00000000`00004000 ffff8005`ac07a678 ffff8005`ac07a660 : 0xffff8005`aaefca00
08 00000000`00000000 : 00000000`00004000 ffff8005`ac07a678 ffff8005`ac07a660 00000000`00004000 : 0xfffff80e`00000000

All we can see here is that the Aomei driver is calling WaitForSingleObject to put this thread into a wait-state.

With this information, the usual many would do is simply suggesting to either update or remove Aomei. It is the Aomei driver that for some reason needs to wait for something else. However, Aomei is imaging the file system, why does Aomei call this function from a DPC routine?

The answer can’t be retrieved from the minidump, so I decided to have a look at the event logs and see if there is anything interesting.
Sure enough, there are lots of events about I/O operations that have been retried
Log Name: System
Source: disk
Date: 2016-12-12T23:37:02.311
Event ID: 153
Task: N/A
Level: Warning
Opcode: N/A
Keyword: Classic
User: N/A
User Name: N/A
Computer: Yosh-M4800
The IO operation at logical block address 0x5e380 for Disk 1 (PDO name: \Device\Scsi\O2FJ2RDR1Port1Path0Target0Lun0) was retried.

Although, these events are a few months old, I decided to investigate why there were so many I/O operations retried.
The user ran HDTune and provided a few interesting screenshots, one screenshot shows a benchmark where the transfer rate was 2.2MB/s average which is incredibly slow.
HDTune transfer rate

Another screenshot shows an error scan which includes the speedmap. This speedmap shows that a large amount of blocks are slowly accessed.
HDTune speedmap

My guess is that Aomei called WaitForSingleObject because it had to wait for the file system to respond.

The user replaced the hard drive with a SSD, fixing slow performance issues and the 0xB8 crashes.

The lesson I learned from this, don’t always go straight for what looks like to be the cause but look for more relevant information that you can use to identify the root cause.


BSOD Index

Leave a Reply

Your email address will not be published. Required fields are marked *