Die Zeit der frei konfigurierbaren, proprietären Betriebssysteme, auf austauschbarer Hardware, ist doch jetzt schon fast vorbei. Eingeschweißt in "Premium-Plastik" gibt es dann nur noch hartcodierte Starthilfeknöpfe die dich ins Netz katapultieren und SaS.

Mir als Windows 10 Benutzer erscheint es als eine Zumutung und ein Glücksspiel, irgendwelche stabilen, kompatiblen Treiber selber heraus zu fischen und dann per "Never touch a running system" möglichst zu konservieren. Habe ich hier Windows 95 oder wie...? Ein Betriebssystem ist nicht mehr mein Hobby. (Arch-Linux als Ausnahme vielleicht noch...)

Das ist bei Windows leider so. Und es muss ja auch kein Treiber sein. Kann alles Mögliche sein. Probleme mit Treibern lasse sich eigentlich relativ schnell einkreisen. Alles andere kann kompliziert werden.

Mag ja alles richtig sein aber das fremde Prozesse/Treiber das System vollständig (weil Kritisch) herunter reißen ist mMn. ein Designfehler. Ein wiederholt fehlerhafter Prozess könnte vielleicht auch abgefangen/isoliert werden ohne das Windows sich gleich ins Schneckenhaus zurück zieht. Treiber verfügen doch zwangsweise über eine Prüfung durch Microsoft.

Das Problem ist ja, das die [i]Wininit.exe [/i]eigentlich meist nichts dafür kann, dass sie sich beendet. Daher kann Microsoft da auch relativ wenig machen. Die bräuchten dann schon Dein System, damit sie da selber nachforschen können. Ich hatte da schon lange keine Probleme mehr mit der Wininit.exe. Das letzte mal war das auf dem Tablet und da war dieses blöde Service-Tool von Samsung schuld, welches mit dem damals aktuellen Windows inkompatibel war. Samsung hat da irgendwo zw. der RS2 und RS3 den Support eingestellt. War aber mehr Zufall, dass ich das herausgefunden hatte. Habe dann einfach eine Neuinstallation durchgeführt und mir vorher alles an damalig aktuellen Treibern selber zusammen gestellt und alles von Samsung weggelassen einschließlich den veralteten Treibern. Seitdem läuft das Tablet ohne Probleme.

Wie gesagt, die Fehler 0xEF und 0xF4 in Zusammenhang mit csrss.exe, wininit.exe, logonui.exe, smss.exe, services.exe, conhost.exe und winlogon.exe sind schwierig, in den Griff zu bekommen. Auch das Auswerten der Dump-Dateien ist recht komplex und zeitaufwendig.

Fazit:
Ich bin mir nun sicherer das es ein Softwarefehler ist und nicht meine Hardware. Das wusste ich vorher nämlich nicht.

@DK2000
Wie sollte ich einen "wininit.exe Fehler" reparieren, wenn MS das nicht macht? Aus welcher Ecke auch immer die exe geschossen wird, es ist zu komplex für mich. Ich hatte einen alten HP-Netzwerkdrucker-Treiber im Verdacht und die Treiber-Isolation per GPO deaktiviert. Aber das war es nicht.
Das Protokoll des system died Crashs in der Dump Datei hatte ich ja offen. Ich hatte nur ein Minidump eingestellt. Nun wird es ein vollständiges Abbild. Also dann mal schauen, der nächste Crash kommt bestimmt.

@Irgendwer:

Ja, das Tool ist mir bekannt. Wundert mich aber halt, dass die Winint.exe abstürzt, wenn Du eine Dump Datei öffnest.

Aber du verwendest das Tool aus dem passenden SDK bzw. WDK für das installierte Windows und nicht die Preview aus den Store. Letztere habe ich da auch wieder entfernt, weil die nicht unbedingt so lief, wie erwartet. Das dauert wohl noch ein wenig, bis man die verwenden kann.

@Gast:

Was nützt einem ein provozierter BSOD? Man benötigt hierfür genau die Dumpdatei, welche aufgrund des Problems erstellt wurde und keine, die man selber erstellt hat.

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...

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/windows-hardware/drivers/debugger/debugger-download-tools

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

Die Selbstheilung checkte 100 Möglichkeiten und reparierte den OneDrive Link
[code]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[/code]
Das ist einfach nur lächerlich oder eben nicht kaputt gewesen...

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

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

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 [i]sfc /scannow[/i] angeblich irgendetwas repariert, aber lt. Log eigentlich nichts repariert wurde.

https://www.deskmodder.de/phpBB3/viewtopic.php?f=334&t=24661

Das war alles sehr seltsam.

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

Ich habe zuerst mal die Windows Selbstheilung angestoßen:

[code]DISM.exe /Online /Cleanup-image /Restorehealth
sfc /scannow[/code]
Es wurde auch etwas gefunden und erfolgreich repariert aber ich sehe in der CBS.log keine Details.
Nun debuggen...

Die [i]wininit.exe[/i] 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.