KERNEL_DATA_INPAGE_ERROR (7a) и софтбэды, что причина а что следствие?

Question

[SagePtr]

Система вылетела в синьку с ошибкой KERNEL_DATA_INPAGE_ERROR.
Проверил первым же делом жёсткий, нашёл на нём pending sectors, которые при дальнейшем лечении викторией оказались софт-бэдами и после зануления пропали.
Кластеры приходились на левый файл, не имеющий никакого отношения к системе (по тому смещению лежал файл локализации к программе, которая от силы запускалась раз в пару месяцев и в момент сбоя не была запущена). Возможно, в тот момент, когда система вылетела, проводилась фоновая дефрагментация (в планировщике она как раз на 7 часов назначена)

Вопрос вот в чём: это Windows вылетел в синьку из-за софтбэда на диске? Или софтбэд на диске образовался из-за выпадения Windows в синьку? Или эти события вообще не связаны между собой?

*******************************************************************************
*                                                                             *
*                        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: fffff6fc50006a88, lock type that was held (value 1,2,3, or PTE address)
Arg2: ffffffffc0000185, error status (normally i/o status code)
Arg3: 00000000ae861820, current process (virtual address for lock type 3, or PTE)
Arg4: fffff8a000d513cc, virtual address that could not be in-paged (or PTE contents if arg1 is a PTE address)

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


ERROR_CODE: (NTSTATUS) 0xc0000185 - <Unable to get error code text>

DISK_HARDWARE_ERROR: There was error with disk hardware

BUGCHECK_STR:  0x7a_c0000185

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

PROCESS_NAME:  System

CURRENT_IRQL:  0

