bluescreen memory management

[ad0r]

Hallo,

hatte leider gerade einen Bluescreen "memory management". Der PC war im "Energie sparen" Modus und beim starten trat der Bluescreen auf. Win 7 x64.
Vielleicht hat ja ein Profi eine Idee dazu.
Der PC läuft seit etwas über einem Jahr ohne Probleme. Vor ca. 4 Monaten wurde eine Grafikkarte nachgerüstet, sonst ist immer alles gleich geblieben.
Keine Übertaktungen oder so.

Hier die Minidump Auswertung:

Spoiler

MEMORY_MANAGEMENT (1a) # Any other values for parameter 1 must be individually examined.
Arguments:
Arg1: 0000000000041790, A page table page has been corrupted. On a 64 bit OS, parameter 2
contains the address of the PFN for the corrupted page table page.
On a 32 bit OS, parameter 2 contains a pointer to the number of used
PTEs, and parameter 3 contains the number of used PTEs.
Arg2: fffffa8001098900
Arg3: 000000000000ffff
Arg4: 0000000000000000


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




BUGCHECK_STR: 0x1a_41790


DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT


PROCESS_NAME: taskhost.exe


CURRENT_IRQL: 0


ANALYSIS_VERSION: 6.3.9600.17298 (debuggers(dbg).141024-1500) amd64fre


LAST_CONTROL_TRANSFER: from fffff80002cfa010 to fffff80002c87ec0


STACK_TEXT:
fffff880`13c9c818 fffff800`02cfa010 : 00000000`0000001a 00000000`00041790 fffffa80`01098900 00000000`0000ffff : nt!KeBugCheckEx
fffff880`13c9c820 fffff800`02c753cf : fffffa80`00000000 00000000`276affff 00000000`00000000 00000000`00000000 : nt! ?? ::FNODOBFM::`string'+0x35084
fffff880`13c9c9e0 fffff800`02c87153 : ffffffff`ffffffff 00000000`075ef7d8 00000000`075ef7d0 00000000`00008000 : nt!NtFreeVirtualMemory+0x61f
fffff880`13c9cae0 00000000`7716149a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`075ef798 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x7716149a




STACK_COMMAND: kb


FOLLOWUP_IP:
nt! ?? ::FNODOBFM::`string'+35084
fffff800`02cfa010 cc int 3


SYMBOL_STACK_INDEX: 1


SYMBOL_NAME: nt! ?? ::FNODOBFM::`string'+35084


FOLLOWUP_NAME: MachineOwner


MODULE_NAME: nt


IMAGE_NAME: ntkrnlmp.exe


DEBUG_FLR_IMAGE_TIMESTAMP: 54b5f6ff


IMAGE_VERSION: 6.1.7601.18717


FAILURE_BUCKET_ID: X64_0x1a_41790_nt!_??_::FNODOBFM::_string_+35084


BUCKET_ID: X64_0x1a_41790_nt!_??_::FNODOBFM::_string_+35084


ANALYSIS_SOURCE: KM


FAILURE_ID_HASH_STRING: km:x64_0x1a_41790_nt!_??_::fnodobfm::_string_+35084


FAILURE_ID_HASH: {f6a6ed79-e275-9f8c-d5a4-3a37a32b0b4e}


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

Und hier ein paar Infos aus CPU-Z:


Viele Grüße

 

[simpel1970]

Aus der Auswertung kann man zunächst kein Treiberproblem erkennen.

Arg1: 0000000000041790

Beschreibt einen unbekannten Speichermanagementfehler.

fffff880`13c9c818 fffff800`02cfa010 : 00000000`0000001a 00000000`00041790 fffffa80`01098900 00000000`0000ffff : nt!KeBugCheckEx
fffff880`13c9c820 fffff800`02c753cf : fffffa80`00000000 00000000`276affff 00000000`00000000 00000000`00000000 : nt! ?? ::FNODOBFM::`string'+0x35084
fffff880`13c9c9e0 fffff800`02c87153 : ffffffff`ffffffff 00000000`075ef7d8 00000000`075ef7d0 00000000`00008000 : nt!NtFreeVirtualMemory+0x61f

Die Auslagerungsdatei wird vom System verwaltet, oder hast du die deaktiviert, oder verändert?

Lade bitte mal die Dump Datei hier hoch, ggf. kann man über die PFN Adresse noch etwas herausfinden.

Poste bitte auch noch einen Screenshot von CPU-Z (Reiter SPD).
Was für eine Grafikkarte ist nun drin? Und war die beim erstellen der CPU-Z Screens eingebaut (beim Screenshot Mainbard ist keine angeschlossene Grafikeinheit zu sehen)?

 

[ad0r]

Danke für deine Hilfe.

Hier die Infos zur Auslagerungsdatei:

