Kritischer Systemabsturz

[Irgendwer]

Jetzt geht das wieder los:
Protokoll: 29.12.2020 10:18:32, Kernel Power Prozess Died, mit Bluescreen
Unverändertes System..., man, man man...

Code: Alles auswählen

 EventData 

  BugcheckCode 239 
  BugcheckParameter1 0xffffb60ab1a9d080 
  BugcheckParameter2 0x0 
  BugcheckParameter3 0x0 
  BugcheckParameter4 0x0 
  SleepInProgress 0 
  PowerButtonTimestamp 0 
  BootAppStatus 0 
  Checkpoint 0 
  ConnectedStandbyInProgress false 
  SystemSleepTransitionsToOn 0 
  CsEntryScenarioInstanceId 0 
  BugcheckInfoFromEFI false 
  CheckpointStatus 0 
  CsEntryScenarioInstanceIdV2 0 
  LongPowerButtonPressDetected false 

[Tante Google]

[Irgendwer]

Code: Alles auswählen

Protokollname: System
Quelle:        Microsoft-Windows-WER-SystemErrorReporting
Datum:         29.12.2020 10:18:40
Ereignis-ID:   1001
Aufgabenkategorie:Keine
Ebene:         Fehler
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Computer:      ********
Beschreibung:
Der Computer wurde nach einem schwerwiegenden Fehler neu gestartet. Der Fehlercode war: 0x000000ef (0xffffb60ab1a9d080, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000). Ein volles Abbild wurde gespeichert in: C:\Windows\MEMORY.DMP. Berichts-ID: 5f7dceb8-41af-4e13-a53a-45a8530eb5e8.
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-WER-SystemErrorReporting" Guid="{ABCE23E7-DE45-4366-8631-84FA6C525952}" EventSourceName="BugCheck" />
    <EventID Qualifiers="16384">1001</EventID>
    <Version>0</Version>
    <Level>2</Level>
    <Task>0</Task>
    <Opcode>0</Opcode>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2020-12-29T09:18:40.3701074Z" />
    <EventRecordID>4323</EventRecordID>
    <Correlation />
    <Execution ProcessID="0" ThreadID="0" />
    <Channel>System</Channel>
    <Computer>********</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="param1">0x000000ef (0xffffb60ab1a9d080, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000)</Data>
    <Data Name="param2">C:\Windows\MEMORY.DMP</Data>
    <Data Name="param3">5f7dceb8-41af-4e13-a53a-45a8530eb5e8</Data>
  </EventData>
</Event>]

[John-Boy]

Ich habe nun keine Lust deine alten Beiträge zu suchen und durchzulesen aber generell sollte zu einer solchen Fehlermeldung mehr gehören.

Ich tippe nun mal so ins blaue: Netzteil oder RAM

[DK2000]

Das da oben sagt im Grunde genommen nicht aus. Man bräuchte die DateiC:\Windows\MEMORY.DMP um in Erfahrung zu bringen, welcher Prozess-Objekt sich bei Adresse 0xffffb60ab1a9d080 befindet. Wenn man Glück hat, ist in der Dump auch der Grund gespeichert, also der eigentliche Fehler, warum der Prozess gestorben ist. Dann könnte man eventuell Rückschlüsse ziehen, was da passiert ist.

[Gast]

@John-Boy
...und was willst du mir damit sagen?

@DK2000
Laut Memory.dmp ist der kritische Prozess: wininit.exe
(Die Debugging-Ausgabe lässt sich leider nicht kopieren.)

[DK2000]

Wenn das wirklich die wininit.exe ist, dann reicht eine Memory.dmp (Kernel Dump) nicht aus. Hier bräuchte man mindestens ein vollständiges Abbild mit User- und Kernel Mode Daten, am Besten mehrere davon. Das ist kompliziert.

Kannst höchstens hier noch einmal nachschauen:

https://docs.microsoft.com/en-us/window ... ocess-died

Aber der Fehler ist schwierig.

[Irgendwer]

