New HDD Causing BSOD

alphaomega16 · 20 Apr 2015 at 15:48

Heya guys, I have had my system up and running now with 0 issues and no BSOD whatsoever but I recieved my 2x6TB HDD through today and I unplugged my DVD drive and connected one of the 6TB's to transfer some files over, first time it done around 800GB then BSOD with error code 2057.

Second time it managed around 400GB then proceeded to BSOD, third time I just tried copying 1 folder over and it ended up just acting like explorer had crashed but would not bring the taskbar back or any other icons.

These are some of the errors I am getting.

The computer has rebooted from a bugcheck. The bugcheck was: 0x0000007a (0xfffff6fc400486a8, 0xffffffffc00000c0, 0x000000006869a860, 0xfffff880090d5000). A dump was saved in: C:\Windows\MEMORY.DMP. Report Id: 042015-13696-01.

Another one here that has is listed under "Kernal-Power"
The system has rebooted without cleanly shutting down first. This error could be caused if the system stopped responding, crashed, or lost power unexpectedly.

EventData

BugcheckCode 122
BugcheckParameter1 0xfffff6fc400486a8
BugcheckParameter2 0xffffffffc00000c0
BugcheckParameter3 0x6869a860
BugcheckParameter4 0xfffff880090d5000
SleepInProgress false
PowerButtonTimestamp 0

Anyone have any ideas as to why just simply transferring files is doing this ?

The drives were recommended to be GPT Partition and not MBR, could this be an issue ?

Here is a bug check, I have the 6TB installed now and system is fine without trying to copy anything to the drive itself at the moment.

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

KERNEL_DATA_INPAGE_ERROR (7a)
The requested page of kernel data could not be read in. Typically caused by
a bad block in the paging file or disk controller error. Also see
KERNEL_STACK_INPAGE_ERROR.
If the error status is 0xC000000E, 0xC000009C, 0xC000009D or 0xC0000185,
it means the disk subsystem has experienced a failure.
If the error status is 0xC000009A, then it means the request failed because
a filesystem failed to make forward progress.
Arguments:
Arg1: fffff6fc400486a8, lock type that was held (value 1,2,3, or PTE address)
Arg2: ffffffffc00000c0, error status (normally i/o status code)
Arg3: 000000006869a860, current process (virtual address for lock type 3, or PTE)
Arg4: fffff880090d5000, virtual address that could not be in-paged (or PTE contents if arg1 is a PTE address)

Debugging Details:
------------------

TRIAGER: Could not open triage file : e:\dump_analysis\program\triage\modclass.ini, error 2

ERROR_CODE: (NTSTATUS) 0xc00000c0 - This device does not exist.

BUGCHECK_STR: 0x7a_c00000c0

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: CODE_CORRUPTION

PROCESS_NAME: System

CURRENT_IRQL: 0

