WXP Fehlermeldung entschlüsseln

Mein System hat gerade einen Neustart durchgeführt, Fehlermeldung siehe unten. Bräuchte mal einen Tip, wo oder wie ich nachschauen kann, was das bedeutet...

Kannst mir ja mal deine minidump als zip hochladen.
Ich lasse die dann mal durch den Debugger laufen.
Vielleicht zeigt es was an.

Viele Grüße

Fiona

Ok, hängt dran...

Sieht nach ntoskrnl.exe aus.

Aus Windebug;

BugCheck A, {8562077c, 2, 0, 80516a55}

Probably caused by : ntoskrnl.exe ( nt!IopRemoveLockedDeviceNode+52 )

Followup: MachineOwner

Aus Kernel-Debug;

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 8562077c, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 80516a55, address which referenced memory

FOLLOWUP_IP:
nt!IopRemoveLockedDeviceNode+52
80516a55 8b420c mov eax,[edx+0xc]

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: nt!IopRemoveLockedDeviceNode+52

MODULE_NAME: nt

IMAGE_NAME: ntoskrnl.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 3ea80977

STACK_COMMAND: kb

BUCKET_ID: 0xA_nt!IopRemoveLockedDeviceNode+52

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

Habe erst mal ein Vorschlag!

Start / Ausführen

Kopiere die von der CD oder wenn du Servicepack1 hast (nehme mal an WinXP
) mit dem Befehl "expand"
Beispiel von WinXP-CD:
C:\>EXPAND CD-Laufwerk:\I386\NTOSKRNL.EX_ C:\TEMP\NTOSKRNL.EXE
Beispiel von Servicepack1;
Expand Laufwerk:\xpservicepack1\ntoskrnl.ex_ C:\TEMP\ntoskrnl.exe

Neustart im abgesicherten Modus.

Lösche ntoskrnl.exe im Ordner C:\WINDOWS\system32
Kopiere von C:\Temp\ntoskrnl.exe zu C:\WINDOWS\system32

Vielleicht hilfts!

Viele Grüße

Fiona

WOW! *dickeskarrmageb*

Erst mal vielen dank, vielleicht sollte ich noch erwähnen, hab ich vergessen, das mein System übertaktet ist. Seit drei Tagen läuft es mit einer WaKü, dabei ist mir aufgefallen, daß die NB deutlich wärmer wird (+6°C an der Kühlkörperoberfläche), da ich natürlich einige Lüfter entfernt habe. Könnte es damit zusammenhängen?

Wollte als erstes mal wieder Lüfter einbauen zum testen. Das System lief vorher tagelang zum SETI-Crunchen ohne Probs.

Ich weiß, never change a running system!

Ich poste noch mal, wenn ich umgebaut habe, falls der Fehler wieder auftaucht, werde ich deinen Tip ausprobieren!
---
Edit: kann dir gerade kein Karma geben, mach ich aber sobald als möglich!

@Fiona
Ich glaube nicht, daß es an der NTOSKRNL.EXE liegt. Die Interrupt Request Level-Bluescreens resultieren fast immer aus einem unsauber programmierten Treiber, der auf Kernelkomponenten zugreifen möchte, dafür aber nicht den passenden IRQ-Level hat. Um eine Unterbrechungsanfrage an eine Kernelkomponente senden zu können, muß die aufrufende Komponente (z.B. der Treiber) einen gleichen oder niedrigeren IRQL haben.

Bei mir kommt das raus:

1: kd> !analyze -v

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 8562077c, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 80516a55, address which referenced memory

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


READ_ADDRESS: 8562077c

CURRENT_IRQL: 2

FAULTING_IP:
nt!MiDeletePte+15d
80516a55 8b420c mov eax,[edx+0xc]

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xA

LAST_CONTROL_TRANSFER: from 80516e65 to 80516a55

TRAP_FRAME: ef893b38 -- (.trap ffffffffef893b38)
ErrCode = 00000000
eax=00939eee ebx=c00052fc ecx=003134fa edx=85620770 esi=00ee5360 edi=0001b824
eip=80516a55 esp=ef893bac ebp=ef893bd0 iopl=0 nv up ei pl nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010206
nt!MiDeletePte+0x15d:
80516a55 8b420c mov eax,[edx+0xc] ds:0023:8562077c=????????
Resetting default scope

