Random F4 bsods on newly built pc

[michaell]

So ever since I have built my new computer I have been getting this f4 bsod and I have no clue whats causing it. I have done the steps listed below but I still get it.

PC Specs:
Intel I7 4790k
GTX 970 ssc
MSI Z97S Krait Edition motherboard
Corsair vengeance 16gb ram
Samsung 850 evo 250gb ssd
WD blue 1tb hd

What I have done:
Updated all drivers
Checked ssd driver and it is fully up to date
Ran memtest 86 on ram and got no failures
Ran windows memory diagnostics and got no errors
Ran check disk on both ssd and hdd and got no errors
Changed sata cables on both my ssd and hdd
Ran driver verifier
Ran malwarebytes to check for malware and viruses

I have attached the zipped folder from dm log collector and the minidumps of the f4 bsods.

 

[cluberti]

Something is crashing both winint and csrss processes on the system. Given they both have very different purposes in life, the likelihood is you have a driver that's causing issues if the hardware tests out OK. Unfortunately with minidumps, there's little information available (in this case it's an access denied/access violation, as far as can be told, but nothing further) to use to troubleshoot. In the case of an F4, we'd need a kernel dump to gather what's going on with any level of certainty. However, I'd start with upgrading all of the drivers in the system (which you've said you've already done), making sure the machine is fully patched, and then configure the machine for a kernel memory dump (not a minidump). Note you'll need a paging file that's approximately 4GB in size on the Windows volume to make sure you can capture a kernel dump the next time a crash occurs.

 

[michaell]

Something is crashing both winint and csrss processes on the system. Given they both have very different purposes in life, the likelihood is you have a driver that's causing issues if the hardware tests out OK. Unfortunately with minidumps, there's little information available (in this case it's an access denied/access violation, as far as can be told, but nothing further) to use to troubleshoot. In the case of an F4, we'd need a kernel dump to gather what's going on with any level of certainty. However, I'd start with upgrading all of the drivers in the system (which you've said you've already done), making sure the machine is fully patched, and then configure the machine for a kernel memory dump (not a minidump). Note you'll need a paging file that's approximately 4GB in size on the Windows volume to make sure you can capture a kernel dump the next time a crash occurs.

Thanks for the reply, my system was apparently already setup for a kernel memory dump and it is located in the windows folder. How would I upload it to here? Its like 769mb.

 

[cluberti]

You'd be best served zipping it up to your desktop first, then uploading it to your OneDrive, DropBox, Google Drive, etc. account. Short of that, a public file sharing site would also work. Once you've uploaded the .zipped file, share the link.

 

[michaell]

You'd be best served zipping it up to your desktop first, then uploading it to your OneDrive, DropBox, Google Drive, etc. account. Short of that, a public file sharing site would also work. Once you've uploaded the .zipped file, share the link.

Ah okay, here it is: https://onedrive.live.com/redir?resid=9352901A85C6DBF0!123&authkey=!AE6z97WSTujKGlU&ithint=file,zip

 

[cluberti]

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:

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.

 

[michaell]

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:

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.

Thanks for analyzing the error. I ran ckdsk /r on both drives and no errors came up, I also used WD digital data life guard to do an advanced scan the drive for errors and no errors came up. I also checked the smart status of both drives and it is all ok. I also checked my ssd's firmware to make sure that it is indeed up to date. I'm thinking it's the WD drive that might be causing the problems. Should I contact WD for a rma or should I just take out the drive and see if the bsods occur again. How would I be able to take out the WD drive if basically all my programs and games are on it. Will windows throw any errors if I take it out?

 

[cluberti]

Windows will, indeed, complain about it if anything from the OS is on there, any startup items, etc. I'd suggest making a backup of your installation that you can restore after testing, and just unplug the drive after you've got a good backup. You probably want to use another (external) drive for the backup, if possible, for obvious reasons .