TRAP_FRAME: fffff880039d98e0 -- (.trap 0xfffff880039d98e0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000001 rbx=0000000000000000 rcx=fffff88009067300
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff880090d5000 rsp=fffff880039d9a78 rbp=fffff800032702d8
r8=0000000000000000 r9=0000000000000000 r10=fffffffffffffffb
r11=00000000019745c8 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na po nc
srv!TerminateServer:
fffff880`090d5000 00a214700000 add byte ptr [rdx+7014h],ah ds:00000000`00007014=??
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff80003140542 to fffff800030d31c0

STACK_TEXT:
fffff880`039d95c8 fffff800`03140542 : 00000000`0000007a fffff6fc`400486a8 ffffffff`c00000c0 00000000`6869a860 : nt!KeBugCheckEx
fffff880`039d95d0 fffff800`030f9fff : fffffa80`09cc8af0 fffff880`039d9740 fffff800`03305540 fffffa80`09cc8af0 : nt! ?? ::FNODOBFM::`string'+0x3717a
fffff880`039d96b0 fffff800`030e0789 : 00000000`00000000 00000000`00000008 ffffffff`ffffffff 00000000`00000002 : nt!MiIssueHardFault+0x28b
fffff880`039d9780 fffff800`030d12ee : 00000000`00000008 fffff880`090d5000 00000000`00000000 fffffa80`08c1c5d0 : nt!MmAccessFault+0x1399
fffff880`039d98e0 fffff880`090d5000 : fffff880`090d7aa4 00000000`00000001 fffffa80`08c1c5d0 fffff800`032702d8 : nt!KiPageFault+0x16e
fffff880`039d9a78 fffff880`090d7aa4 : 00000000`00000001 fffffa80`08c1c5d0 fffff800`032702d8 00000000`00000000 : srv!TerminateServer
fffff880`039d9a80 fffff800`033c5633 : fffffa80`08c1c5d0 fffffa80`088e9110 fffffa80`0868c870 fffffa80`06705b50 : srv!SrvConfigurationThread+0x54
fffff880`039d9b40 fffff800`030dc841 : fffff800`03270200 fffff800`033c5601 fffffa80`06705b00 00000000`00000000 : nt!IopProcessWorkItem+0x23
fffff880`039d9b70 fffff800`03369e6a : 00000000`00000000 fffffa80`06705b50 00000000`00000080 fffffa80`066f15f0 : nt!ExpWorkerThread+0x111
fffff880`039d9c00 fffff800`030c3ec6 : fffff880`03765180 fffffa80`06705b50 fffff880`0376ffc0 00000000`00000000 : nt!PspSystemThreadStartup+0x5a
fffff880`039d9c40 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16

STACK_COMMAND: kb

MODULE_NAME: memory_corruption

IMAGE_NAME: memory_corruption

FOLLOWUP_NAME: memory_corruption

DEBUG_FLR_IMAGE_TIMESTAMP: 0

MEMORY_CORRUPTOR: LARGE_4096

FAILURE_BUCKET_ID: X64_MEMORY_CORRUPTION_LARGE_4096

BUCKET_ID: X64_MEMORY_CORRUPTION_LARGE_4096

Followup: memory_corruption
---------

I have had 0 issues with this system prior to installing this 6TB HDD today.

ED209 · 20 Apr 2015 at 16:09

might be worth doing a check disk on the drive.

do you have a spare sata cable to try as well, maybe worth trying a different sata port too?

can always remove the partition and then re create it all through disk management in windows

alphaomega16 · 20 Apr 2015 at 16:35

I am trying another port as I type this on my mobile, never encountered a bsod when copying files before.

ED209 · 20 Apr 2015 at 17:40

I would do a check disk as well just to make sure the drive is ok

alphaomega16 · 20 Apr 2015 at 20:15

Just changing port its been transferring ok for last 3 hours but im afraid to even load anything up like firefox, last time I upgraded from a 2tb to a 4tb I was able to transfer fine, have firefox open and play star trek online at the same time, I was doing the same with this 6tb for the first 800gb then it started to throw hissy fits.

Never had any issues like this and have not tried the second 6tb drive I received yet.

bledd · 20 Apr 2015 at 21:42

I've never seen this issue before.

Done a bit of reading on it.

Try one drive at a time, it's possible that either of these are causing the issue..

Faulty SATA cable
Faulty SATA port
Bad SATA driver
Faulty hard drive

I'd remove one of the new drives, then exhaust every testing combination above. Maybe leave the driver for now.

Then repeat the tests on the second drive.

With any brand new hard drive, I run a full disk check, it takes hours on a 6tb, but I still do it for peace of mind.

-

Also some reports that it could be a boot sector virus, run an AV scan too.

What is your system spec and which OS are you using?

alphaomega16 · 20 Apr 2015 at 22:25

I am only using 1 drive at a time to copy stuff to then replace with the second, I am using Windows 7, 750W PSU, 4 SATA and 1SSD Hard Drive. Different port didnt work so will try different power connecter, if it ends up being that it will be the second SATA power connect ive had issue with.

I done chkdsk e: from command but it done it in read only and took less than a minute and found no issues.

3570k CPU
MSI Z77A Motherboard
GTX 670 MSI
8GB Memory

All this is really making my stomach feel rough and I am getting all flushed and worried that my computer is going to bsod any moment, it only started after inserting the first 6TB drive.

I will remove it and leave machine running like it was before I ever installed it if it gives BSOD again.

I have not had a virus on this machine ever, I run weekly scan with Kaspersky and Malwarebytes and both come up clean.

Edit
I have all 3 dump files if someone more experienced wouldnt mind taking a look.

alphaomega16 · 20 Apr 2015 at 23:11

Here is the very first dump file

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

KERNEL_DATA_INPAGE_ERROR (7a)
The requested page of kernel data could not be read in. Typically caused by
a bad block in the paging file or disk controller error. Also see
KERNEL_STACK_INPAGE_ERROR.
If the error status is 0xC000000E, 0xC000009C, 0xC000009D or 0xC0000185,
it means the disk subsystem has experienced a failure.
If the error status is 0xC000009A, then it means the request failed because
a filesystem failed to make forward progress.
Arguments:
Arg1: fffff6fc4000c948, lock type that was held (value 1,2,3, or PTE address)
Arg2: ffffffffc000000e, error status (normally i/o status code)
Arg3: 00000001cd103860, current process (virtual address for lock type 3, or PTE)
Arg4: fffff880019292b0, virtual address that could not be in-paged (or PTE contents if arg1 is a PTE address)

Debugging Details:
------------------

TRIAGER: Could not open triage file : e:\dump_analysis\program\triage\modclass.ini, error 2

ERROR_CODE: (NTSTATUS) 0xc000000e - A device which does not exist was specified.

DISK_HARDWARE_ERROR: There was error with disk hardware

BUGCHECK_STR: 0x7a_c000000e

DEFAULT_BUCKET_ID: CODE_CORRUPTION

PROCESS_NAME: System

CURRENT_IRQL: 0

TRAP_FRAME: fffff88003b06f90 -- (.trap 0xfffff88003b06f90)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000001 rbx=0000000000000000 rcx=0000000000084101
rdx=fffff88003b08610 rsi=0000000000000000 rdi=0000000000000000
rip=fffff880019292b0 rsp=fffff88003b07128 rbp=fffff88003b07260
r8=fffff880019292b0 r9=fffff88003b07260 r10=0000000100000000
r11=fffff88003b07198 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na pe nc
Ntfs! ?? ::NNGAKEGL::`string'+0x709b:
fffff880`019292b0 0b00 or eax,dword ptr [rax] ds:00000000`00000001=????????
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff8000314b542 to fffff800030de1c0

STACK_TEXT:
fffff880`03b06c78 fffff800`0314b542 : 00000000`0000007a fffff6fc`4000c948 ffffffff`c000000e 00000001`cd103860 : nt!KeBugCheckEx
fffff880`03b06c80 fffff800`03104fff : fffffa80`0a5800e0 fffff880`03b06df0 fffff800`03310540 fffffa80`0a5800e0 : nt! ?? ::FNODOBFM::`string'+0x3717a
fffff880`03b06d60 fffff800`030eb789 : 00000000`00000000 00000000`00000008 ffffffff`ffffffff 00000000`00000000 : nt!MiIssueHardFault+0x28b
fffff880`03b06e30 fffff800`030dc2ee : 00000000`00000008 fffff880`019292b0 fffff880`01849300 fffff880`018878a0 : nt!MmAccessFault+0x1399
fffff880`03b06f90 fffff880`019292b0 : fffff800`0310945f fffff880`0189ca68 fffff880`03b07950 fffff880`03b07240 : nt!KiPageFault+0x16e
fffff880`03b07128 fffff800`0310945f : fffff880`0189ca68 fffff880`03b07950 fffff880`03b07240 fffff880`0184f5c5 : Ntfs! ?? ::NNGAKEGL::`string'+0x709b
fffff880`03b07130 fffff800`03108ead : fffff880`03b08610 fffff880`03b08610 00000000`00000000 fffff880`01836000 : nt!_C_specific_handler+0x13f
fffff880`03b071a0 fffff800`031088f8 : fffff880`03b08610 fffff880`03b07220 fffff880`0184fe28 fffff880`01836000 : nt!RtlpExecuteHandlerForUnwind+0xd
fffff880`03b071d0 fffff800`031093ec : fffff880`03b086f0 fffff880`018ba6bc fffff880`03b08010 ffffffff`c000000e : nt!RtlUnwindEx+0x472
fffff880`03b07870 fffff800`03108e2d : fffff880`01887b60 fffff880`03b086f0 00000000`00000000 fffff880`01836000 : nt!_C_specific_handler+0xcc
fffff880`03b078e0 fffff800`03107c05 : fffff880`01887b60 fffff880`03b07958 fffff880`03b08010 fffff880`01836000 : nt!RtlpExecuteHandlerForException+0xd
fffff880`03b07910 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!RtlDispatchException+0x415

STACK_COMMAND: kb

MODULE_NAME: memory_corruption

IMAGE_NAME: memory_corruption

FOLLOWUP_NAME: memory_corruption

DEBUG_FLR_IMAGE_TIMESTAMP: 0

MEMORY_CORRUPTOR: LARGE_4096

FAILURE_BUCKET_ID: X64_MEMORY_CORRUPTION_LARGE_4096

BUCKET_ID: X64_MEMORY_CORRUPTION_LARGE_4096

Followup: memory_corruption
---------

Here is the second.

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

KERNEL_DATA_INPAGE_ERROR (7a)
The requested page of kernel data could not be read in. Typically caused by
a bad block in the paging file or disk controller error. Also see
KERNEL_STACK_INPAGE_ERROR.
If the error status is 0xC000000E, 0xC000009C, 0xC000009D or 0xC0000185,
it means the disk subsystem has experienced a failure.
If the error status is 0xC000009A, then it means the request failed because
a filesystem failed to make forward progress.
Arguments:
Arg1: fffff6fc5005cbc0, lock type that was held (value 1,2,3, or PTE address)
Arg2: ffffffffc000000e, error status (normally i/o status code)
Arg3: 000000002c276880, current process (virtual address for lock type 3, or PTE)
Arg4: fffff8a00b9784f8, virtual address that could not be in-paged (or PTE contents if arg1 is a PTE address)

Debugging Details:
------------------

TRIAGER: Could not open triage file : e:\dump_analysis\program\triage\modclass.ini, error 2

ERROR_CODE: (NTSTATUS) 0xc000000e - A device which does not exist was specified.

DISK_HARDWARE_ERROR: There was error with disk hardware

BUGCHECK_STR: 0x7a_c000000e

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

PROCESS_NAME: svchost.exe

CURRENT_IRQL: 0

TRAP_FRAME: fffff88004e75330 -- (.trap 0xfffff88004e75330)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000001 rbx=0000000000000000 rcx=0000000000000000
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8000338eaf7 rsp=fffff88004e754c0 rbp=fffff8a001716530
r8=0000000000000001 r9=0000000000000001 r10=00000000000001ec
r11=fffff88004e75628 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na pe nc
nt!AlpcpWalkConnectionList+0x1f:
fffff800`0338eaf7 f0480fba6be000 lock bts qword ptr [rbx-20h],0 ds:ffffffff`ffffffe0=????????????????
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff80003147542 to fffff800030da1c0

STACK_TEXT:
fffff880`04e75018 fffff800`03147542 : 00000000`0000007a fffff6fc`5005cbc0 ffffffff`c000000e 00000000`2c276880 : nt!KeBugCheckEx
fffff880`04e75020 fffff800`03100fff : fffffa80`09c02450 fffff880`04e75190 fffff800`0330c600 fffffa80`09c02450 : nt! ?? ::FNODOBFM::`string'+0x3717a
fffff880`04e75100 fffff800`030e7789 : 00000000`00000000 00000000`00000001 ffffffff`ffffffff fffff800`030dd28f : nt!MiIssueHardFault+0x28b
fffff880`04e751d0 fffff800`030d82ee : 00000000`00000001 fffff8a0`0b9784f8 00000000`00000000 fffff8a0`0b978518 : nt!MmAccessFault+0x1399
fffff880`04e75330 fffff800`0338eaf7 : fffffa80`07ca3260 00000000`00000001 fffff880`03765180 fffff800`030ae5bb : nt!KiPageFault+0x16e
fffff880`04e754c0 fffff800`0337801a : 00000000`00000000 fffff8a0`0151a778 00000000`00000000 00000000`ffffffff : nt!AlpcpWalkConnectionList+0x1f
fffff880`04e754f0 fffff800`03378421 : fffffa80`0863cc00 fffff8a0`01716530 00000000`00000001 00000000`000007ff : nt!AlpcpDisconnectPort+0x2ce
fffff880`04e75550 fffff800`03378ee4 : fffffa80`0863cc00 00000000`00000001 fffff8a0`01716530 00000000`00000000 : nt!AlpcpDoPortCleanup+0x19
fffff880`04e75580 fffff800`033ccdc4 : 00000000`00000000 fffffa80`0863cbd0 00000000`00000000 fffff800`030e33dc : nt!AlpcpClosePort+0x44
fffff880`04e755b0 fffff800`033ccb81 : fffff8a0`01716530 fffff8a0`00000001 fffff8a0`01716530 00000000`00000000 : nt!ObpDecrementHandleCount+0xb4
fffff880`04e75630 fffff800`0338ce70 : 00000000`000001ec fffff8a0`01716530 fffff8a0`0171b7b0 00000000`000001ec : nt!ObpCloseHandleTableEntry+0xb1
fffff880`04e756c0 fffff800`0338cd68 : 00000000`00000004 00000000`00000000 fffffa80`085ad060 fffff800`0337a311 : nt!ObpCloseHandleProcedure+0x30
fffff880`04e75700 fffff800`0338d3ea : fffff8a0`0171a001 fffff880`04e75ae0 fffffa80`085ad060 00000000`00000001 : nt!ExSweepHandleTable+0x74
fffff880`04e75740 fffff800`033ab692 : fffff8a0`0171a060 00000000`00000000 00000000`00000000 00000000`00000000 : nt!ObKillProcess+0x62
fffff880`04e75780 fffff800`0338ebdd : 00000000`c0000006 fffff800`030e4f01 000007ff`fff92000 fffffa80`08706b50 : nt!PspExitThread+0x522
fffff880`04e75880 fffff800`030cccda : fffffa80`085ad060 fffff800`030e33dc fffffa80`40fe0088 fffff880`04e75b60 : nt!PsExitSpecialApc+0x1d
fffff880`04e758b0 fffff800`030cd020 : 00000000`0243f920 fffff880`04e75930 fffff800`0338eb50 00000000`00000001 : nt!KiDeliverApc+0x2ca
fffff880`04e75930 fffff800`030d94f7 : fffffa80`07ca3060 00000000`0243f808 fffff880`04e75a88 00000000`00000000 : nt!KiInitiateUserApc+0x70
fffff880`04e75a70 00000000`777318ca : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceExit+0x9c
00000000`0243f7e8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x777318ca

STACK_COMMAND: kb

FOLLOWUP_IP:
nt! ?? ::FNODOBFM::`string'+3717a
fffff800`03147542 cc int 3

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: nt! ?? ::FNODOBFM::`string'+3717a

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4fa390f3

FAILURE_BUCKET_ID: X64_0x7a_c000000e_nt!_??_::FNODOBFM::_string_+3717a

BUCKET_ID: X64_0x7a_c000000e_nt!_??_::FNODOBFM::_string_+3717a

Followup: MachineOwner

Here is the third.

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

KERNEL_DATA_INPAGE_ERROR (7a)
The requested page of kernel data could not be read in. Typically caused by
a bad block in the paging file or disk controller error. Also see
KERNEL_STACK_INPAGE_ERROR.
If the error status is 0xC000000E, 0xC000009C, 0xC000009D or 0xC0000185,
it means the disk subsystem has experienced a failure.
If the error status is 0xC000009A, then it means the request failed because
a filesystem failed to make forward progress.
Arguments:
Arg1: fffff6fc400486a8, lock type that was held (value 1,2,3, or PTE address)
Arg2: ffffffffc00000c0, error status (normally i/o status code)
Arg3: 000000006869a860, current process (virtual address for lock type 3, or PTE)
Arg4: fffff880090d5000, virtual address that could not be in-paged (or PTE contents if arg1 is a PTE address)

Debugging Details:
------------------

TRIAGER: Could not open triage file : e:\dump_analysis\program\triage\modclass.ini, error 2

ERROR_CODE: (NTSTATUS) 0xc00000c0 - This device does not exist.

BUGCHECK_STR: 0x7a_c00000c0

DEFAULT_BUCKET_ID: CODE_CORRUPTION

PROCESS_NAME: System

CURRENT_IRQL: 0

TRAP_FRAME: fffff880039d98e0 -- (.trap 0xfffff880039d98e0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000001 rbx=0000000000000000 rcx=fffff88009067300
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff880090d5000 rsp=fffff880039d9a78 rbp=fffff800032702d8
r8=0000000000000000 r9=0000000000000000 r10=fffffffffffffffb
r11=00000000019745c8 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na po nc
srv!TerminateServer:
fffff880`090d5000 00a214700000 add byte ptr [rdx+7014h],ah ds:00000000`00007014=??
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff80003140542 to fffff800030d31c0

STACK_TEXT:
fffff880`039d95c8 fffff800`03140542 : 00000000`0000007a fffff6fc`400486a8 ffffffff`c00000c0 00000000`6869a860 : nt!KeBugCheckEx
fffff880`039d95d0 fffff800`030f9fff : fffffa80`09cc8af0 fffff880`039d9740 fffff800`03305540 fffffa80`09cc8af0 : nt! ?? ::FNODOBFM::`string'+0x3717a
fffff880`039d96b0 fffff800`030e0789 : 00000000`00000000 00000000`00000008 ffffffff`ffffffff 00000000`00000002 : nt!MiIssueHardFault+0x28b
fffff880`039d9780 fffff800`030d12ee : 00000000`00000008 fffff880`090d5000 00000000`00000000 fffffa80`08c1c5d0 : nt!MmAccessFault+0x1399
fffff880`039d98e0 fffff880`090d5000 : fffff880`090d7aa4 00000000`00000001 fffffa80`08c1c5d0 fffff800`032702d8 : nt!KiPageFault+0x16e
fffff880`039d9a78 fffff880`090d7aa4 : 00000000`00000001 fffffa80`08c1c5d0 fffff800`032702d8 00000000`00000000 : srv!TerminateServer
fffff880`039d9a80 fffff800`033c5633 : fffffa80`08c1c5d0 fffffa80`088e9110 fffffa80`0868c870 fffffa80`06705b50 : srv!SrvConfigurationThread+0x54
fffff880`039d9b40 fffff800`030dc841 : fffff800`03270200 fffff800`033c5601 fffffa80`06705b00 00000000`00000000 : nt!IopProcessWorkItem+0x23
fffff880`039d9b70 fffff800`03369e6a : 00000000`00000000 fffffa80`06705b50 00000000`00000080 fffffa80`066f15f0 : nt!ExpWorkerThread+0x111
fffff880`039d9c00 fffff800`030c3ec6 : fffff880`03765180 fffffa80`06705b50 fffff880`0376ffc0 00000000`00000000 : nt!PspSystemThreadStartup+0x5a
fffff880`039d9c40 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16

STACK_COMMAND: kb

MODULE_NAME: memory_corruption

IMAGE_NAME: memory_corruption

FOLLOWUP_NAME: memory_corruption

DEBUG_FLR_IMAGE_TIMESTAMP: 0

MEMORY_CORRUPTOR: LARGE_4096

FAILURE_BUCKET_ID: X64_MEMORY_CORRUPTION_LARGE_4096

BUCKET_ID: X64_MEMORY_CORRUPTION_LARGE_4096

Followup: memory_corruption
---------

The e: drive in question was the actual 6TB HDD Assigned Letter.

alphaomega16 · 21 Apr 2015 at 00:09

I have removed the drive from my system, will leave it overnight running the way I usually have it to see if it has restarted during the night but so far ive loaded up and closed several things including games and so far have not had a blue screen.

I dont understand why a 6TB drive would cause issues, ive been fine with the 4TB Drives, I even have 2 of them.

If system runs fine I will run a check disk tomorrow on the 6TB I was having a problem with but I hate the sick feeling I get when something goes wrong, especially this expensive.

How long of a run are we looking at for the check disk.

Edit
I have the MSI Z77A-GD65 Motherboard and the current Intel(R) 7 Series/C216 Chipset Family SATA AHCI Controller - 1E02 Drivers say.

Driver Provider: Intel
Driver Date: 26/08/2011
Driver Version: 9.3.9.1011
Digital Signer: Microsoft Windows Hardware Compatibility Publisher.

Window had no issue whatsoever detecting and installing drivers for this and did not come up with any problems installing the driver so it should work ok shouldnt it ?

alphaomega16 · 21 Apr 2015 at 13:18

Well, I managed to last the night and morning up to now without a crash, even played a few games and done a bit of browsing since removing the 6TB Drive.

I will try the second 6TB I received to see if I get any problems with that one, if I dont then there must be something wrong with the first one, if I do then I dont know what to do

Edit
Trying the second drive now, already got sick feeling in my stomach.

Edit 2
Watching a youtube video and the ******* made my crap my pants, the video came up with the sound that happens when you connect and disconnect a drive after about 45s in his video.

alphaomega16 · 21 Apr 2015 at 17:47

I am currently running a check disk on the first drive on my old machine, what happens if it does another hissy fit and BSOD and reboots during the check ?

Also should I have formatted the drive before running the check ?

alphaomega16 · 21 Apr 2015 at 22:51

Just an update, after 10 hours I transferred 3.5TB of information from a 4TB Drive to the SECOND of the two 6TB Drives I ordered with 0 issues whilst also browsing the internet, watching youtube, twitch and even playing a couple of games and watching a film and a couple of TV shows whilst using the exact same Power + SATA Cable I did with the first.

First HDD is still going through the disk check but if it passes ok I will reinstall it in my machine, remove the partition and remake it then attempt to recopy the stuff over as I did with the second drive.

If I end up encountering the same issues would OCUK have any problem with an RMA due to this unusual issue, the second drive I received was perfect and has done a continuous transfer without interruption or going below 104mb/s whilst the first drive kept bouncing between 90-100mb/s.

I doubt it is a Power Cable, SATA Cable or Driver Issue as the second drive performed as it should, nearly 10 hours of continuous transfer without skipping a beat.

I will update thread once the Disk Check finishes on the first drive I was having an issue with.

alphaomega16 · 21 Apr 2015 at 23:35

Well, the Check Disk came back and found no issues, I will delete the partition and remake it tomorrow then attempt to recopy everything back over.

bledd · 21 Apr 2015 at 23:54

What model is your SSD?

What make is your PSU?

Have you tried other SATA cables?

alphaomega16 · 22 Apr 2015 at 00:06

Samsung 830
Akasa
Not tried another cable as I wanted to use the same one on the second so I could narrow down if it was infact the cable or the hard drive.

Second HDD I tried had 0 issues using same cables and same ports so either something went wrong with making the partition or something is overloading on the HDD when transferring the files over.

I managed to get everything over on the other drive in the end but the stability of the drive concerns me if its willing to BSOD when just idly transferring files.

I will retry the original drive tomorrow.

It is a very peculiar situation, one of which I have never experienced and hope not to again but we shall see tomorrow.

Edit
This is the Power Supply I have.

Hopefully OCUK doesnt have a problem with manufacturer links since they dont stock Akasa PSU's anymore.

http://www.akasa.co.uk/update.php?t...plies&type_sub=Main Stream&model=AK-PA075AM01

System is NOT overclocked, CPU rarely goes over 40 and never really above around 52, Hard drives dont go above 30-35.

bledd · 22 Apr 2015 at 10:37

That's fine, just checking it wasn't an ebay £15 special or something like that.

One of them could just be faulty, it can happen, intricate moving parts etc.. test them extensively one at a time.

Even if a hard drive is running at 100% constant load, it should never give you any errors, it should just slow down.

alphaomega16 · 22 Apr 2015 at 12:25

The first drive is back in now, going at the same 95mb/s as last time, its about 10mb/s slower than the second one I received.

If it blue screens on me again whilst doing the transfer after the second one was flawless I will have to give OC a ring, try to sort out an RMA because something is definitely wrong with it.

I assumed if the load was too much it would just slow down or if there was a power problem it would just disconnect the drive but as I said my system has been up for ~2 Years and I had never had a blue screen til I plugged that drive in.

EXTREMELY unusual occurrence.

alphaomega16 · 22 Apr 2015 at 20:58

Another Update.

Despite going at a solid 10mb/s slower than the second drive the original drive that started off the BSOD's and memory dumps did not occur, it took an hour longer than the other drive to copy all teh stuff over but it did do it without incident so I am at a loss as to what the **** happened.

I used the exact same cable, exact same port and it copied all 3.3TB of info over without interruption.

I really dont understand what happened.

bledd · 22 Apr 2015 at 21:07

What make are the new drives? I'd be inclined to run testing software from the manufacturer of the drive.

alphaomega16 · 22 Apr 2015 at 21:43

Western Digital Red NAS Drives.