Looks like something has reported that a device does not exist - and then a second fault has the same error, which ends up bugchecking the machine. Let's see what the dump says:
Code:
6: kd> .bugcheck
Bugcheck code 0000007A
Arguments fffff6fc`400099b0 ffffffff`c000000e 00000002`f95b1860 fffff880`01336780
6: kd> !error ffffffff`c000000e
Error code: (NTSTATUS) 0xc000000e (3221225486) - A device which does not exist was specified.
// Looking at the context record, we can see that zero'ing data on disk caused a failure to be thrown:
6: kd> .cxr fffff880`0352af90
rax=00000000c000000e rbx=00000000c000000e rcx=fffff8800352af90
rdx=fffffa8016d07011 rsi=0000000000000e00 rdi=0000000000000000
rip=fffff80002eb91dc rsp=fffff8800352aed0 rbp=fffffa800dc94af0
r8=fffffa8016d07010 r9=fffff880030fb180 r10=fffffa800c782090
r11=fffff8800352b440 r12=fffffa8015ca60d0 r13=0000000000000e00
r14=00000000c000000e r15=0000000000000000
iopl=0 nv up ei ng nz na pe nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00200282
nt!RtlRaiseStatus+0x18:
fffff800`02eb91dc 488b8424b8010000 mov rax,qword ptr [rsp+1B8h] ss:0018:fffff880`0352b088=fffff80002eb91dc
// Here's the error being raised when calling CcZeroDataOnDisk:
6: kd> kn
*** Stack trace for last set context - .thread/.cxr resets it
# Child-SP RetAddr Call Site
00 fffff880`0352aed0 fffff800`02e22602 nt!RtlRaiseStatus+0x18
01 fffff880`0352b470 fffff800`030e4755 nt!CcZeroDataOnDisk+0x305
02 fffff880`0352b540 fffff880`0132c80b nt!CcZeroData+0x165
03 fffff880`0352b5a0 fffff880`0125cf58 Ntfs!NtfsZeroData+0xeb
04 fffff880`0352b660 fffff880`0125dc93 Ntfs!NtfsCommonWrite+0x2c28
05 fffff880`0352b810 fffff880`01072bcf Ntfs!NtfsFsdWrite+0x1c3
06 fffff880`0352b8d0 fffff880`010716df fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x24f
07 fffff880`0352b960 fffff800`02e7548b fltmgr!FltpDispatch+0xcf
08 fffff880`0352b9c0 fffff800`02e7571f nt!IoAsynchronousPageWrite+0x20b
09 fffff880`0352ba10 fffff800`02ec5390 nt! ?? ::FNODOBFM::`string'+0x5047b
0a fffff880`0352bb10 fffff800`03125456 nt!MiMappedPageWriter+0x198
0b fffff880`0352bc00 fffff800`02e7d2c6 nt!PspSystemThreadStartup+0x5a
0c fffff880`0352bc40 00000000`00000000 nt!KxStartSystemThread+0x16
// The I/O request for this thread ultimately points to zeros being attempted to be written on a .tmp file:
6: kd> !irp fffffa8016cad7a0
Irp is active with 10 stacks 10 is current (= 0xfffffa8016cadaf8)
Mdl=fffffa800ccba508: No System Buffer: Thread fffffa800c763040: Irp stack trace.
cmd flg cl Device File Completion-Context
[ 0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
>[ 4, 0] 0 0 fffffa800daa6030 fffffa800dc94af0 00000000-00000000
\FileSystem\Ntfs
Args: 00001000 00000000 00001000 00000000
6: kd> !devobj fffffa800daa6030
Device object (fffffa800daa6030) is for:
\FileSystem\Ntfs DriverObject fffffa800d36c870
Current Irp 00000000 RefCount 0 Type 00000008 Flags 00040000
DevExt fffffa800daa6180 DevObjExt fffffa800daa7ad0
ExtensionFlags (0x00000800) DOE_DEFAULT_SD_PRESENT
Characteristics (0000000000)
AttachedDevice (Upper) fffffa800d499de0 \FileSystem\FltMgr
Device queue is not busy.
6: kd> !fileobj fffffa800dc94af0
\Users\Michael\AppData\Local\Temp\~DF0BD74F45F1B89A91.TMP
LockOperation Set Device Object: 0xfffffa800d49ea50 \Driver\volmgr
Vpb: 0xfffffa800d709d20
Event signalled
Access: Read Write SharedRead
Flags: 0x40042
Synchronous IO
Cache Supported
Handle Created
FsContext: 0xfffff8a0038fe140 FsContext2: 0xfffff8a0038fe330
CurrentByteOffset: 0
Cache Data:
Section Object Pointers: fffffa801082b738
Shared Cache Map: 00000000
// If we look at the trap frame, we can see that there's **another** error in reading or writing within ntfs on the same thread:
6: kd> .trap 0xfffff88003529e40
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000001 rbx=0000000000000000 rcx=00000000000e6b01
rdx=fffff8800352b5a0 rsi=0000000000000000 rdi=0000000000000000
rip=fffff88001336780 rsp=fffff88003529fd8 rbp=fffff8800352a110
r8=fffff88001336780 r9=fffff8800352a110 r10=0000000000000000
r11=fffff8800352a048 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na pe nc
Ntfs! ?? ::NNGAKEGL::`string'+0x1da0:
fffff880`01336780 0000 add byte ptr [rax],al ds:00000000`00000001=??
// Here's the Ntfs function that caused the trap - it's another (hard) page fault, failing to disk; you can see it's trying to zero data:
6: kd> kn
# Child-SP RetAddr Call Site
00 fffff880`03529b28 fffff800`02efd212 nt!KeBugCheckEx
01 fffff880`03529b30 fffff800`02eb32ab nt!MiWaitForInPageComplete+0x426c2
02 fffff880`03529c10 fffff800`02e99b39 nt!MiIssueHardFault+0x28b
03 fffff880`03529ce0 fffff800`02e899ee nt!MmAccessFault+0x1399
04 fffff880`03529e40 fffff880`01336780 nt!KiPageFault+0x16e <-- Trap, 2nd (hard) fault
05 fffff880`03529fd8 fffff800`02eb776f Ntfs!NtfsZeroData$fin$0
06 fffff880`03529fe0 fffff800`02eb71bd nt!__C_specific_handler+0x13f
07 fffff880`0352a050 fffff800`02eb6c08 nt!zzz_AsmCodeRange_End
08 fffff880`0352a080 fffff800`02eb76fc nt!RtlUnwindEx+0x472
09 fffff880`0352a720 fffff880`01260125 nt!__C_specific_handler+0xcc
0a fffff880`0352a790 fffff800`02eb713d Ntfs!__GSHandlerCheck_SEH+0x75
0b fffff880`0352a7c0 fffff800`02eb5f15 nt!RtlpExecuteHandlerForException+0xd
0c fffff880`0352a7f0 fffff800`02eb9212 nt!RtlDispatchException+0x415
0d fffff880`0352aed0 fffff800`02e22602 nt!RtlRaiseStatus+0x4e <-- 1st fault
0e fffff880`0352b470 fffff800`030e4755 nt!CcZeroDataOnDisk+0x305
0f fffff880`0352b540 fffff880`0132c80b nt!CcZeroData+0x165
10 fffff880`0352b5a0 fffff880`0125cf58 Ntfs!NtfsZeroData+0xeb
11 fffff880`0352b660 fffff880`0125dc93 Ntfs!NtfsCommonWrite+0x2c28
12 fffff880`0352b810 fffff880`01072bcf Ntfs!NtfsFsdWrite+0x1c3
13 fffff880`0352b8d0 fffff880`010716df fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x24f
14 fffff880`0352b960 fffff800`02e7548b fltmgr!FltpDispatch+0xcf
15 fffff880`0352b9c0 fffff800`02e7571f nt!IoAsynchronousPageWrite+0x20b
16 fffff880`0352ba10 fffff800`02ec5390 nt!MiGatherMappedPages+0xffffffff`fffb0f3f
17 fffff880`0352bb10 fffff800`03125456 nt!MiMappedPageWriter+0x198
18 fffff880`0352bc00 fffff800`02e7d2c6 nt!PspSystemThreadStartup+0x5a
19 fffff880`0352bc40 00000000`00000000 nt!KxStartSystemThread+0x16
// Looking at the VA being referenced, it matches param 4 in the bugcheck:
6: kd> !pte @rip
VA fffff88001336780 <--- matches bugcheck param 4
PXE at FFFFF6FB7DBEDF88 PPE at FFFFF6FB7DBF1000 PDE at FFFFF6FB7E200048 PTE at FFFFF6FC400099B0
contains 00000003FEB84863 contains 00000003FEB83863 contains 0000000000BE0863 contains 00000002F95B1860
pfn 3feb84 ---DA--KWEV pfn 3feb83 ---DA--KWEV pfn be0 ---DA--KWEV not valid
Transition: 2f95b1
Protect: 3 - ExecuteRead
// What's the error here?
6: kd> dx -r1 ((Ntfs!_FILE_OBJECT *)0xfffff8800352a2e0)
((Ntfs!_FILE_OBJECT *)0xfffff8800352a2e0) : 0xfffff8800352a2e0 : [Type: _FILE_OBJECT *]
[Type: _FILE_OBJECT]
...
[+0x18] FsContext : 0xfffff8800125cf58 : [Type: void *]
[+0x20] FsContext2 : 0xfffff880c000000e : [Type: void *]
...
// The same as before...
6: kd> !error 0xfffff880c000000e
Error code: (NTSTATUS) 0xc000000e (3221225486) - A device which does not exist was specified.
// This appears to be the thread that triggered the device enumeration for the zeroing request, going through ataport:
6: kd> kn
*** Stack trace for last set context - .thread/.cxr resets it
# Child-SP RetAddr Call Site
00 fffff880`03392f60 fffff800`02e8f602 nt!KiSwapContext+0x7a
01 fffff880`033930a0 fffff800`02e9331f nt!KiCommitThreadWait+0x1d2
02 fffff880`03393130 fffff800`02ebac12 nt!KeWaitForSingleObject+0x19f
03 fffff880`033931d0 fffff800`02eb32ab nt!MiWaitForInPageComplete+0xc2
04 fffff880`033932b0 fffff800`02e99b39 nt!MiIssueHardFault+0x28b
05 fffff880`03393380 fffff800`02e899ee nt!MmAccessFault+0x1399
06 fffff880`033934e0 fffff880`00e1e93c nt!KiPageFault+0x16e
07 fffff880`03393678 fffff880`00e1c4ce ataport!ChannelQueryDeviceRelations
08 fffff880`03393680 fffff800`0324d74e ataport!IdePortDispatchPnp+0x22
09 fffff880`033936b0 fffff800`0324daba nt!PnpAsynchronousCall+0xce
0a fffff880`033936f0 fffff800`0324fe07 nt!PnpQueryDeviceRelations+0xfa
0b fffff880`033937b0 fffff800`032759ec nt!PipEnumerateDevice+0x117
0c fffff880`03393810 fffff800`03275ff8 nt!PipProcessDevNodeTree+0x21c
0d fffff880`03393a80 fffff800`02f8c087 nt!PiProcessReenumeration+0x98
0e fffff880`03393ad0 fffff800`02e954b5 nt!PnpDeviceActionWorker+0x327
0f fffff880`03393b70 fffff800`03125456 nt!ExpWorkerThread+0x111
10 fffff880`03393c00 fffff800`02e7d2c6 nt!PspSystemThreadStartup+0x5a
11 fffff880`03393c40 00000000`00000000 nt!KxStartSystemThread+0x16
// The I/O request on that thread does show us pending in the actual disk subsystem (\Driver\disk):
6: kd> !irp fffffa8016dae750
Irp is active with 10 stacks 4 is current (= 0xfffffa8016dae8f8)
Mdl=fffffa8015bdeef0: No System Buffer: Thread fffffa800c75a660: Irp stack trace.
cmd flg cl Device File Completion-Context
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
>[IRP_MJ_READ(3), N/A(34)]
12 e0 fffffa800d58e790 00000000 fffff88000fb61b0-00000000 Success Error Cancel
\Driver\Disk partmgr!PmReadWriteCompletion
Args: 00001000 00000000 2562575000 00000000
[IRP_MJ_READ(3), N/A(0)]
12 e0 fffffa800d58e1e0 00000000 fffff88000fc6010-fffffa800d49eba0 Success Error Cancel
\Driver\partmgr volmgr!VmpReadWriteCompletionRoutine
Args: 2137ae1099 00000000 2562575000 00000000
[IRP_MJ_READ(3), N/A(0)]
2 e0 fffffa800d49ea50 00000000 fffff880018d50a8-fffffa800d4a8a90 Success Error Cancel
\Driver\volmgr fvevol!FvePassThroughCompletion
Args: 00001000 00000000 2137ae1097 00000000
[IRP_MJ_READ(3), N/A(0)]
2 e0 fffffa800d4a8940 00000000 fffff88001007f40-fffffa80103b93d0 Success Error Cancel
\Driver\fvevol volsnap!VspReadCompletionRoutine
Args: 00001000 00000000 2562475000 00000000
[IRP_MJ_READ(3), N/A(0)]
2 e1 fffffa800d70c040 00000000 fffff880012479c0-00000000 Success Error Cancel pending
\Driver\volsnap Ntfs!NtfsPagingFileCompletionRoutine
Args: 00001000 00000000 2562475000 00000000
[IRP_MJ_READ(3), N/A(0)]
0 e1 fffffa800daa6030 fffffa800ec75ae0 fffff88001075e40-fffffa800d5c92d0 Success Error Cancel pending
\FileSystem\Ntfs fltmgr!FltpPassThroughCompletion
Args: 00001000 0a755000 2562475000 00000000
[IRP_MJ_READ(3), N/A(0)]
0 1 fffffa800d499de0 fffffa800ec75ae0 00000000-00000000 pending
\FileSystem\FltMgr
Args: 00001000 00000000 0a755000 00000000
\\ That thread is attempting to deal with pagefile.sys, which makes sense when there's a hard fault that requires read-in from disk to memory of something that was expected to be there:
6: kd> !fileobj fffffa800ec75ae0
\pagefile.sys
Device Object: 0xfffffa800d49ea50 \Driver\volmgr
Vpb: 0xfffffa800d709d20
Event signalled
Access: Read Write SharedWrite
Flags: 0x40008
No Intermediate Buffering
Handle Created
FsContext: 0xfffffa800ebe58d0 FsContext2: 0xfffffa800ec4b850
CurrentByteOffset: 0
Cache Data:
Section Object Pointers: fffffa800eaee378
Shared Cache Map: 00000000
// I cannot easily tell which device decided to "not exist" yet, but here are the two potential culprits:
6: kd> !object \driver\disk
Object: fffffa800d494c20 Type: (fffffa800c770400) Driver
ObjectHeader: fffffa800d494bf0 (new version)
HandleCount: 0 PointerCount: 4
Directory Object: fffff8a00007f060 Name: Disk
6: kd> !drvobj fffffa800d494c20
Driver object (fffffa800d494c20) is for:
\Driver\Disk
Driver Extension List: (id , addr)
(fffff8800194a7a0 fffffa800d4958c0)
Device Object list:
fffffa800d594790 fffffa800d58e790
// Western Digital Caviar Blue:
6: kd> !devstack fffffa800d594790
!DevObj !DrvObj !DevExt ObjectName
fffffa800d498940 \Driver\partmgr fffffa800d498a90
> fffffa800d594790 \Driver\Disk fffffa800d5948e0 DR1
fffffa800d35e680 \Driver\atapi fffffa800d35e7d0 IdeDeviceP1T0L0-1
!DevNode fffffa800d35f010 :
DeviceInst is "IDE\DiskWDC_WD10EZEX-00BN5A0____________________01.01A01\5&19c6f5b&0&1.0.0"
ServiceName is "disk"
// Samsung EVO SSD:
6: kd> !devstack fffffa800d58e790
!DevObj !DrvObj !DevExt ObjectName
fffffa800d58e1e0 \Driver\partmgr fffffa800d58e330
> fffffa800d58e790 \Driver\Disk fffffa800d58e8e0 DR0
fffffa800d352680 \Driver\atapi fffffa800d3527d0 IdeDeviceP0T0L0-0
!DevNode fffffa800d352140 :
DeviceInst is "IDE\DiskSamsung_SSD_850_EVO_250GB_______________EMT01B6Q\5&14562000&0&0.0.0"
ServiceName is "disk"
// Looks like there are indeed 2 known drives here:
6: kd> !driveinfo C
Drive C:, DriveObject fffff8a000379fe0
Directory Object: fffff8a000006330 Name: C:
Target String is '\Device\HarddiskVolume1'
Drive Letter Index is 3 (C:)
Volume DevObj: fffffa800d49ea50
Vpb: fffffa800d709d20 DeviceObject: fffffa800daa6030
FileSystem: \FileSystem\Ntfs
Volume has 0x28a8a67 (free) / 0x3a388ff (total) clusters of size 0x1000
166538 of 238473 MB free
6: kd> !driveinfo E
Drive E:, DriveObject fffff8a00037bb50
Directory Object: fffff8a000006330 Name: E:
Target String is '\Device\HarddiskVolume3'
Drive Letter Index is 5 (E:)
Volume DevObj: fffffa800d4a7cd0
Vpb: fffffa800d4a6910 DeviceObject: fffffa800da59030
FileSystem: \FileSystem\Ntfs
Volume has 0xd7113f0 (free) / 0xe8da5ff (total) clusters of size 0x1000
880916 of 953766 MB free
// In looking further at the ataport thread with the hard fault's I/O request, we can actually see that there's a corresponding I/O request to the actual disk via ataport, which appears to be the root cause of the problem:
6: kd> !irp fffffa80`0ece04e0
Irp is active with 2 stacks 2 is current (= 0xfffffa800ece05f8)
Mdl=fffffa8015bdeef0: No System Buffer: Thread 00000000: Irp stack trace.
cmd flg cl Device File Completion-Context
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
>[IRP_MJ_INTERNAL_DEVICE_CONTROL(f), N/A(0)]
12 e1 fffffa800d352680 00000000 fffff88001925a00-fffffa8010947b20 Success Error Cancel pending
\Driver\atapi CLASSPNP!TransferPktComplete
Args: fffffa8010947c40 00000000 00000000 fffffa8015c69b80
// Here's the device...
6: kd> !devobj fffffa800d352680
Device object (fffffa800d352680) is for:
IdeDeviceP0T0L0-0 \Driver\atapi DriverObject fffffa800d3339b0
Current Irp 00000000 RefCount 0 Type 00000007 Flags 00005050
Dacl fffff9a100490c70 DevExt fffffa800d3527d0 DevObjExt fffffa800d352f90 Dope fffffa800d48eaf0 DevNode fffffa800d352140
ExtensionFlags (0x00000800) DOE_DEFAULT_SD_PRESENT
Characteristics (0x00000100) FILE_DEVICE_SECURE_OPEN
AttachedDevice (Upper) fffffa800d58e790 \Driver\Disk
Device queue is not busy.
6: kd> !drvobj \Driver\atapi
Driver object (fffffa800d3339b0) is for:
\Driver\atapi
Driver Extension List: (id , addr)
(fffff88000e24008 fffffa800d3338f0)
Device Object list:
fffffa800d35e680 fffffa800d352680 fffffa800d340050 fffffa800d338050
// ...and here's the physical device underneath that decided to stop responding:
6: kd> !devstack fffffa800d352680
!DevObj !DrvObj !DevExt ObjectName
fffffa800d58e1e0 \Driver\partmgr fffffa800d58e330
fffffa800d58e790 \Driver\Disk fffffa800d58e8e0 DR0
> fffffa800d352680 \Driver\atapi fffffa800d3527d0 IdeDeviceP0T0L0-0
!DevNode fffffa800d352140 :
DeviceInst is "IDE\DiskSamsung_SSD_850_EVO_250GB_______________EMT01B6Q\5&14562000&0&0.0.0"
ServiceName is "disk"
Not sure if the WD played a part in this (it would appear they're both on the ATA bus in your system), but the boot drive going unavailable would make sense. I'd start by running chkdsk /r against both of your drives, making sure the 850's firmware is totally up-to-date, and that neither are throwing SMART errors. Failing that, I'd remove the WD blue drive (as it's known to cause freezes and crashes if it locks up) to make sure the SSD is indeed the culprit. If so, however, you probably want to swap that out for a functional drive.