Dabei fällt mir ein, dass ich vor ca. 2 Monaten die 120gb SSD durch eine 256gb SSD getauscht habe. Dabei habe ich nicht die Auslagerungsdatei vergrößert, könnte dass das Problem sein?

Lade bitte mal die Dump Datei hier hoch, ggf. kann man über die PFN Adresse noch etwas herausfinden.

Die "MEMORY.DMP" ist 665mb groß. Oder was genau soll ich hochladen?

CPU-Z SPD:


CPU-Z Grafik:

Was für eine Grafikkarte ist nun drin? Und war die beim erstellen der CPU-Z Screens eingebaut

Die Screenshots sind von gerade jetzt und es ist seit ca. 4 Monaten eine passive GTX 750 verbaut. Vorher hatte ich die Onboard-Grafik der CPU benutzt.

 

[simpel1970]

Kein Ding.

Dabei fällt mir ein, dass ich vor ca. 2 Monaten die 120gb SSD durch eine 256gb SSD getauscht habe. Dabei habe ich nicht die Auslagerungsdatei vergrößert, könnte dass das Problem sein?

Die Größe der Auslagerungsdatei ist vom Arbeitsspeicher abhängig, nicht von der Systemplatte, sollte daher kein Problem darstellen.
10GB Auslagerungsdatei sollten eigentlich auch ausreichend sein.

Die "MEMORY.DMP" ist 665mb groß. Oder was genau soll ich hochladen?

Wenn "nur" Memory.dmp" angelegt werden (vollständiges Speicherabbild) und keine Minidumps vorhanden sind, dann lade bitte die memory.dmp hoch (diese ist für die Auswertung auch besser, da sie mehr Informationen über den Absturzhergang enthält). Da diese große Datei aber nicht über den foreneigenen Upload hochgeladen werden kann, könntest du die Datei z.B. über Dropbox, GoogleDrive oder OneDrive zur Verfügung stellen.

Bei den vom Board eingestellten Timings würde ich noch in Erwägung ziehen, das XMP Profil zu laden (welches möglicherweise stabiler läuft). Allerdings ist es fraglich, ob es daran liegen kann, wenn das System schon so lange problemlos läuft.
Deshalb würde ich eher noch zur Sicherheit die RAM mit Memtest86+ auf Fehler überprüfen (Prüfung außerhalb von Windows mind. 6 Std. laufen lassen).

 

[ad0r]

Hier der dmp zum downloaden: http://ador-design.de/tmp/memory.ZIP

Memtest lasse ich dann nächsten Montag über Nacht laufen.

 

[simpel1970]

Alles klar.

Ich habe mir die Dump inzwischen mal angeschaut. Wie bereits geschrieben, muss man zunächst von einem Speichermanagementfehler ausgehen. Speicher i.d.S. kann zunächst so gut wie alles sein (RAM, VRAM, CPU-Cache, Motherboard, Systemplatte, etc., etc., etc.).

Nun muss ich etwas ausholen...Ist ein Treiber für das Problem verantwortlich, kann der Treiber regelmäßig im Stackverlauf nachgewiesen werden.

STACK_TEXT: fffff880`13c9c818 fffff800`02cfa010 : 00000000`0000001a 00000000`00041790 fffffa80`01098900 00000000`0000ffff : nt!KeBugCheckEx
fffff880`13c9c820 fffff800`02c753cf : fffffa80`00000000 00000000`276affff 00000000`00000000 00000000`00000000 : nt! ?? ::FNODOBFM::`string'+0x35084
fffff880`13c9c9e0 fffff800`02c87153 : ffffffff`ffffffff 00000000`075ef7d8 00000000`075ef7d0 00000000`00008000 : nt!NtFreeVirtualMemory+0x61f
fffff880`13c9cae0 00000000`7716149a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`075ef798 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x7716149a

Hier ist allerdings kein primäres Treiberproblem ersichtlich. "FreeVirtualMemory" ist ein Prozess, der zwar nicht für den Absturz verantwortlich ist, aber zunächst mal einen Anhaltspunkt bietet, woher das Problem kommen könnte.
Deshalb auch gleich die Frage nach der Auslagerungsdatei. Allerdings greift das virtuelle Speichermanagement insgesamt auf den verfügbaren Speicherplatz zurück (RAM- und Festplatten). Das die Auslagerungsdatei hiermit zusammenhängt ist also auch nur eine mögliche Ursache.

Mal davon abgesehen, dass hier nur eine Dump ausgewertet wird/wurde, bei Speichermanagement Problemen die Hinweise in der nächsten Dump jedoch wieder in eine ganz andere Richtung gehen können, mache ich dennoch weiter...

