Hi,
At the end of each day I make a copy of a database to usb stick. Since a few weeks Im getting BSODs at the end of backup process (WinDbg report below) every few days, however recently the problem got worse - Im getting it almost every day. After reboot the database backup is usually succesful. Backup process is the only situation when BSOD occurs, so I hope its not HDD failure - its relatively new, about 1 year old, SMART tests dont show any problems (no bad sectors as well).
WinDbg report:
BugCheck 7A, {fffff6fb80008000, ffffffffc000000e, 8bc9c880, fffff70001000000}
Probably caused by : ntkrnlmp.exe ( nt! ?? ::FNODOBFM::`string'+36c1a )
Followup: MachineOwner
---------
0: kd> !analyze -v
*******************************************************************************
* *
* 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: fffff6fb80008000, lock type that was held (value 1,2,3, or PTE address)
Arg2: ffffffffc000000e, error status (normally i/o status code)
Arg3: 000000008bc9c880, current process (virtual address for lock type 3, or PTE)
Arg4: fffff70001000000, virtual address that could not be in-paged (or PTE contents if arg1 is a PTE address)
Debugging Details:
------------------
ERROR_CODE: (NTSTATUS) 0xc000000e - Okre
DISK_HARDWARE_ERROR: There was error with disk hardware
BUGCHECK_STR: 0x7a_c000000e
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
PROCESS_NAME: sqlbrowser.exe
CURRENT_IRQL: 0
TRAP_FRAME: fffff88007520dd0 -- (.trap 0xfffff88007520dd0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffff70001080068 rbx=0000000000000000 rcx=000000000000000b
rdx=0000000000000001 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8000339f68a rsp=fffff88007520f60 rbp=000000000000000b
r8=fffff70001000000 r9=0000000000000078 r10=fffff80003206880
r11=ffffffffffffffff r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na pe nc
nt!MiInsertVadCharges+0x10a:
fffff800`0339f68a 490fa308 bt qword ptr [r8],rcx ds:2b30:fffff700`01000000=0000000000000000
Resetting default scope
LAST_CONTROL_TRANSFER: from fffff800030fca12 to fffff80003088ec0
STACK_TEXT:
fffff880`07520ab8 fffff800`030fca12 : 00000000`0000007a fffff6fb`80008000 ffffffff`c000000e 00000000`8bc9c880 : nt!KeBugCheckEx
fffff880`07520ac0 fffff800`030b08b7 : fffffa80`04fe52b0 fffff880`07520c30 fffffa80`06c32ec8 fffffa80`04fe52b0 : nt! ?? ::FNODOBFM::`string'+0x36c1a
fffff880`07520ba0 fffff800`030971ca : 00000000`00000000 00000000`00000000 ffffffff`ffffffff 00000000`00000000 : nt!MiIssueHardFault+0x28b
fffff880`07520c70 fffff800`03086fee : 00000000`00000000 fffff700`01000000 00000000`00000000 00000000`017af000 : nt!MmAccessFault+0x146a
fffff880`07520dd0 fffff800`0339f68a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiPageFault+0x16e
fffff880`07520f60 fffff800`033844b0 : 00000000`00000000 ffffffff`ffffffff 00000000`00000000 00000000`000007ff : nt!MiInsertVadCharges+0x10a
fffff880`07520ff0 fffff800`03088153 : ffffffff`ffffffff fffffa80`06e2b060 00000000`00000000 fffff880`075213b8 : nt!NtAllocateVirtualMemory+0x1bf0
fffff880`07521190 fffff800`03084710 : fffff800`03379e12 ffffffff`ffffffff fffff880`07521770 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
fffff880`07521398 fffff800`03379e12 : ffffffff`ffffffff fffff880`07521770 00000000`00000000 00000000`00000000 : nt!KiServiceLinkage
fffff880`075213a0 fffff800`03088153 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!NtSetInformationProcess+0x3a1
fffff880`075216f0 fffff800`03084710 : fffff800`033796f2 00000000`00000000 fffff800`0338595f 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
fffff880`07521888 fffff800`033796f2 : 00000000`00000000 fffff800`0338595f 00000000`00000000 fffffa80`03665a08 : nt!KiServiceLinkage
fffff880`07521890 fffff800`03378070 : 00000000`00004000 00000000`00040000 00000000`00000000 00000000`00001000 : nt!RtlCreateUserStack+0x122
fffff880`07521980 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!PspAllocateThread+0x5bb
STACK_COMMAND: kb
FOLLOWUP_IP:
nt! ?? ::FNODOBFM::`string'+36c1a
fffff800`030fca12 cc int 3
SYMBOL_STACK_INDEX: 1
SYMBOL_NAME: nt! ?? ::FNODOBFM::`string'+36c1a
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 54d0317d
FAILURE_BUCKET_ID: X64_0x7a_c000000e_nt!_??_::FNODOBFM::_string_+36c1a
BUCKET_ID: X64_0x7a_c000000e_nt!_??_::FNODOBFM::_string_+36c1a
Followup: MachineOwner
At the end of each day I make a copy of a database to usb stick. Since a few weeks Im getting BSODs at the end of backup process (WinDbg report below) every few days, however recently the problem got worse - Im getting it almost every day. After reboot the database backup is usually succesful. Backup process is the only situation when BSOD occurs, so I hope its not HDD failure - its relatively new, about 1 year old, SMART tests dont show any problems (no bad sectors as well).
WinDbg report:
BugCheck 7A, {fffff6fb80008000, ffffffffc000000e, 8bc9c880, fffff70001000000}
Probably caused by : ntkrnlmp.exe ( nt! ?? ::FNODOBFM::`string'+36c1a )
Followup: MachineOwner
---------
0: kd> !analyze -v
*******************************************************************************
* *
* 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: fffff6fb80008000, lock type that was held (value 1,2,3, or PTE address)
Arg2: ffffffffc000000e, error status (normally i/o status code)
Arg3: 000000008bc9c880, current process (virtual address for lock type 3, or PTE)
Arg4: fffff70001000000, virtual address that could not be in-paged (or PTE contents if arg1 is a PTE address)
Debugging Details:
------------------
ERROR_CODE: (NTSTATUS) 0xc000000e - Okre
DISK_HARDWARE_ERROR: There was error with disk hardware
BUGCHECK_STR: 0x7a_c000000e
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
PROCESS_NAME: sqlbrowser.exe
CURRENT_IRQL: 0
TRAP_FRAME: fffff88007520dd0 -- (.trap 0xfffff88007520dd0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffff70001080068 rbx=0000000000000000 rcx=000000000000000b
rdx=0000000000000001 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8000339f68a rsp=fffff88007520f60 rbp=000000000000000b
r8=fffff70001000000 r9=0000000000000078 r10=fffff80003206880
r11=ffffffffffffffff r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na pe nc
nt!MiInsertVadCharges+0x10a:
fffff800`0339f68a 490fa308 bt qword ptr [r8],rcx ds:2b30:fffff700`01000000=0000000000000000
Resetting default scope
LAST_CONTROL_TRANSFER: from fffff800030fca12 to fffff80003088ec0
STACK_TEXT:
fffff880`07520ab8 fffff800`030fca12 : 00000000`0000007a fffff6fb`80008000 ffffffff`c000000e 00000000`8bc9c880 : nt!KeBugCheckEx
fffff880`07520ac0 fffff800`030b08b7 : fffffa80`04fe52b0 fffff880`07520c30 fffffa80`06c32ec8 fffffa80`04fe52b0 : nt! ?? ::FNODOBFM::`string'+0x36c1a
fffff880`07520ba0 fffff800`030971ca : 00000000`00000000 00000000`00000000 ffffffff`ffffffff 00000000`00000000 : nt!MiIssueHardFault+0x28b
fffff880`07520c70 fffff800`03086fee : 00000000`00000000 fffff700`01000000 00000000`00000000 00000000`017af000 : nt!MmAccessFault+0x146a
fffff880`07520dd0 fffff800`0339f68a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiPageFault+0x16e
fffff880`07520f60 fffff800`033844b0 : 00000000`00000000 ffffffff`ffffffff 00000000`00000000 00000000`000007ff : nt!MiInsertVadCharges+0x10a
fffff880`07520ff0 fffff800`03088153 : ffffffff`ffffffff fffffa80`06e2b060 00000000`00000000 fffff880`075213b8 : nt!NtAllocateVirtualMemory+0x1bf0
fffff880`07521190 fffff800`03084710 : fffff800`03379e12 ffffffff`ffffffff fffff880`07521770 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
fffff880`07521398 fffff800`03379e12 : ffffffff`ffffffff fffff880`07521770 00000000`00000000 00000000`00000000 : nt!KiServiceLinkage
fffff880`075213a0 fffff800`03088153 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!NtSetInformationProcess+0x3a1
fffff880`075216f0 fffff800`03084710 : fffff800`033796f2 00000000`00000000 fffff800`0338595f 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
fffff880`07521888 fffff800`033796f2 : 00000000`00000000 fffff800`0338595f 00000000`00000000 fffffa80`03665a08 : nt!KiServiceLinkage
fffff880`07521890 fffff800`03378070 : 00000000`00004000 00000000`00040000 00000000`00000000 00000000`00001000 : nt!RtlCreateUserStack+0x122
fffff880`07521980 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!PspAllocateThread+0x5bb
STACK_COMMAND: kb
FOLLOWUP_IP:
nt! ?? ::FNODOBFM::`string'+36c1a
fffff800`030fca12 cc int 3
SYMBOL_STACK_INDEX: 1
SYMBOL_NAME: nt! ?? ::FNODOBFM::`string'+36c1a
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 54d0317d
FAILURE_BUCKET_ID: X64_0x7a_c000000e_nt!_??_::FNODOBFM::_string_+36c1a
BUCKET_ID: X64_0x7a_c000000e_nt!_??_::FNODOBFM::_string_+36c1a
Followup: MachineOwner