Der PC startet plötzlich neu, friert ein oder geht ohne sichtbaren Bluescreen aus. In der Ereignisanzeige steht danach Kernel-Power, Ereignis-ID 41, Aufgabenkategorie 63. Dieser Eintrag wirkt wie eine eindeutige Fehlerdiagnose – ist aber zunächst nur der Nachweis, dass Windows zuvor nicht ordnungsgemäß heruntergefahren wurde.

Diese Anleitung zeigt dir, welche Details in Ereignis 41 tatsächlich weiterhelfen, wie du einen versteckten Bluescreen von Strom- oder Hardwareproblemen unterscheidest und welche Daten du vor Änderungen sichern solltest. Sie gilt für Windows 11 und weitgehend auch für unterstützte Windows-Clientversionen. Recherche- und Prüfstand: 6. Oktober 2026.

Kurzlösung

Öffne in der Ereignisanzeige unter Windows-Protokolle → System das Ereignis 41 und prüfe in der Detailansicht zuerst BugcheckCode und PowerButtonTimestamp. Ein BugcheckCode ungleich 0 spricht für einen Windows-Absturz. Stehen beide Werte auf 0, konnte Windows die Ursache vor dem Ausfall meist nicht mehr protokollieren. Dann untersuchst du Stromversorgung, Temperatur, Firmware, Treiber und Arbeitsspeicher anhand des Fehlerzeitpunkts – statt Ereignis 41 selbst „reparieren“ zu wollen.

Was bedeutet Kernel-Power 41?

Windows schreibt Ereignis 41 beim nächsten Systemstart, wenn der vorherige Lauf nicht sauber beendet wurde. Das kann nach einem Bluescreen, einem vollständigen Stromverlust, einem Reset, einem langen Druck auf den Einschaltknopf oder einem harten Einfrieren passieren. Microsoft formuliert deshalb bewusst, dass das System neu gestartet wurde, ohne zuvor ordnungsgemäß herunterzufahren.

Wichtig: Kernel-Power 41 ist häufig die Folge, nicht die Ursache. Das Ereignis beweist weder automatisch ein defektes Netzteil noch einen bestimmten Treiberfehler. Microsoft beschreibt mehrere Szenarien und wertet dafür zusätzliche Felder innerhalb des Ereignisses aus. Die technische Grundlage findest du in Microsofts Dokumentation zu Ereignis-ID 41.

Ereignis 41 vollständig öffnen

  1. Drücke Windows + R, gib eventvwr.msc ein und bestätige.
  2. Öffne Windows-Protokolle → System.
  3. Wähle rechts Aktuelles Protokoll filtern und trage bei Ereignis-IDs 41,6008,1074,1001 ein.
  4. Öffne das Ereignis 41, wechsle zu Details und wähle die XML-Ansicht.
  5. Notiere Zeitpunkt, BugcheckCode, PowerButtonTimestamp, SleepInProgress und WHEABootErrorCount.

Die ergänzenden IDs helfen bei der Einordnung: Ereignis 6008 meldet ebenfalls ein unerwartetes Herunterfahren. Ereignis 1074 dokumentiert dagegen einen regulär ausgelösten Neustart oder Shutdown durch einen Prozess beziehungsweise Benutzer. Ein passendes Ereignis 1001 kann Informationen zu einem Bugcheck enthalten. Microsoft zeigt diese zeitliche Auswertung auch in der Anleitung zu unerwarteten Neustarts anhand des Systemprotokolls.

Die drei wichtigsten Szenarien

1. BugcheckCode ist größer als 0

Dann hat Windows einen Stopfehler erkannt. Der Wert im Ereignis wird dezimal gespeichert, während Bluescreen-Codes meist hexadezimal angegeben werden. Mit PowerShell wandelst du beispielsweise den Dezimalwert 239 um:

'0x{0:X8}' -f 239

Das Ergebnis 0x000000EF lässt sich anschließend gezielt recherchieren. Der konkrete Code grenzt die Suche stärker ein als Ereignis 41. Prüfe außerdem, ob unter C:\Windows\Minidump eine zeitlich passende DMP-Datei liegt. Sie kann den abstürzenden Treiber oder den betroffenen Kernelpfad sichtbar machen, liefert aber nicht in jedem Fall bereits eine eindeutige Ursache.

2. PowerButtonTimestamp ist größer als 0

Das spricht laut Microsoft dafür, dass der Einschaltknopf lange genug gedrückt wurde, um das Gerät hart auszuschalten. Kläre, ob der Rechner zuvor eingefroren war. Der Tastendruck erklärt dann den unmittelbaren Shutdown, aber noch nicht zwingend den ursprünglichen Hänger.

3. BugcheckCode und PowerButtonTimestamp sind 0

Windows konnte vor dem Neustart weder einen Stopcode noch einen langen Druck auf den Einschaltknopf erfassen. Möglich sind ein abrupter Stromverlust, ein Reset außerhalb von Windows, ein vollständiger Hardware-Hänger oder ein Absturz, bei dem kein Speicherauszug geschrieben werden konnte. Die Nullen sind daher keine Netzteil-Diagnose, sondern bedeuten zunächst: Im Ereignis fehlen verwertbare Absturzdaten.