Der Stack-Verlauf ist eine Momentaufnahme im Zeitpunkt des Absturzes. Es ist daher auch möglich, dass der Grund für den Absturz (wenn es ein Treiber ist), im Stack nicht mehr aufzuspüren ist.
Der Stack kann "erweitert" werden, um mögliche Spuren, die doch hinterlassen wurden, finden zu können. Allerdings sind diese Spuren oftmals etwas "verwischt" und können auch auf eine falsche Spur führen.
Wenn man dies alles bedenkt und sich dennoch den erweiterten Stack anschaut:

fffff880`13c9a630 fffff880`01b6c0f0*** ERROR: Module load completed but symbols could not be loaded for tdrpman.sys
tdrpman+0xaf0f0
fffff880`13c9a668 fffff880`01b6c0f0 tdrpman+0xaf0f0
fffff880`13c9a698 fffff880`01b78508 tdrpman+0xbb508
fffff880`13c9a6d8 fffff880`01b782b2 tdrpman+0xbb2b2
fffff880`13c9a708 fffff880`01b6cd90 tdrpman+0xafd90
fffff880`13c9a720 fffff880`01ac2920 tdrpman+0x5920
fffff880`13c9a738 fffff880`01b70416 tdrpman+0xb3416
fffff880`13c9a748 fffff880`01b6ce84 tdrpman+0xafe84
fffff880`13c9a778 fffff880`01b6c174 tdrpman+0xaf174
fffff880`13c9a788 fffff880`01b6c0f0 tdrpman+0xaf0f0
fffff880`13c9a7b8 fffff880`01982817*** ERROR: Module load completed but symbols could not be loaded for fltsrv.sys
fltsrv+0x5817
fffff880`13c9a7d8 fffff800`02dbdfcd nt!ExFreePoolWithTag+0x22d
fffff880`13c9a848 fffff880`01a2cdf2*** ERROR: Module load completed but symbols could not be loaded for snapman.sys
snapman+0x24df2
fffff880`13c9a858 fffff880`01a31a90 snapman+0x29a90
fffff880`13c9a888 fffff880`01a2b421 snapman+0x23421
fffff880`13c9a898 fffff880`019a2558 fvevol!FveFilterRundownRead
fffff880`13c9a8a8 fffff880`01a4d0e0 snapman+0x450e0
fffff880`13c9a8b8 fffff880`01a35f52 snapman+0x2df52
fffff880`13c9a8e8 fffff880`01a2a7d7 snapman+0x227d7
fffff880`13c9a8f8 fffff880`01a2d048 snapman+0x25048
fffff880`13c9a910 fffff880`01a31a90 snapman+0x29a90
fffff880`13c9a938 fffff880`01a2cdf2 snapman+0x24df2
fffff880`13c9a948 fffff800`02c8aa63 nt!SwapContext_PatchXSave+0xa3
fffff880`13c9a968 fffff880`01a2a780 snapman+0x22780
fffff880`13c9a988 fffff800`02c8a69a nt!KiSwapContext+0x7a
fffff880`13c9a998 fffff880`01a33b42 snapman+0x2bb42
fffff880`13c9a9a8 fffff880`01a2a874 snapman+0x22874
fffff880`13c9aa88 fffff880`01933df4 volsnap! ?? ::FNODOBFM::`string'+0x57b
fffff880`13c9ab08 fffff880`01230c25 Ntfs!NtfsPrepareSimpleBuffers+0x6c6
fffff880`13c9ab48 fffff880`01225a41 Ntfs!NtfsVerifyAndRevertUsaBlock+0x81
fffff880`13c9abd8 fffff800`02f94230 nt!SeAuditingAnyFileEventsWithContext+0x50
fffff880`13c9ac08 fffff800`02f81804 nt!SeUnlockSubjectContext+0x44
fffff880`13c9ac38 fffff880`012c9116 Ntfs!NtfsAccessCheck+0xf85
fffff880`13c9ac58 fffff880`012c9101 Ntfs!NtfsAccessCheck+0xf70
fffff880`13c9ac88 fffff800`02c9991c nt!IopFreeIrp+0x11c
fffff880`13c9acc8 fffff800`02f94230 nt!SeAuditingAnyFileEventsWithContext+0x50
fffff880`13c9ad98 fffff880`012c7671 Ntfs!NtfsOpenAttribute+0x491
fffff880`13c9ae18 fffff880`012b5f0c Ntfs!NtfsCheckExistingFile+0x1dc
fffff880`13c9aea8 fffff880`012b6115 Ntfs!NtfsOpenExistingAttr+0x145
fffff880`13c9aee0 fffff880`01264a00 Ntfs!NtfsFileNameIndex
fffff880`13c9af40 fffff880`01264a00 Ntfs!NtfsFileNameIndex
fffff880`13c9af68 fffff880`012b1ebf Ntfs!NtfsOpenAttributeInExistingFile+0x50f
fffff880`13c9af90 fffff880`01264a00 Ntfs!NtfsFileNameIndex
fffff880`13c9afb8 fffff880`012b6115 Ntfs!NtfsOpenExistingAttr+0x145
fffff880`13c9aff0 fffff880`01264a00 Ntfs!NtfsFileNameIndex
fffff880`13c9b058 fffff880`0122d23a Ntfs!NtfsAcquireFcbWithPaging+0x13a
fffff880`13c9b078 fffff880`012b1ebf Ntfs!NtfsOpenAttributeInExistingFile+0x50f
fffff880`13c9b0b8 fffff880`012c6976 Ntfs!NtfsFindPrefixHashEntry+0x4ad
fffff880`13c9b0d0 fffff880`01264a00 Ntfs!NtfsFileNameIndex
fffff880`13c9b0f8 fffff880`012b5730 Ntfs!NtfsOpenExistingPrefixFcb+0x74b
fffff880`13c9b1e8 fffff880`012c5306 Ntfs!NtfsFindStartingNode+0x5e6
fffff880`13c9b228 fffff800`02c9ab3e nt!SepNormalAccessCheck+0x18e
fffff880`13c9b278 fffff880`012c1468 Ntfs!NtfsCommonCleanup+0x5937
fffff880`13c9b2b8 fffff800`02c99f04 nt!SepAccessCheck+0x274
fffff880`13c9b308 fffff880`012cdc00 Ntfs!NtfsFileIsEqual

So sieht das für mich doch nach einem recht interessanten Fehlerbild aus. Hier fallen insbes. drei Treiber auf:
-Ntfs.sys (windowseigener Dateisystemtreiber) -> weist auf eine Problem mit dem Dateisystem hin.
-Snapman.sys (Acronis Treiber; laut Treibersignatur von Feb 2012)
-tdrpman.sys (Acronis Treiber; laut Treibersignatur von April 2012)
beide Acronis Treiber also nicht mehr so ganz frisch.

2: kd> lmvm snapman
start end module name
fffff880`01a08000 fffff880`01a58000 snapman (no symbols)
Loaded symbol image file: snapman.sys
Image path: \SystemRoot\system32\DRIVERS\snapman.sys
Image name: snapman.sys
Timestamp: Tue Feb 21 09:10:08 2012 (4F435160)
CheckSum: 00055A00
ImageSize: 00050000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
2: kd> lmvm tdrpman
start end module name
fffff880`01abd000 fffff880`01bfb000 tdrpman (no symbols)
Loaded symbol image file: tdrpman.sys
Image path: \SystemRoot\system32\DRIVERS\tdrpman.sys
Image name: tdrpman.sys
Timestamp: Mon Apr 23 11:16:44 2012 (4F951DFC)
CheckSum: 00142D52
ImageSize: 0013E000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4

Was nun machen?
Hilfreich und harmlos wäre zunächst das Dateisystem auf mögliche Fehler zu überprüfen. Dazu die Eingabeaufforderung als Admin starten und folgenden Befehl eingeben:
chkdsk /f /r
Die Überprüfung ruhig auch für die anderen Platten wiederholen. Dazu den Befehl entsprechend abändern: chkdsk X: /f /r. Das X steht dabei für den jeweiligen Laufwerksbuchstaben.

Danach würde ich erst einmal abwarten, ob nochmal ein Absturz auftritt. Wenn ja, lade bitte wieder die Dump hoch. Sollte auch hier Acronis in der Auswertung auffällig werden, würde das gegen das Image-Tool sprechen. Schau ma mal.

 

[ad0r]

So, chkdsk habe ich durchlaufen lassen.
Memtest habe ich 17 Stunden laufen lassen, keine Probleme.

-Snapman.sys (Acronis Treiber; laut Treibersignatur von Feb 2012)
-tdrpman.sys (Acronis Treiber; laut Treibersignatur von April 2012)

Ich nutze Acronis 2012 für Backups, dass ist leider schon relativ alt.
Da ich von den neuen Versionen eher schlechtes gehört habe, habe ich mir nie die neueren Versionen gekauft.

Bei den vom Board eingestellten Timings würde ich noch in Erwägung ziehen, das XMP Profil zu laden (welches möglicherweise stabiler läuft).

Das RAM läuft schon entschärft und nicht auf maximum. Wenn ich das XMP-Profil lade, würde nur der Takt höher werden. Da ich das RAM nicht mehr für die interne APU brauche (Shared Memory), ist das ok so.

Vielleicht warte ich nu auch ein bisschen ab und schaue mal ob noch was passiert.

 

[simpel1970]

Was hat die CheckDisk Prüfung ergeben?
Nachträglich kannst du das Ergebnis über die Ereignisanzeige anzeigen lassen: Nach dem Absturz - Das chkdsk-Protokoll nachträglich auslesen - Tipp für Windows 7 | TecChannel.de