STACK_TEXT:
ef893bd0 80516e65 c00052fc 014bf000 00000000 nt!MiDeletePte+0x15d
ef893c90 8050fda9 00000000 01590fff 00000000 nt!MiDeleteVirtualAddresses+0x149
ef893ca8 80595d96 01490000 01590fff ef893d64 nt!MiDeleteFreeVm+0x1d
ef893d4c 805306a4 ffffffff 0012dae0 0012db28 nt!NtFreeVirtualMemory+0x42e
ef893d4c 7ffe0304 ffffffff 0012dae0 0012db28 nt!KiSystemService+0xc9
0012da88 00000000 00000000 00000000 00000000 SharedUserData!SystemCallStub+0x4


FOLLOWUP_IP:
nt!MiDeletePte+15d
80516a55 8b420c mov eax,[edx+0xc]

SYMBOL_STACK_INDEX: 0

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: nt!MiDeletePte+15d

MODULE_NAME: nt

DEBUG_FLR_IMAGE_TIMESTAMP: 3ea80977

STACK_COMMAND: .trap ffffffffef893b38 ; kb

IMAGE_NAME: memory_corruption

BUCKET_ID: 0xA_nt!MiDeletePte+15d

Followup: MachineOwner

Habe es noch mal laufen lassen!
Hier ist von mir volle Bugcheck Analysis

Edit:

Microsoft (R) Windows Debugger Version 6.3.0017.0
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\TEMP\Mini071704-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: F:\Debugsymbols
Executable search path is:
Unable to load image ntoskrnl.exe, Win32 error 2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
Windows XP Kernel Version 2600 (Service Pack 1) MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Kernel base = 0x804d4000 PsLoadedModuleList = 0x8054a230
Debug session time: Sat Jul 17 09:10:31 2004
System Uptime: 0 days 0:58:04.651
Unable to load image ntoskrnl.exe, Win32 error 2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
Loading Kernel Symbols
.....................................................................................................
Loading unloaded module list
..........
Loading User Symbols
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {8562077c, 2, 0, 80516a55}

Probably caused by : ntoskrnl.exe ( nt!IopRemoveLockedDeviceNode+52 )

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

1: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 8562077c, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 80516a55, address which referenced memory

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


READ_ADDRESS: 8562077c

CURRENT_IRQL: 2

FAULTING_IP:
nt!IopRemoveLockedDeviceNode+52
80516a55 8b420c mov eax,[edx+0xc]

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xA

LAST_CONTROL_TRANSFER: from 805334b1 to 804f5471

STACK_TEXT:
ef893b1c 805334b1 0000000a 8562077c 00000002 nt!MiUpdateWsle+0x64
ef893b38 81fd8514 ef893bb4 f83d88ff f83d88ce nt!_vsnwprintf+0x69
WARNING: Frame IP not in any known module. Following frames may be wrong.
80fbf400 00000000 00000000 00000000 00000000 0x81fd8514


STACK_COMMAND: .bugcheck ; kb

FOLLOWUP_IP:
nt!IopRemoveLockedDeviceNode+52
80516a55 8b420c mov eax,[edx+0xc]

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: nt!IopRemoveLockedDeviceNode+52

MODULE_NAME: nt

IMAGE_NAME: ntoskrnl.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 3ea80977

BUCKET_ID: 0xA_nt!IopRemoveLockedDeviceNode+52

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


Weiß nicht warum die unterschiedlich sind?
Neuesten Symbole werden gerade auch noch mal installiert und getestet!
Edit:
Gibt auch eine neue Version Debugger 6.3.17.0 wird auch mal alles aktualisiert.
Werde die Werte hier posten.

@ Fiona:

Sorry wenn ich jetzt dumm frag', aber ich kenn mich da nicht sooo gut aus!

Ist dieser Debugger bzw. Windebug ein Programm, wo man irgendwelche "Fehlercodes" eingeben kann und dieses Prog. einem dann sagt, was da schuld sein könnte?

Wenn ja, wo kann ich dieses Prog. Downloaden?
Wenn ja, welchen "Fehlercode" muss ich da dann verwenden dass dann auch etwas entsprechendes "herauskommt"!

Wie gesgat sorry für die dumme Frage aber könntest du mir dass bitte genauer erklären?

PS: auf CB unter Downloads habe ich sowohl nach "Debugger" als auch nach "WinDebug" gesucht --> KEINE Ergeb.

Den Windebugger gibt es hier!

http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx

Die Symbole dazu gibt es hier!