@DK2000
Danke dir. Ich nehme mir mal die anderen beiden Dumps vor. Jedenfalls ist es die originale winini.exe und kein Virus. Diese winini.exe zickt ja offenbar häufiger mal herum.

[DK2000]

Die wininit.exe ist halt ein spezieller Fall. Die Grund für den 0xEF kann schon auf Benutzerebene liegen, kann aber auch ein Problemen mit der Hardware oder Treiber sein. Irgendetwas scheint da die wininit.exe abzuschießen und das "irgendetwas" muss man erst einmal finden und das ist schwierig, zumal das Problem auch in einem ganz anderen Kontext sein kann.

[Irgendwer]

Ich habe zuerst mal die Windows Selbstheilung angestoßen:

Code: Alles auswählen

DISM.exe /Online /Cleanup-image /Restorehealth
sfc /scannow

Es wurde auch etwas gefunden und erfolgreich repariert aber ich sehe in der CBS.log keine Details.
Nun debuggen...

[DK2000]

Wenn da etwas repariert wurde, sollte da auch etwas in der CBS.log stehen bzw. in den archivierten Logs (CbsPersist*). Obwohl hatten ja da letztens das seltsame Problem mit der 2004/20H2, dass sfc /scannow angeblich irgendetwas repariert, aber lt. Log eigentlich nichts repariert wurde.

viewtopic.php?f=334&t=24661

Das war alles sehr seltsam.

[Irgendwer]

Keine Chance zur Zeit. Sobald der Debugger loslegt crasht die winini.exe bis zum Bluescreen: "Mausetot"

[DK2000]

Wie debuggst Du? Bei der Auswertung der Dump Dateien sollte das eigentlich nicht passieren.

[Irgendwer]

Die Selbstheilung checkte 100 Möglichkeiten und reparierte den OneDrive Link

Code: Alles auswählen

2020-12-29 13:35:03, Info                  CSI    000001fe [SR] Repairing file \??\C:\Users\Default\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\\OneDrive.lnk from store
2020-12-29 13:35:03, Info                  CSI    000001ff CSIPERF - FilePI Queue 155ms
2020-12-29 13:35:03, Info                  CSI    00000200 [SR] Repair complete
2020-12-29 13:35:03, Info                  CSI    00000201 [SR] Committing transaction
2020-12-29 13:35:03, Info                  CSI    00000202 Creating NT transaction (seq 1)
2020-12-29 13:35:03, Info                  CSI    00000203 Created NT transaction (seq 1) result 0x00000000, handle @0x169dc
2020-12-29 13:35:03, Info                  CSI    00000204@2020/12/29:12:35:03.967 Beginning NT transaction commit...
2020-12-29 13:35:03, Info                  CSI    00000205@2020/12/29:12:35:03.982 CSI perf trace:
CSIPERF:TXCOMMIT;3231
2020-12-29 13:35:03, Info                  CSI    00000206 [SR] Verify and Repair Transaction completed. All files and registry keys listed in this transaction  have been successfully repaired

Das ist einfach nur lächerlich oder eben nicht kaputt gewesen...

[Irgendwer]

Mit dem Debugging Tools (WinDbg) für Windows 10 kannst du die Memory.dmp öffnen und innerhalb des Programmes kannst du dann Fehler "debuggen".
https://docs.microsoft.com/en-us/window ... load-tools

[Gast]

Zitat:
Wenn das wirklich die wininit.exe ist, dann reicht eine Memory.dmp (Kernel Dump) nicht aus. Hier bräuchte man mindestens ein vollständiges Abbild mit User- und Kernel Mode Daten, am Besten mehrere davon. Das ist kompliziert.
-
Man kann mit dem Programm "NoMyFault" so einen Crash (Bluescreen) provozieren und dann hast du, falls in Windows ein vollständiges Abbild eingestellt wurde, die *dmp analysieren.
P.S.
Die Frage die sich mir langsam stellt: Was soll das überhaupt bringen? Ich habe den Kram nicht programmiert und Fehlersuche dauert bei MS Stunden...