*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 77, {1, 67006f006c005c, 0, fffff88015a86e80}
Probably caused by : ntkrnlmp.exe ( nt! ?? ::FNODOBFM::`string'+51e31 )
Followup: MachineOwner
---------
2: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
KERNEL_STACK_INPAGE_ERROR (77)
The requested page of kernel data could not be read in. Caused by
bad block in paging file or disk controller error.
In the case when the first arguments is 0 or 1, the stack signature
in the kernel stack was not found. Again, bad hardware.
An I/O status of c000009c (STATUS_DEVICE_DATA_ERROR) or
C000016AL (STATUS_DISK_OPERATION_FAILED) normally indicates
the data could not be read from the disk due to a bad
block. Upon reboot autocheck will run and attempt to map out the bad
sector. If the status is C0000185 (STATUS_IO_DEVICE_ERROR) and the paging
file is on a SCSI disk device, then the cabling and termination should be
checked. See the knowledge base article on SCSI termination.
Arguments:
Arg1: 0000000000000001, (page was retrieved from disk)
Arg2: 0067006f006c005c, value found in stack where signature should be
Arg3: 0000000000000000, 0
Arg4: fffff88015a86e80, address of signature on kernel stack
Debugging Details:
------------------
ERROR_CODE: (NTSTATUS) 0x1 - STATUS_WAIT_1
BUGCHECK_STR: 0x77_1
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT
PROCESS_NAME: System
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from fffff80001f54b01 to fffff80001ed8fc0
STACK_TEXT:
fffff880`0252ba18 fffff800`01f54b01 : 00000000`00000077 00000000`00000001 0067006f`006c005c 00000000`00000000 : nt!KeBugCheckEx
fffff880`0252ba20 fffff800`01f0cc54 : fffffa80`0922db50 fffffa80`00000001 fffffa80`04160b50 00000000`00000000 : nt! ?? ::FNODOBFM::`string'+0x51e31
fffff880`0252bb30 fffff800`01f0cbef : fffffa80`09e9eb30 00000000`00000000 fffffa80`0368d5f0 00000000`00000000 : nt!MmInPageKernelStack+0x40
fffff880`0252bb90 fffff800`01f0c928 : 00000000`00000000 00000000`00000000 00000000`00000080 fffffa80`0368d5f0 : nt!KiInSwapKernelStacks+0x1f
fffff880`0252bbc0 fffff800`0216fe5a : 48f5246c`8d411a69 6c850fcf`3b480e8b 8348cdff`4100079e 0fe875ef`3b4408c6 : nt!KeSwapProcessOrStack+0x84
fffff880`0252bc00 fffff800`01ec9d26 : fffff880`009b9180 fffffa80`036ae040 fffff880`009c3fc0 58247c8b`48502474 : nt!PspSystemThreadStartup+0x5a
fffff880`0252bc40 00000000`00000000 : fffff880`0252c000 fffff880`02526000 fffff880`0252b770 00000000`00000000 : nt!KiStartSystemThread+0x16
STACK_COMMAND: kb
FOLLOWUP_IP:
nt! ?? ::FNODOBFM::`string'+51e31
fffff800`01f54b01 cc int 3
SYMBOL_STACK_INDEX: 1
SYMBOL_NAME: nt! ?? ::FNODOBFM::`string'+51e31
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 503f82be
FAILURE_BUCKET_ID: X64_0x77_1_nt!_??_::FNODOBFM::_string_+51e31
BUCKET_ID: X64_0x77_1_nt!_??_::FNODOBFM::_string_+51e31
Followup: MachineOwner
---------