http://www.microsoft.com/whdc/devtools/debugging/symbolpkg.mspx

Da ist eigentlich alles auf englisch in der Hilfe beschrieben.
Du kannst die Fehlerdatei die Windows speichert zum Beispiel memory.dmp oder mini.dmp laden und analysieren lassen. Für den Kerneldebugger gibt es noch mal Parameter wie !analyze -v und andere. Da müsstest du dich einlesen.
Viele Grüße

Fiona

Fiona schrieb:

Den Windebugger gibt es hier!

http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx

Die Symbole dazu gibt es hier!

http://www.microsoft.com/whdc/devtools/debugging/symbolpkg.mspx

Viele Grüße

Fiona

Zum Vergrößern anklicken....

Ich habe unter 'Symbol File Path' folgedes eingetragen:
SRV*e:\SymbolPath*http://msdl.microsoft.com/download/symbols
Die Debugger-Version stimmt mit Deiner überein.

e:\Symbolpath ist ein beliebiges Verzeichnis auf dem lokalen Rechner.

Hierbei werden die benötigten Dateien bei Bedarf nachgeladen.

Wie gesagt: Einen Fehler im Windows Kernel zu finden ist viel unwahrscheinlicher, als einen fehlerhaft programmierten Treiber zu installieren

Wäre auch schlimm wenn der Kernel einen Fehler hätte!
Ich hatte noch eine ältere Version glaube 6.2 usw. .
Jetzt nicht mehr!
Deine Idee mit den benötigten Symbolen vom Microsoft-Server zu laden ist nicht schlecht, da immer auf dem neuesten Stand.
Trotzdem werde ich die noch mal downloaden und installieren damit ich da Fehler ausschließen kann und die Werte nochmal vergleichen.

Viele Grüße Fiona

Danke mal für den Hinweis!

Ich denke mal war Speicherfehler wegem übertakten wie er schon geschrieben hatte. Sowas sollte man natürlich vorher nicht verschweigen, wenn man fragt. Denke dann kann es auch mal den Kernel erwischen. Exe-Dateien sind ja auch in den Symbolen mit drin. War sicher für mich auch ungewohnt die ntoskrnl.exe da drin zu haben.

ACM Microsoft® Audio Compression Manager files
COM Executable files (.com)
CPL Control Panel programs
DLL Dynamic-link library files (.dll)
DRV Driver files (.drv)
EXE Executable files (.exe)
SCR Screen-saver files
SYS Driver files (.sys)

Viele Grüße

Fiona

Edit:

Habe alles neu installiert und laufen lassen.
Habe oben über Edit: nochmal den gesamten Bugcheck geladen.
Das Ergebniss bleibt leider so und zeigt weiterhin ntoskrnl.exe an.
Schaue dir auch mal die Windebug-Meldung an.

Viele Grüße

Fiona

Zunächst noch mal vielen Dank an euch!

@Fiona: der von dir beschriebene Weg die ntoskrnl.exe zu ersetzen schlug leider fehl, das System fuhr nicht mehr hoch.
War keine Problem, da auf dem Rechner kaum was instaliert war. Hab gestern auch wieder auf Luftkühlung umgebaut, da ich ich an der NB mit WaKü einen massiven Temperaturanstieg messen konnte, ein zusätzlicher Lüfter brachte kaum Besserung.

Ich dachte halt, es wäre möglich, aus der Fehlermeldung etwas herauszubekommen, ob das System wegen Überhitzung runter gefahren wurde. Ist für mich auch Neuland.

Heute morgen hab ich den Rechner komplett neu aufgesetzt, Temps immer noch zu hoch und Prime (Test ohne RAM) zeigte bei FSB 233 relativ schnell einen Fehler an, allerdings nicht bei FSB 200!
An dieser Stelle: der Rechner verbrachte bis vor 3 Tagen im Prinzip jeden Tag zwischen 6 h - 8 h über 3 Monate mit FSB 233 zum SETI-Crunchen, keine Abstürze, super stabil! [Edit: mit VCore auf Auto, unter Last so ca 1,26 V - 1,28 V)]

Die Vermutliche Ursache für den Fehler dürfte sein, das die CPU (P43,0E) einen Schaden bekommen hat, als ich sie kurzzeitig auf FSB 255 mit 1,600 V liefen lies.
Wollte halt mal schauen, was die WaKü bringt... (nein, nicht hauen, bitte)

