remote Verbindung, EventLog in Win 11 26H2 beheben

Question

remote Verbindung, EventLog in Win 11 26H2 beheben

walter dudnik 0

Technischer Fehlerbericht für Microsoft Support

Windows 11 Pro | EventLog / wevtsvc.dll | Stand: 02.11.2026

Zusammenfassung / Fehlerbild

Windows-Ereignisprotokolldienst (EventLog) startet nicht vollständig und verbleibt dauerhaft im Status START_PENDING. Der Dienst wird als automatischer Windows-Dienst unter LocalService betrieben. Der Fehler besteht seit mindestens September 2026 und blieb auch nach einem Windows-Versionswechsel bestehen.

Parallel dazu fehlt der RDP-TCP-Listener auf Port 3389, obwohl TermService und Thinstuff-Komponenten laufen. Ein ursächlicher Zusammenhang ist nicht nachgewiesen; die Analyse soll sich primär auf EventLog konzentrieren.

Betroffenes System

Windows 11 Pro, aktuell 26H2, Build 26300 (zuvor 25H2, Build 26200). Hardware: Intel Core i9, 64 GB RAM. Mehrbenutzerbetrieb mit Thinstuff XP/VS Server 1.0.980.1.

Der Rechner ist produktiv im Einsatz. Riskante Eingriffe, Neustarts und das Umbenennen/Löschen von Ereignisprotokolldateien sind ohne Sicherung und Wartungsfenster zu vermeiden.

Reproduzierbare technische Befunde

„sc.exe queryex EventLog“: STATE = START_PENDING, CHECKPOINT = 0, WAIT_HINT = 0; zuletzt beobachtete dedizierte svchost.exe-PID 3212 (PID kann wechseln).

„sc.exe qc EventLog“: START_TYPE = AUTO_START; Dienstkonto LocalService; svchost-Gruppe LocalServiceNetworkRestricted -p. ServiceDll = %SystemRoot%\System32\wevtsvc.dll.

Berechtigungen am Verzeichnis der Windows-Ereignisprotokolle geprüft; NT SERVICE\EventLog, SYSTEM und Administratoren mit Vollzugriff. Rund 1.294 Ereigniskanäle registriert.

Im Windows Error Reporting-Archiv befinden sich zahlreiche AppHang_EventLog-Berichte. Ein untersuchter Report.wer enthält EventType=ServiceHang, Verweis auf wevtsvc.dll, DLL-Version 10.0.26100.9818 und OS-Build 26300. Der Bericht weist keine eindeutige ursprüngliche Fehlerursache aus.

WinDbg-Befund

Ein Prozessabbild des bereits hängenden EventLog-Dienstes wurde mit WinDbg untersucht. Der beobachtete Aufrufpfad liegt in der Beendigungs-/Aufräumphase: wevtsvc!LegacyEventLogShutDown → OsEventsCleanup → OsEventsThreadStop → WaitForSingleObjectEx.

Dieser Stack deutet auf einen Wartezustand während der Bereinigung hin. Er beweist nicht, welcher ursprüngliche Fehler den Dienststart ausgelöst hat. Gesucht wird ausdrücklich der erste Fehler vor Eintritt in diese Cleanup-Sequenz.

Bereits durchgeführte Maßnahmen (ohne nachhaltigen Erfolg)

DISM und SFC mehrfach ohne festgestellte Integritätsverletzungen; Windows-Reparaturinstallationen und Versionswechsel 25H2 → 26H2 ohne Behebung.

Dienstkonfiguration, ServiceDll und Dateisystemberechtigungen geprüft. ProcMon-Boot-Aufzeichnung mit etwa 4,9 Millionen Ereignissen bereits durchgeführt, ohne eindeutige Ursachenzuordnung.

Thinstuff mehrfach deinstalliert und Konfiguration/Registrierung bereinigt; EventLog-Problem blieb bestehen. Ein erneutes Wiederholen dieser Schritte erscheint nicht zielführend.

Microsoft TSS heruntergeladen und Dokumentation nach geeigneter EventLog-/ServiceHang-Startdiagnose durchsucht. Bisher kein passendes gezieltes TSS-Szenario identifiziert; keine neue TSS-Aufzeichnung gestartet.

