Random F4 bsods on newly built pc


  1. Posts : 4
    Windows 7 64 bit
       #1

    Random F4 bsods on newly built pc


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


  2. Posts : 2,528
    Windows 10 Pro x64
       #2

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


  3. Posts : 4
    Windows 7 64 bit
    Thread Starter
       #3

    cluberti said:
    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.
      My Computer


  4. Posts : 2,528
    Windows 10 Pro x64
       #4

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


  5. Posts : 4
    Windows 7 64 bit
    Thread Starter
       #5

    cluberti said:
    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?resi...int=file%2czip
      My Computer


  6. Posts : 2,528
    Windows 10 Pro x64
       #6

    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.
    Last edited by cluberti; 10 Jun 2015 at 13:24.
      My Computer


  7. Posts : 4
    Windows 7 64 bit
    Thread Starter
       #7

    cluberti said:
    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.
    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?
    Last edited by michaell; 11 Jun 2015 at 09:02.
      My Computer


  8. Posts : 2,528
    Windows 10 Pro x64
       #8

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


 

  Related Discussions
Our Sites
Site Links
About Us
Windows 7 Forums is an independent web site and has not been authorized, sponsored, or otherwise approved by Microsoft Corporation. "Windows 7" and related materials are trademarks of Microsoft Corp.

© Designer Media Ltd
All times are GMT -5. The time now is 15:18.
Find Us