TRAP_FRAME:  fffff880031400a0 -- (.trap 0xfffff880031400a0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffff8a000d513cc rbx=0000000000000000 rcx=0000000000000000
rdx=00000000ffffffff rsi=0000000000000000 rdi=0000000000000000
rip=fffff80003395900 rsp=fffff88003140230 rbp=fffff88003140660
 r8=fffff8a0000520e0  r9=000000000000ffff r10=fffff8000324d000
r11=fffffa800777a020 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl zr na po nc
nt!CmpFindValueByNameFromCache+0xe0:
fffff800`03395900 428b14b8        mov     edx,dword ptr [rax+r15*4] ds:fffff8a0`00d513cc=????????
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff80003139fd2 to fffff800030c5380

STACK_TEXT:  
fffff880`0313fd88 fffff800`03139fd2 : 00000000`0000007a fffff6fc`50006a88 ffffffff`c0000185 00000000`ae861820 : nt!KeBugCheckEx
fffff880`0313fd90 fffff800`030ec74f : fffffa80`07074010 fffff880`0313ff00 fffff800`03304600 fffffa80`07074010 : nt! ?? ::FNODOBFM::`string'+0x3140a
fffff880`0313fe70 fffff800`030d29c9 : 00000000`00000000 00000000`00000000 ffffffff`ffffffff fffff880`00000002 : nt!MiIssueHardFault+0x28b
fffff880`0313ff40 fffff800`030c34ae : 00000000`00000000 fffff8a0`00d513cc fffff880`03140300 fffff8a0`00024010 : nt!MmAccessFault+0x1399
fffff880`031400a0 fffff800`03395900 : fffff8a0`00024010 00000000`011073c8 fffff8a0`000520e0 fffff880`031403a0 : nt!KiPageFault+0x16e
fffff880`03140230 fffff800`03390976 : fffff8a0`02d756f8 fffff880`03140520 fffff880`03140360 fffff880`03140368 : nt!CmpFindValueByNameFromCache+0xe0
fffff880`03140300 fffff800`0339575f : 00000000`00000000 fffff880`03140520 fffff880`00000002 fffff8a0`24408010 : nt!CmQueryValueKey+0x136
fffff880`031403e0 fffff800`030c4613 : fffffa80`069f1b50 fffff880`03140798 fffffa80`00000002 fffff8a0`24408010 : nt!NtQueryValueKey+0x37d
fffff880`03140570 fffff800`030c0bd0 : fffff800`03406c27 00000000`00000000 fffff880`03140958 fffff8a0`10cc0600 : nt!KiSystemServiceCopyEnd+0x13
fffff880`03140778 fffff800`03406c27 : 00000000`00000000 fffff880`03140958 fffff8a0`10cc0600 00000000`00000000 : nt!KiServiceLinkage
fffff880`03140780 fffff800`034a29b3 : 00000000`00000000 fffffa80`0cb36038 00000000`00000000 ffffffff`80001b00 : nt! ?? ::NNGAKEGL::`string'+0x167d1
fffff880`031408f0 fffff800`034aa673 : fffff880`03140ac0 00000000`00000000 00000000`0000030a 00000000`00000308 : nt!PnpDisableDeviceInterfaces+0x153
fffff880`031409c0 fffff800`034ab987 : fffffa80`0cb36010 00000000`00000000 00000000`00000003 00000000`000007ff : nt!PnpSurpriseRemoveLockedDeviceNode+0x133
fffff880`03140a00 fffff800`034abaa0 : 00000000`00000000 fffff8a0`1e6da500 fffff8a0`199d22a0 fffff880`03140b58 : nt!PnpDeleteLockedDeviceNode+0x37
fffff880`03140a30 fffff800`035493ef : 00000000`00000002 00000000`00000000 fffffa80`0cb36010 00000000`00000000 : nt!PnpDeleteLockedDeviceNodes+0xa0
fffff880`03140aa0 fffff800`03549fac : fffff880`03140c78 fffffa80`072c2500 fffffa80`069f1b00 fffffa80`00000000 : nt!PnpProcessQueryRemoveAndEject+0x6cf
fffff880`03140be0 fffff800`03433506 : 00000000`00000000 fffffa80`072c2560 fffff8a0`1e6da5f0 00000000`00000000 : nt!PnpProcessTargetDeviceEvent+0x4c
fffff880`03140c10 fffff800`030ce355 : fffff800`0332cb68 fffff8a0`1e6da5f0 fffff800`0326e2d8 fffffa80`069f1b50 : nt! ?? ::NNGAKEGL::`string'+0x4a32b
fffff880`03140c70 fffff800`0335e476 : 00000000`00000000 fffffa80`069f1b50 00000000`00000080 fffffa80`06976b10 : nt!ExpWorkerThread+0x111
fffff880`03140d00 fffff800`030b6726 : fffff880`009ef180 fffffa80`069f1b50 fffff880`009f9f40 00000000`00000000 : nt!PspSystemThreadStartup+0x5a
fffff880`03140d40 00000000`00000000 : fffff880`03141000 fffff880`0313b000 fffff880`0313fae0 00000000`00000000 : nt!KxStartSystemThread+0x16


STACK_COMMAND:  kb

FOLLOWUP_IP: 
nt! ?? ::FNODOBFM::`string'+3140a
fffff800`03139fd2 cc              int     3

SYMBOL_STACK_INDEX:  1

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

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

IMAGE_NAME:  ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  56eb24e6

FAILURE_BUCKET_ID:  X64_0x7a_c0000185_nt!_??_::FNODOBFM::_string_+3140a

BUCKET_ID:  X64_0x7a_c0000185_nt!_??_::FNODOBFM::_string_+3140a

Followup: MachineOwner
---------

Answer 1

[Александр Молокович]

В синий экран система может вылететь только если на месте критически фажного системного файла оказался нечитаемый сектор. В любом другом случае, система может разве что тормозить. Даже если бы сбойный сектор действительно оказался в месте хранения критически фажного системного файла и диск самостоятельно выполнил при этом ремап (а операционная система показала синий экран), то при следующем запуске, ОС не загрузилась бы из-за того, что при выполнении ремапа файл был бы испорчен.
Если ошибка больше не повторяется, то нет смысла искать её причину.