Mit einer leicht erhöten Spannung (1,3750 V) läuft auch Prime wieder ohne Fehler bei FSB 233, bis jetzt. Das Problem hierbei ist ein massiver Temperaturanstieg gegenüber früher (sowohl bei FSB 200 als auch FSB 233), Ich vermute mal durch erhöhte Elektronenmigration (meine zumindest, so was mal gelesen zu haben).

Irgendwie musste ich den Fehler halt eingrenzen.

PS: kann mich jetzt auch in den Hardware-Zerstörer-Thread eintragen...

Habe bei mir noch mal geschaut!
Ntoskrnl.exe ist bereits 5.1.2600.1240 (xpsp2.030618-0119).
Die hat Microsoft wahrscheinlich mit Hotfix zu Servicepack 2 wahrscheinlich in einem Sicherheitspack geändert.
Vielleicht daher die Probleme.

Viele Grüße

Fiona

Wenn ich das minidump-File vom aktuellen WinDbg 6.3.17.0 interpretieren lasse , bekomme ich das gleiche Ergebnis wie FBrenner -> memory_corruption

Ich habe die Symbole auch mal von Microsoft-Server geladen und getestet.
Bekomme auch wie ihr das selbe Ergebniss.


Microsoft (R) Windows Debugger Version 6.3.0017.0
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\TEMP\Mini071704-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*e:\SymbolPath*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows XP Kernel Version 2600 (Service Pack 1) MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp2.030422-1633
Kernel base = 0x804d4000 PsLoadedModuleList = 0x8054a230
Debug session time: Sat Jul 17 09:10:31 2004
System Uptime: 0 days 0:58:04.651
Loading Kernel Symbols
.....................................................................................................
Loading unloaded module list
..........
Loading User Symbols
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {8562077c, 2, 0, 80516a55}

Probably caused by : memory_corruption ( nt!MiDeletePte+15d )

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

1: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 8562077c, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 80516a55, address which referenced memory

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


READ_ADDRESS: 8562077c

CURRENT_IRQL: 2

FAULTING_IP:
nt!MiDeletePte+15d
80516a55 8b420c mov eax,[edx+0xc]

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xA

LAST_CONTROL_TRANSFER: from 80516e65 to 80516a55

TRAP_FRAME: ef893b38 -- (.trap ffffffffef893b38)
ErrCode = 00000000
eax=00939eee ebx=c00052fc ecx=003134fa edx=85620770 esi=00ee5360 edi=0001b824
eip=80516a55 esp=ef893bac ebp=ef893bd0 iopl=0 nv up ei pl nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010206
nt!MiDeletePte+0x15d:
80516a55 8b420c mov eax,[edx+0xc] ds:0023:8562077c=????????
Resetting default scope

STACK_TEXT:
ef893bd0 80516e65 c00052fc 014bf000 00000000 nt!MiDeletePte+0x15d
ef893c90 8050fda9 00000000 01590fff 00000000 nt!MiDeleteVirtualAddresses+0x149
ef893ca8 80595d96 01490000 01590fff ef893d64 nt!MiDeleteFreeVm+0x1d
ef893d4c 805306a4 ffffffff 0012dae0 0012db28 nt!NtFreeVirtualMemory+0x42e
ef893d4c 7ffe0304 ffffffff 0012dae0 0012db28 nt!KiSystemService+0xc9
0012da88 00000000 00000000 00000000 00000000 SharedUserData!SystemCallStub+0x4


FOLLOWUP_IP:
nt!MiDeletePte+15d
80516a55 8b420c mov eax,[edx+0xc]

SYMBOL_STACK_INDEX: 0

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: nt!MiDeletePte+15d

MODULE_NAME: nt

DEBUG_FLR_IMAGE_TIMESTAMP: 3ea80977

STACK_COMMAND: .trap ffffffffef893b38 ; kb

IMAGE_NAME: memory_corruption

BUCKET_ID: 0xA_nt!MiDeletePte+15d

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

Wenn man aber die Symbole (171 MB) von Micrososft komplett runterladet und installiert, bekommt man das andere Ergebniss!
Ich möchte das noch mal ergänzen mit meinem Test.
Ich habe aus dem Symbolordner der Vollversion die *.exe Dateien rausgenommen.
Dann bekommen ich auch das selbe Ergebniss wie ihr.
Könnt ihr testen wenn ihr auch mal die *.exe Symbole ladet.
Daher der Unterschied.

Viele Grüße

Fiona