KERNEL_DATA_INPAGE_ERROR (7a) and softbads, what is the cause and what is the effect?

Question

Hard disks

The system crashed with a KERNEL_DATA_INPAGE_ERROR error.
The first thing I checked was the hard one, I found pending sectors on it, which, with further treatment with Victoria, turned out to be soft-bads and disappeared after zeroing.
The clusters fell on the left file, which had nothing to do with the system (at that offset, there was a localization file for the program, which was launched once every couple of months at most and was not launched at the time of failure). Perhaps, at the moment when the system crashed, a background defragmentation was being carried out (in the scheduler it was just scheduled for 7 hours)
. Or was the soft-bad on the disk formed due to Windows falling into blue? Or are these events completely unrelated?

*******************************************************************************
*                                                                             *
*                        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

The system can crash into the blue screen only if there is an unreadable sector in place of the critical system file. In any other case, the system can only slow down. Even if the bad sector really ended up in the storage location of the critical system file and the disk performed the remap on its own (and the operating system showed a blue screen), then the next time it was started, the OS would not boot due to the fact that when the remap was performed, the file was would be spoiled.
If the error is no longer repeated, then there is no point in looking for its cause.