Wichtige Betriebserfahrung: Eine frühere Umbenennung von EVTX-Dateien führte dazu, dass Windows nicht mehr startete. Bitte keine derartigen Schritte als Routineempfehlung.

Auswirkungen auf Remotedesktop / Thinstuff

TermService läuft, ebenso ThinRDPSrv und Kernel-Treiber thinrdp; der RDP-TCP-Listener und Port 3389 sind jedoch nicht vorhanden. In qwinsta fehlt rdp-tcp.

Die Thinstuff-Supportdiagnose (.tsrp) lieferte unvollständige Protokolle/Verzeichnisse. Ob die EventLog-Störung hierzu beiträgt, ist ungeklärt. Ziel ist zunächst die Wiederherstellung des EventLog-Dienstes und danach die erneute RDP-Diagnose.

Konkrete Bitte an Microsoft

Bitte den Startfehler des Windows-Dienstes EventLog / wevtsvc.dll eskalieren und eine geeignete, möglichst risikoarme Methode zur Erfassung der ersten Exception bzw. des ersten fehlschlagenden Initialisierungsschritts empfehlen.

Bitte insbesondere klären: (a) welche ETW-Provider, WPR-Profile oder Debugger-Einstellungen die EventLog-Initialisierung vor der Cleanup-Phase erfassen; (b) welche Dumps, WER-Reports und Konfigurationsdaten für die Ursachenanalyse benötigt werden; (c) ob ein bekannter Fehler unter Windows 11 26H2 / Build 26300 oder in wevtsvc.dll 10.0.26100.9818 vorliegt.

Bitte keine Standardempfehlungen zu DISM/SFC, generischer ProcMon-Aufzeichnung oder pauschaler Neuinstallation, bevor die vorliegenden Befunde ausgewertet wurden.

Für Microsoft nachzureichende Belege

Vollständige Ausgabe von sc.exe queryex EventLog und sc.exe qc EventLog; exakter aktueller Windows-Build aus winver; Original-Report.wer aus dem betreffenden AppHang_EventLog-Ordner; vorhandene WinDbg-Dumps und Stack-Ausgaben; gegebenenfalls relevante ProcMon-Auszüge.

Diese Artefakte sind in diesem Bericht beschrieben, aber nicht beigefügt. Vor dem Versand bitte Dateipfade, Benutzernamen, IP-Adressen und sonstige vertrauliche Daten prüfen.

0 Kommentare

1 Antwort

Ihre Antwort

Answer 1

Willkommen bei Microsoft Q&A!

Vielen Dank für die ausführlichen Diagnoseinformationen.

Auf Grundlage Ihrer Ergebnisse würde ich derzeit nicht empfehlen, EVTX-Dateien zu löschen oder umzubenennen, Windows erneut zu installieren oder DISM/SFC bzw. allgemeine ProcMon-Aufzeichnungen zu wiederholen, insbesondere aufgrund des früheren Startproblems nach Änderungen an den Ereignisprotokolldateien.

Das wichtigste Symptom ist, dass der Windows-Ereignisprotokolldienst (EventLog) im Status START_PENDING verbleibt, während der Dump zeigt, dass wevtsvc.dll im folgenden Bereinigungspfad wartet:

LegacyEventLogShutDown → OsEventsCleanup → OsEventsThreadStop → WaitForSingleObjectEx

Ein SERVICE_HANG-Dump zeigt, wo ein Dienst zum Erfassungszeitpunkt blockiert ist. Da dieser Stack jedoch erst nach Beginn des EventLog-Bereinigungspfads erfasst wurde, lässt sich daraus der ursprüngliche Initialisierungsfehler nicht zuverlässig bestimmen.

Microsoft stellt WPR zum Erfassen von ETW-Traces und WPA zu deren Analyse bereit. Bei einem Dienststartfehler auf dieser Ebene erfordern die Auswahl der passenden EventLog-spezifischen Ablaufverfolgung bzw. Debuggerkonfiguration und die Analyse der Dump- oder ETL-Daten jedoch eine fallspezifische Untersuchung.

