XP BSOD 0xC000021A während des System-Starts (Session Manager initialization terminated)
Hallo,
heute möchte ich Ihnen von einem interessanten Fall berichteten, an dem ich vor einiger Zeit gearbeitet hatte.
Thema: XP BSOD 0xC000021A während des System-Starts (Session Manager initialization terminated)
Hintergrund:
Der Kunde hat mehrere tausend Arbeitsstation auf Basis von Windows XP SP3, die global verteilt laufen.
Aus unbekannten Gründen trat nach und nach (auf den verschiedenen Systemen) das Problem auf, das die Systeme nicht mehr starteten und während der Boot-Phase in einen Blue-Screen gelaufen sind. Das Starten der Systeme im Safe-Mode war ebenfalls nicht mehr möglich.
Betroffene Systeme mussten daher Re-Installiert werden.
Blue-Screen
BCC: c000021a (Fatal System Error)
The session manager initialization system process terminated unexpectedly
Status: 0xc000000d ()
Ein DUMP-File wurde nicht geschrieben.
Verlauf:
Einer der ersten Schritte war die Analyse der Registry-Keys eines defekten Systems, die für die Initialisierung des Session Manager verantwortlich sind (und dessen Gegenprüfung mit den Keys eines funktionierenden Systems des Kunden).
Hierbei habe ich festgestellt, dass der Entry-Point des Session Managers unter Environment verändert wurde.
Entry-Point f. Environment:
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager\Environment\
“(Default)”
“Data” stand hierbei statt auf “(value not set)” auf NULL (also leer).
Da der Session Manager auf die Registry-Daten via Low-Level zugreift (also nicht mit Registry-Kommandos, sondern die Registry-Files unter system32\config an-sich einließt) und für den Entry-Point erwartet wird, das diesem Wert keine Daten (also un-set) zugeordnet sind, schlägt die Initialisierung fehl.
Weitergehende Analyse:
Als nächsten musste herausgefunden werden, wodurch und warum dieser Wert manipuliert wurde.
Hierzu haben wir das Auditing für den Registry-Wert auf einem funktionierendem System aktiviert – was angesichts der Tatsache, dass es sich zum einem um Windows XP Systeme handelte und zum anderen nicht bekannt war, auf welchem System das Problem das nächste Mal auftritt – nicht ganz trivial war (zusätzlichen zu der Tatsache, dass natürlich die Dringlichkeit der Anfrage recht hoch war).
Wir haben hierzu das generelle Auditing über eine GPO für einen bestimmten Benutzerkreis (für eine OU) aktiviert
Computer Configuration > Windows Settings > Security Settings > Local Policies > Audit Policy -> Audit object access > Success [enable]
Zusätzlich musste das Auditing speziell für den Registry-Key aktiviert werden, was wir über subinacl realisiert hatten.
Folgendes Kommando haben wir hierfür verwendet (im Nachhinein sicherlich nicht optimal, jedoch angesichts der Dringlichkeit das funktionalste Mittel):
subinacl /keyreg "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager\Environment\" /audit "/aace=everyone TYPE=0x2 Flags=0xc3 AccessMask=0x40000000"
Nach dem das Problem auf einem der beobachteten Systeme aufgetreten ist, habe ich anhand der Audit-Einträge im Security-Log festgestellt, das ERIS – eine Komponente von Empirum – als einzige Komponente schreibend auf „Environment“ zugegriffen hat, also ursächlich für das Problem war.
Als nächstes musste der Hersteller kontaktiert werden…
Ergebnis:
Das Problem wurde im Anschluss von dem Hersteller als BUG identifiziert, ein FIX wurde hierzu entwickelt u. bereitgestellt.
--
Ich hoffe, dass Sie diesen Beitrag interessant finden und würde mich über Ihr Feedback freuen.
Grüße,
Matthias Meiling
Support Engineer - Platform Core
Comments
Anonymous
January 19, 2012
Wir haben das gleiche Problem mit Windows 7 Rechnern, und haben zusammen mit Microsoft lange nach einer Lösung gesucht. Ich hoffe, Matrix42 kann auch hier helfen. Vielen Dank für deinen BlogAnonymous
February 20, 2012
Vielen Dank für diese Informationen. Wir haben das gleiche Problem auf XP und WIndows 7 Rechner. DEAFAULT war NULL. Das dies vom ERIS beieinflusst wird hatten wir nicht herausgefunden. VIELEN DANK. Gruss Daniel