Nach dem Update auf Windows 10 Version 20H2, der Herbstversion 2020 hatte ich auf einer Reihe von Lenovo Notebooks und auf zwei Microsoft Surface Pro Tablets das Problem, dass sich im Verlauf der Anmeldung das Betriebssystem mit einem Bluescreen (BSOD, Stopp-Fehler) verabschiedete.
Für alle die hier nicht mehr weiterlesen wollen, könnte das Setzen des folgenden Parameters in der Registry von Windows 10 und ein damit verbundener Neustart das Problem beheben.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CSC\Parameters]
"FormatDatabase"=dword:00000001
Neustart nicht vergessen 
Alle Interessierten dürfen gerne den Rest des Beitrags lesen.
Fehlerbild(er)
Eine Reihe mir zugesandter Screenshots die von den Anwendern mit dem Smartphone erstellt wurden, zeigten ein diffuses Fehlerbild.
Unterschiedlich war dabei immer die Fehlerursache, dabei tauchten verschiedene Komponenten des Betriebssystems auf:
- mrxsmb20.sys (7x), mountmgr.sys (1x) und auch der volume.sys (1x)
- Lenovo L460, L470 und T14L
- Surface Pro 4 und Surface Pro 7
Gleich waren auf allen Windows 10 Systemen die folgenden Parameter
- Der BSOD tauchte immer während der Anmeldung auf
- Windows 10 Version 20H2
- kürzlich auf die Version 20H2 aktualisiert
- Nach dem Update lief der Computer im Netzwerk (Firma) stabil!
- Der Computer ist Mitglied einer Domäne, aber die Anmeldung erfolgte ohne Verbindung zum Domain Controller im HomeOffice
- Konfiguriertes OneDrive for Business
Workarounds
Eine schnelle Lösung brachte die Verwendung eines lokalen Benutzers auf den Endgeräten. Der Computer war zwar nach wie vor Mitglied der Domäne, aber von Benutzer wurde im HomeOffice ein lokales Konto verwendet. Dieses hatte ich entweder im Vorfeld schon angelegt, konnte es über Teamviewer “nachrüsten” oder der Anwender war dazu selbst in der Lage.
Damit war ein Zugang per RDP auf den eigentlichen PC innerhalb der Firma möglich und der Druck erst einmal weg.
Darüber hinaus brachte das Zurücksetzen von Windows auf die vorherige Version bei allen Surface Geräten Abhilfe. Der BSOD war verschwunden! Ich muss aber gestehen, dass ich das auf den Lenovo Notebooks nicht in Betracht ziehen wollte.
Zusammenfassend konnte das Problem schnell mit den beiden folgenden Ansätzen gelöst werden.
- Verwenden eines lokalen Benutzers (den ich inzwischen generell immer anlege, zusätzlich zu einem lokalen Admin) und auch einrichte (Outlook, OneDrive, …)
- Rückkehr auf die vorherige Version von Windows 10
Zufrieden war ich aber mit beiden Lösungen nicht. Zum einen führen lokale Benutzerprofile dazu, dass irgendwann Daten darin verschwinden und nicht mehr auf dem Server gespeichert werden. Eine Rückkehr auf die vorherige Version von Windows kann nur temporär eine Lösung sein, das nächste Update kommt bestimmt. Also musste dafür eine ordentliche Lösung gefunden werden und kein Workaround. Durch die Workarounds konnten alle Anwender zunächst einmal arbeiten.
Die eigentliche Lösung
Durch das Auftauchen von Komponenten die mit dem Speicher (Festplatte) und Cache von Windows zu tun hatten, dachte ich zuerst an einen Defekt des Notebooks. Da der BSOD aber nach der Verwendung des lokalen Benutzer-Kontos nicht mehr auftrat, konnte ich diesen Verdacht beiseitelegen und außerdem hatte ich inzwischen das Problem auf mehreren Geräten.
Geblieben waren aber der mrxsmb20.sys und das der STOPP-Fehler der generell bei einer Anmeldung ohne Domain Controller erfolgte.
Das zeigte mir auch ein Blick in den memory.dmp (PROCESS_NAME: winlogon.exe ist der Anmelde-Prozess von Windows)
Dazu bekommen wir gleich zu Beginn der Analyse den Hinweis, dass etwas beim Zugriff auf das Dateisystem schief gegangen ist, nämlich als eine RDR (ReDirection) stattgefunden hat.
Das ist der Fall, wenn ein Computer sich Offline anmeldet. Inzwischen konnte ich nachvollziehen, dass die Anmeldung direkt im Firmennetzwerk ohne Probleme funktioniert und lediglich im HomeOffice der BSOD auftritt.
Im ersten Screenshot des Debuggers ist zu sehen, dass es sich um einen ExceptionCode c0000005 handelt und der Zugriff auf den Offline Cache fehl schlägt. Der entsprechende Ordner dafür liegt im Windows Verzeichnis mit dem Namen CSC.
# Windows Client Side Cache Ordner (Offline Files)
%WINDIR%\CSC
Die Berechtigungen auf diesen sind einfach gehalten und mit SYSTEM:F überschaubar. Allerdings lassen sie sich nur im passenden Kontext überprüfen. Ich verwende dazu Psexec.exe von Sysinternals, welches mit dem Parameter –s im Systemkontext gestartet werden kann.
# Start von Psexec.exe unter Local System
C:\Temp> "\Program Files (x86)\Windows Sysinternals Tools\psexec.exe" -s cmd.exe
# Kontrolle der Berechtigungen
C:\Windows> cacls csc /t
Nachdem die Berechtigungen richtig angezeigt wurden, erinnerte ich mich an frühere Migrationen von Dateiservern wo im Anschluss der CSC Cache Probleme gemacht hat und zurück gesetzt werden musste. Korrekter Weise dessen Datenbank und ein Upgrade von Windows 10 auf eine höhere Version könnte hier durchaus ebenfalls zu Problemen oder Inkompatibilitäten führen.
Ein Rücksetzen des CSC ist über den folgenden Registry-Eintrag möglich. Natürlich verbunden mit einem notwendigen Neustart des Computers.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CSC\Parameters]
"FormatDatabase"=dword:00000001
Damit war auch eine Anmeldung im HomeOffice möglich und damit die Lösung des Problem gefunden.
Alle nun folgenden Notebooks habe ich gleich im Anschluss nach dem Upgrade ebenfalls mit diesem Eintrag versehen und die CSC Datenbank gelöscht. Das Problem ist danach nicht mehr aufgetreten.
Enjoy it, b!
Windows SBS and Essentials Blog 