Die bisherigen Hinweise sprechen daher für einen EventLog-Initialisierungsfehler oder ein Hängen des Dienstes, belegen aber nicht die zugrunde liegende Ursache.

Eine dokumentierte Ursache betrifft falsch typisierte Richtlinienwerte unter:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\EventLog

Werte, die REG_SZ sein sollten, können den Start verhindern, wenn sie fälschlicherweise als DWORD konfiguriert sind. Dies sollte jedoch nur dann als mögliche Ursache betrachtet werden, wenn entsprechende Einträge tatsächlich vorhanden sind.

Ebenso kann anhand der verfügbaren Informationen nicht bestätigt werden, dass Windows 11 26H2 Build 26300 oder wevtsvc.dll 10.0.26100.9818 einen bekannten Fehler aufweist, der dieses Verhalten verursacht. Auch der fehlende rdp-tcp-Listener sollte vorerst als separates Symptom betrachtet werden, da ein Zusammenhang mit dem EventLog-Fehler nicht nachgewiesen ist.

Da es sich um ein Produktivsystem handelt, die üblichen Reparaturmaßnahmen bereits ausgeschöpft wurden und nun eine tiefergehende Analyse erforderlich ist, empfehle ich, ein Microsoft-Supportticket für die weitere Untersuchung zu eröffnen.

Bitten Sie Microsoft Support insbesondere, den ersten EventLog-Initialisierungsfehler vor LegacyEventLogShutDown zu untersuchen. Falls eine erneute Reproduktion erforderlich ist, kann der Support die geeigneten ETW/WPR-Provider, die Debuggerkonfiguration oder die erforderliche Dump-Erfassung bestimmen und prüfen, ob das Verhalten einem bekannten oder intern nachverfolgten Windows-Problem entspricht.

Ich verstehe, dass Sie eine genaue Ablaufverfolgungskonfiguration und eine Bestätigung bezüglich eines möglichen Windows-11-26H2-Fehlers erwartet haben. An dieser Stelle möchte ich jedoch transparent auf die Grenzen von Microsoft Q&A hinweisen.

Microsoft Q&A kann öffentlich dokumentiertes Verhalten erläutern und dokumentierte Problembehandlungsschritte bereitstellen. Das Forum kann jedoch kein Windows-Quellcode-Debugging durchführen, interne Fehlerdatenbanken einsehen oder eine technische Untersuchung von wevtsvc.dll einleiten. Daher kann ich die Untersuchung über das Forum sinnvollerweise nur bis zu diesem Punkt begleiten. Der nächste Schritt sollte ein Microsoft-Supportticket sein, damit die vorhandenen Diagnosedaten über die entsprechenden Support- und Engineeringkanäle analysiert werden können.

Bis Microsoft Support die erforderliche Datenerfassung festlegt, würde ich das System möglichst unverändert lassen und insbesondere EventLog-Daten nicht löschen, umbenennen oder zurücksetzen.

Ich weiß Ihre bereits sehr gründliche Problembehandlung zu schätzen und verstehe, dass eine Eskalation möglicherweise nicht die erhoffte unmittelbare Lösung ist. In diesem Stadium ist dieser Weg jedoch sicherer und technisch angemessener als ein nicht verifizierter Workaround für ein Produktivsystem.

Referenzen:

Windows Performance Toolkit | Microsoft Learn

WPR-How-to-Themen | Microsoft Learn

Problembehandlung bei SQL-Agent-Startfehlern mit Fehler 1053 - SQL Server | Microsoft Learn

WerReportAddDump-Funktion (werapi.h) - Win32 apps | Microsoft Learn

Wenn Sie diese Antwort hilfreich finden, klicken Sie bitte auf Antwort akzeptieren.

Vielen Dank, dass Sie sich für Microsoft Q&A entschieden haben.

Hinweis: Diese Antwort wurde mithilfe eines Übersetzungstools übersetzt. Bitte beachten Sie, dass grammatikalische oder semantische Fehler auftreten können. Vielen Dank für Ihr Verständnis.