springi
Goto Top

Minidump Auswertung - Unterstützung gesucht

Hallo Community,

ich habe eine Minidump auswerten lassen, da mein Rechner in letzter Zeit immer wieder "freezed". Gestern hatte ich dann "endlich" ein Bluescreen und somit ein Minidump. Leider kann ich aus dem Dumpfile nicht eindeutig erkennen ob ein Bad Block im Memory oder im Disk vorhanden ist. Vielleicht könnt ihr mehr daraus erkennen. Vielen Dank vorab!

Hier das Ergebnis, der Dumpfile Auswertung über WinDbg:

icrosoft (R) Windows Debugger Version 6.9.0003.113 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [D:\Share\Mini111408-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*your local symbol folder*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows XP Kernel Version 2600 (Service Pack 2) MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp_sp2_qfe.070227-2300
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055c700
Debug session time: Fri Nov 14 16:11:40.111 2008 (GMT+1)
System Uptime: 0 days 5:01:38.125
Loading Kernel Symbols
Loading User Symbols
Loading unloaded module list
*
  • *
  • Bugcheck Analysis *
  • *
*

Use !analyze -v to get detailed debugging information.

BugCheck 77, {1, 0, 0, ab622960}

Probably caused by : memory_corruption ( nt!MmInPageKernelStack+176 )

Followup: MachineOwner

0: 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: 00000001, (page was retrieved from disk)
Arg2: 00000000, value found in stack where signature should be
Arg3: 00000000, 0
Arg4: ab622960, 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: DRIVER_FAULT

PROCESS_NAME: System

LAST_CONTROL_TRANSFER: from 8051228e to 804f9f13

STACK_TEXT:
bad2fd58 8051228e 00000077 00000001 00000000 nt!KeBugCheckEx+0x1b
bad2fd8c 8053f106 00dad538 00000000 8a896458 nt!MmInPageKernelStack+0x176
bad2fda4 8053f5d6 89dad598 805cea08 00000000 nt!KiInSwapKernelStacks+0x16
bad2fdac 805cea08 00000000 00000000 00000000 nt!KeSwapProcessOrStack+0x7c
bad2fddc 8054546e 8053f55a 00000000 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16


STACK_COMMAND: kb

FOLLOWUP_IP:
nt!MmInPageKernelStack+176
8051228e 8a550b mov dl,byte ptr [ebp+0Bh]

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: nt!MmInPageKernelStack+176

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

DEBUG_FLR_IMAGE_TIMESTAMP: 45e5484a

IMAGE_NAME: memory_corruption

FAILURE_BUCKET_ID: 0x77_1_nt!MmInPageKernelStack+176

BUCKET_ID: 0x77_1_nt!MmInPageKernelStack+176

Followup: MachineOwner

Content-Key: 108799

Url: https://administrator.de/contentid/108799

Printed on: April 23, 2024 at 23:04 o'clock