[En]Windows legt in regelmäßigen Abständen eine Sicherungskopie der Registrierungsdateien an. In Windows 10 sieht es aber so aus, als ob dieser Vorgang in der Version 1803 und 1809 scheitert.
Anzeige
Zum Hintergrund der RegBack-Sicherung
In Windows gibt es einen Ordner C:\Windows\System32\config\RegBack in der das Betriebssystem zyklisch Kopien seiner Registrierungsdateien ablegen kann. Dazu existiert in der Aufgabenplanung einen Task im Zweig: Microsoft -> Windows –> Registry
Diese Aufgabe legt zyklisch diverse Dateien im Ordner RegBack an. Ich habe das unter Windows 7 mal in einer administrativen Eingabeaufforderung kontrolliert. Das sieht dann so aus:
Es sind die systemweit gültigen Strukturdateien der Registrierung (Hives) zu finden. In SOFTWARE sind z.B. alle installierten Programme zu finden und unter SYSTEM sind die Registrierungsschlüssel für das System abgelegt.
Anmerkung: Ich habe in obigem Screenshot eine administrative Eingabeaufforderung zur Anzeige der Dateien verwendet. Man kann zwar auch den Explorer nutzen, muss diesem aber Zugriffsrechte auf die betreffenden Ordner gewähren. Dann werden diese Zugriffsrechte aber permanent für das Benutzerkonto in den NT-Zugriffsrechten des Ordners eingetragen. Das wollte ich vermeiden. Es gibt zwar die Möglichkeit, einen portablen Dateimanager wie Explorer++ mit administrativen Rechten zu starten, um dieses Berechtigungsproblem zu umgehen. Aber in meinem Kurztest zeigte dieser unter Windows 7 keine Dateien an, auch wenn diese vorhanden waren. Den Grund habe ich auf die Schnelle nicht herausfinden können (Systemdateien waren zur Anzeige zugelassen). Die Eingabeaufforderung erschein mir die zuverlässigere Lösung zu sein.
Wenn ich es nicht falsch einordne, können diese Kopien bei einem nicht mehr startenden Windows verwendet werden, um über Last known good configuration das System (durch zurückkopieren der Dateien) wieder zum Booten zu bringen.
Durchwachsene Ergebnisse
Befasst man sich aber mal mit der Funktion, ist nicht alles eitel Sonnenschein. Microsoft gibt an, unter Windows 7 die Systemwiederherstellung bei beschädigter Registrierung zu versuchen (in Windows 10 ist diese Funktion standardmäßig deaktiviert). Man kann auch versuchen, die gesicherten Hive-Dateien aus RegBack manuell unter Windows PE zurück zu kopieren. Dieser Beitrag vom August 2018 beschreibt diese Schritte, um das Ganze manuell zurück zu holen. In diesem Forenbeitrag beschreibt einen [erfolglosen] Versuch, die Dateien manuell zurück zu schreiben (die Kopien waren wohl schon beschädigt). Und so richtig zuverlässig war das Ganze wohl nicht – zumindest gibt es in diesem HP-Forenbeitrag aus 2017, dessen RegBack-Ordner leer war, als er diesen gebraucht hätte. Immer wenn der Trigger der Aufgabenplanung versagt, werden halt keine Backups der Hives geschrieben.
In diesem Beitrag zu Windows Vista aus 2009 beklagt sich zudem jemand, dass das Anlegen der Backups für die Registry eine ziemliche hohe Systemlast erzeuge. Ein kurzer Gedanke war daher, dass Microsoft die Sicherung der Registrierungsdateien daher in Windows 10 unterlässt. Aber über die Aufgabenplanung kann das ja in Zeiten des Leerlaufs verlegt werden. Zudem gibt es ja noch die betreffende Aufgabe in der Aufgabenplanung.
Anzeige
In Windows 10 V1803/1809 scheitert das Backup
Es kam in diesem Kommentar schon als Randbemerkung auf: In Windows 10 Version 1809 klappt das automatische Anlegen der Backups der Registry-Hives wohl nicht mehr. Schaut man sich das Ganze in Windows 10 Version 1809 in der Eingabeaufforderung an, ist der Ordner RegBack leer, obwohl es die Aufgabe zur Sicherung gibt.
Auch eine manuelle Ausführung der Aufgabe zur Sicherung der Registrierungs-Hive-Dateien ändert daran nichts. Ich habe dann im Internet gesucht – dieser Foreneintrag in MS Answers vom 7. Juni 2018 beklagt diesen Effekt bereits bei Windows 10 V1803. Er schreibt, dass die Dateien eine Größe von 0 aufweisen würden. Weitere Nutzer bestätigen diese Beobachtungen. Es wird vermutet, dass Microsoft das Registry-Backup ab Windows 10 V1803 'gekillt' habe. In der Version 1809 ist der Ordner sogar ganz leer.
In diesem Tweet wird das Ganze ebenfalls bereits für die Windows 10 V1803 thematisiert, und einige Leute versuchen es im Feedback-Hub oder per Twitter den Microsoft-Entwicklern zur Kenntnis zu bringen.
#Windows10 1803+ no longer creates backup copies of the registry
Major blow to the Windows emergency restore abilities (forum support).
Plz RT & in #feedbackhub
Insiders on 1809: https://t.co/juah6C3Mk4
Non-insiders on 1803: https://t.co/CsX0FLHWS4cc @WithinRafael @rlinev pic.twitter.com/xrStdXzLxE
— Vadim Sterkin (@vsterkin) 30. Oktober 2018
Die Kollegen von dekmodder.de haben sich (wohl nach dem Hinweis in obigem Tweet) in diesem Beitrag ebenfalls an diesem Thema abgearbeitet. Dort wird bestätigt, dass die Registry-Backup-Funktion seit Windows 10 V1803 nicht mehr funktioniere. Den Vorschlag, die Hive-Dateien manuell unter Windows PE zu sichern, halte ich für zu aufwändig. Mal schauen, ob Microsoft da was nachbessert oder sich zu äußert.
Ähnliche Artikel:
Windows 10 Oktober Update (Version 1809): (Upgrade-) FAQ
Windows 10 Oktober 2018 Update – Upgrade-Tipps
Windows 10 V1809: Bekannte Probleme – Teil 1
Windows 10 V1809: Bekannte Probleme – Teil 2
Windows 10 V1809: Bekannte Probleme – Teil 3
Windows 10 V1809: Anzeigebug bei Benachrichtigungen fixen
Bauchlandung mit Windows 10 V1809: Rollout gestoppt
Windows 10 V1809: Ursache für Rollout-Stopp erklärt
Windows 10 V1809: Drucker-/Scanner-Treiber per Update
Windows 10 Okt. 2018-Updates erzeugen BSOD 'WDF Violation'
Windows 10: Update KB4468550 fixt Audio-Probleme
Windows 10 V1809: Update KB4464455 für Insider
Windows 10 V1809: Schreib-Bug in ZIP-Funktion
Windows 10 V1809: ZIP-Bug von MS bestätigt
Windows 10 V1809: Unicode-Font-Fallback-Bug
Windows 10 V1809: Defender Uhrzeitanzeige geht vor
Windows 10 V1809: App-Fehler 'The configuration registry database is corrupt'-Fehler erklärt
Windows 10 V1809: Update KB4464455 fixt ZIP-Bug
Kaputtes Windows 10 V1809-Upgrade erreichte Millionen PCs
2015
regedit /e "%userprofile%\desktop\regback_easy.reg"
wink richtet sich vor allem an microslop, und jene die noch dabei sind zu begreifen was hier wirklich abgeht….. … …
PS: "hust", als admin ausführen
Das ist die normale Exportfunktion des Registrierungseditors. Das oben Beschriebene ist formal was anderes. Es werden Strukturdateien (Hives) mit HKLM etc. kopiert.
Oder, wer es gerne per Maus mag -> Registry-Backup
…auch PORTABLE, also WinPE-tauglich
https://www.tweaking.com/content/page/registry_backup.html
oder auch ERUNT, das schon seit ewigen Zeiten existierende Tool
https://www.heise.de/download/product/erunt-53485
.
Kein Wunder, dass das nicht auffällt. Wer wirklich Backups braucht, der macht Systemimages und spielt nicht mit einzelnen Registryzweigen rum. "Major blow to the emergency restore capabilities" – LOL! Wer auf diese vertraut, testet das doch, oder etwa nicht? Nur weil es mal in Win7 ging, wird da doch nicht blind drauf vertraut.
Dass das keinem aufgefallen ist, hat schon seinen Grund. Ich habe hier auf 1709 mal reingeschaut – Dateien da, aber alle 0 KB, Task läuft nicht einmal von alleine (aber funktioniert, wenn manuell angestoßen). Ist wohl schon mehr als ein Jahr kaputt, vielleicht ja auch schon in älteren Win10 Versionen. Ich würde niemandem raten, das überhaupt zu nutzen.
Der springende Punkt ist ein anderer. So was muss per Regressionstest bei den Entwicklern überprüft werden. Manuell wird kein Nutzer 'damit herumspielen', weil das kaum jemand weiß und das eigentlich nicht vorgesehen ist. Aber wenn die last known good configuration in Windows PE zurückgelesen werden soll, ist es halt essig.
Es kann sein, dass das von der MS Entwicklung geschlachtet wurde. Aber das wurde nie kommuniziert. Zudem gibt es nach wie vor die Aufgabe im Taskplaner.
Und ich erinnere mich, als junger Mann beim TÜV mein altes Auto vorgestellt zu haben – ein Nebelscheinwerfer ging nicht, und der Prüfer hat das moniert. Mein Einwand 'sind optional von mir dran geschraubt', hat er mit 'was am Auto dran ist, hat zu funktionieren' gekontert. Recht hatte er …
Dem kann ich nur zustimmen, wenn die Option Vorhanden ist sollte sie auch funktionieren, ich erinnere mich grau dran dass ich unter Windows 7 auch mal die Registrie zurück Importiert habe.
Die RegBack Dateien bei mir sind auch 0Kb Dateien
C:\Windows\System32\config\RegBack>dir
Datenträger in Laufwerk C: ist OS
Volumeseriennummer: 7×10-Ex7C
Verzeichnis von C:\Windows\System32\config\RegBack
05.05.2018 19:11 .
05.05.2018 19:11 ..
05.05.2018 19:11 0 DEFAULT
05.05.2018 19:11 0 SAM
05.05.2018 19:11 0 SECURITY
05.05.2018 19:11 0 SOFTWARE
05.05.2018 19:11 0 SYSTEM
5 Datei(en), 0 Bytes
2 Verzeichnis(se), 152.998.469.632 Bytes frei
Mich stört es jetzt gerade nicht da ich andere Backups erstelle, aber andere Leute nutzen dies nicht und dann wäre die Registrie wohl mit eine der Letzten Option, so ein System zu stabilisieren.
Eine Frage: Wann war denn "Last known good" überhaupt das letzte Mal im Startmenü auswählbar? In welchem OS war das?
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Configuration Manager\LastKnownGood" /v Enabled /t REG_DWORD /d 1 /f
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Configuration Manager" /v BackupCount /t REG_DWORD /d 2 /f
damit lässt sich die im besten windows aller zeiten entfernte option wieder aktivieren. funktioniert genauso gut und zuverlässig wie damals unter windows 7. was geht ab – so eine funktion zu entfernen??.. blablablabla…
PS: run these two lines in an elevated command prompt
PPS: in die erweiterten optionen neustarten kann man mit:
Win+R -> %comspec% und
shutdown.exe -r -o -f -t 0
@wufuc_MaD
Und die so zurückgewonnene Last-known-good-Option benutzt dann diese Dateien, von denen hier gesagt wird, dass sie gar nicht mehr erstellt werden? Ich denke nicht und Tests (mit manuell über Ausführung des Tasks auf 1709 erzeugten Dateien) haben dies auch bestätigt. Es geht mir hier auch nicht um "last known good" generell, sondern darum, ob man diese Dateien überhaupt vermissen sollte, wenn man (Start-)probleme lösen möchte. Ich denke, hier wird ein defekter Mechanismus besprochen, den eh keiner mehr nutzen sollte. Wann immer MS mal empfohlen hat, alte Registryhives zu einem bestimmten Zweck einzuspielen – diese Tipps habe ich Ewigkeiten nicht mehr gesehen und bezweifle stark, dass MS dieses Vorgehen noch empfehlen würde.
Sicher das die Funktion nicht shutdown -r -o – f – l heißt ?
"Wenn ich es nicht falsch einordne, können diese Kopien bei einem nicht mehr startenden Windows verwendet werden, um über Last known good configuration das System wieder zum Booten zu bringen."
AUTSCH!
Diese Kopien werden dafür NICHT benutzt!
Damit sind auch Deine Spekulationen hinfällig: HÖR AUF, Deine Leser zu desinformieren!
JFTR: Windows NT legt seit Anbeginn seiner Zeiten eine Kopie des verwendeten Registry-Zweigs [HKEY_LOCAL_MACHINE\SYSTEM\ControlSet###] an, sobald ein Systemstart "erfolgreich" war, und trägt ### in [HKEY_LOCAL_SYSTEM\Select] "LastKnownGood"=dword:### ein; das Kriterium für "erfolgreich" darfst Du selbst recherchieren.
Dann klär mal auf…
Hab in einer Einrichtung auch ne Handvoll PCs (edit: Windows 7 Pro), die sich beim Start zurücksetzen sollen (keine Updates während der Benutzung, also keine Systemwiederherstellungspunkte; während Hochfahren wird das Kiosk-Profil, nennen wir das mal so, wieder durch eine bei der Installation/Erststart erstellte Kopie ersetzt).
Hin und wieder kommt es vor, dass einer dieser Computer nicht ordnungsgemäß heruntergefahren und ein zuvor erstellter Registry-Snapshot wiederhergestellt wird – konnte das noch nicht live beobachten, jedoch wurde dann ein Temp-Profil geladen, weil das neu erstellte Profil nicht mehr zur SID des Kiosk-Benutzers passte.
ppps://support.microsoft.com/de-de/help/947215/you-receive-a-the-user-profile-service-failed-the-logon-error-message
standard
Du bist verwirrt und machst offensichtlich mehrere Fehler!
1. was auch immer Du mit dem Frickeln eines "Kiosk-Profils" erreichen willst: Du pfuschst damit Windows ins Handwerk.
2. bei Kiosk-Systemen solltest Du das Konto "Gast" aktivieren: dessen Benutzerprofil wird beim Abmelden gelöscht.
3. falls Du UNBEDINGT ein (vor)konfiguriertes Benutzerprofil verwenden willst: "MANDATORY profiles" gibt's seit dem letzten Jahrtausend.
Das Beispiel mit den SIDs ist auch nur eine von mehreren Auswirkungen, wenn dieses Problem auftritt. Ob/wie ein Gast-Profil zu konfigurieren ist, hat mit dem Thema des Artikels nix zu tun.