Systemereignisse mit PowerShell sichern

Öffne PowerShell als Administrator. Der folgende Befehl zeigt die letzten relevanten Systemereignisse mit Zeitstempel, ID und Meldung:

Get-WinEvent -FilterHashtable @{
    LogName = 'System'
    Id      = 41, 6008, 1074, 1001
} -MaxEvents 50 |
Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message |
Format-List

Für eine Weitergabe an die IT kannst du die Auswahl als CSV exportieren. Der Zielordner muss existieren:

Get-WinEvent -FilterHashtable @{
    LogName = 'System'
    Id      = 41, 6008, 1074, 1001
} -MaxEvents 100 |
Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message |
Export-Csv -Path 'C:\Temp\Neustart-Ereignisse.csv' -NoTypeInformation -Encoding UTF8

Protokolle können Rechnernamen, Benutzernamen oder andere Umgebungsdaten enthalten. Prüfe die Datei, bevor du sie öffentlich hochlädst.

Wenn kein Bluescreen sichtbar war

Windows kann nach einem Stopfehler so schnell neu starten, dass der Bluescreen kaum auffällt. Öffne Systemeigenschaften → Erweitert → Starten und Wiederherstellen → Einstellungen. Unter „Debuginformationen speichern“ sollte für normale Diagnosezwecke ein Speicherauszug aktiviert sein. Die Auslagerungsdatei auf dem Systemlaufwerk darf nicht deaktiviert sein, weil sie für die Dump-Erstellung benötigt werden kann.

Für einen reproduzierbaren Fehler kannst du vorübergehend Automatisch Neustart durchführen deaktivieren. Dann bleibt ein künftiger Stopcode sichtbar. Das verhindert keinen Absturz; es erleichtert nur dessen Erfassung. Auf unbeaufsichtigten oder produktiven Systemen kann ein deaktivierter Neustart die Ausfallzeit verlängern. Microsoft erläutert Dump-Typen und Voraussetzungen unter Systemfehler- und Wiederherstellungsoptionen konfigurieren.

Nicht vorschnell ändern: Deaktiviere keine Schutzfunktionen, lösche keine Ereignisprotokolle und setze BIOS oder Registry nicht pauschal zurück. Ein vorhandener Dump und die ursprünglichen Zeitstempel sind wertvoller als ein „aufgeräumtes“ System ohne Beweise.

Ursache systematisch eingrenzen

  • Nur unter Last: Notiere Anwendung, Leistungsaufnahme, Temperaturen und ob CPU oder GPU übertaktet beziehungsweise undervoltet sind. Teste mit Herstellervorgaben.
  • Nach Standby: Prüfe, ob SleepInProgress gesetzt ist, und aktualisiere BIOS/UEFI sowie Chipsatz-, Grafik- und Gerätetreiber ausschließlich aus vertrauenswürdiger Quelle.
  • Mit Bugcheck: Arbeite mit Stopcode, Dump und Ereignis 1001 weiter. Microsofts Einstieg für unerwartete Neustarts und Stopcodes findest du unter Windows-Abstürze untersuchen.
  • Kompletter Stromverlust: Prüfe Steckdose, Mehrfachleiste, Netzkabel und bei Desktop-PCs die Stromanschlüsse. Arbeiten im geöffneten Netzteil sind lebensgefährlich und gehören in Fachhände.
  • WHEA-Ereignisse in zeitlicher Nähe: Sichere deren IDs und Details. Sie können auf gemeldete Hardwarefehler hinweisen, müssen aber zusammen mit Firmware, Treibern und Hardwarediagnose bewertet werden.
  • Verwalteter Firmen-PC: Gib Zeitpunkt, Benutzeraktion, Ereignis-XML und Dump-Pfad an die IT. Ändere keine Unternehmensrichtlinien oder Sicherheitssoftware eigenmächtig.

Ändere möglichst nur eine Variable pro Test. Tritt der Neustart anschließend nicht mehr auf, ist das noch kein Beweis; sporadische Fehler benötigen mehrere vergleichbare Last- oder Standby-Zyklen.

Woran du eine brauchbare Diagnose erkennst

Am Ende solltest du nicht nur „Kernel-Power 41“ notiert haben, sondern einen konkreteren Pfad: etwa Stopcode plus Dump, einen reproduzierbaren Ausfall unter Last, einen langen Druck auf den Einschaltknopf nach einem Freeze oder einen nachweisbaren Stromabbruch. Erst diese Einordnung bestimmt, ob du bei Treibern, Windows, Firmware, Kühlung, Arbeitsspeicher oder Stromversorgung weitersuchst.

Fazit

Ereignis-ID 41 sagt zuverlässig, dass Windows zuvor nicht sauber beendet wurde – nicht automatisch, warum. Prüfe deshalb die Zusatzfelder, benachbarte Ereignisse und vorhandene Speicherauszüge. Mit dieser Reihenfolge wird aus einem unspezifischen Protokolleintrag eine belastbare Fehlersuche, ohne vorschnell Hardware zu tauschen oder Windows zurückzusetzen.