Langsam wächst sich das Ganze zur “unendlichen Geschichte” aus. In Teil 1 hatte ich das Problem skizziert, dass nach dem Zurücklesen einer Systemabbildsicherung nach jedem Neustart immer ein Dialogfeld der Wiederherstellung erscheint, in dem gefragt wird, ob die Benutzerdateien wiederherzustellen sind. In Teil 2 hatte ich die Analyse im Process Explorer präsentiert und die Aufgabenplanung als Übeltäter identifiziert, ohne die Task herausfinden zu können. Lässt mir keine Ruhe, also hab ich weiter gegraben und sehe nu so langsam “die Pferde vor der Apotheke kotzen”…
Bin ich blind oder was?
Da ich den Taskplaner als Ursache für den rundll32-Aufruf ausgemacht hatte, versuchte ich die Aufgabe zu identifizieren – scheiterte aber kläglich – was ich auf meine Unfähigkeit zurückschob (hab vielleicht was übersehen). Also noch eine Anfrage im US Technet-Forum [1] abgesetzt. Dort gab es den Tipp, im administrativen Registirerungs-Editor zum Schlüssel
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Schedule
zu gehen, und den DWORT-Wert Start auf 4 zu setzen. Habe ich gemacht, neu gebootet und das System gestartet. Der “nag-screen” war weg!
Da ich aber nicht ohne Aufgabenplanung unterwegs sein will, hilft mir das nicht wirklich. Also den Dienst wieder freigegeben, neu gebootet und dann erneut die Aufgabenplanung durchforstet – kein Ergebnis, es gibt die Aufgabe AfterRecovery einfach nicht.
Also den Windows Explorer angeworfen und den Zweig C:\Windows\System32\Tasks inspiziert. Dort finden sich die Ordner mit den Aufgaben und einige enthalten XML-Dateien mit den Taskparameter (dies ist seit Vista neu eingeführt). Aber nix von AfterRecovery und ReAgent.dll zu finden.
Frag den Process Monitor – welche Schweinereien laufen da ab?
Um noch weiter zu kommen, habe ich neben dem Process Monitor auch den Process Explorers von den Sysinternals in den Autostart eingebunden. Bei zwei Versuchen war ich schnell genug, so dass der Process Monitor beim Anmeldeprozess lief und Datei- sowie Registrierungszugriffe protokollierte. An Hand der im Process Monitor ermittelten Prozess ID konnte ich dann die Daten im Sysinternals Process Explorer filtern. Hier der Auszug aus dem Schnappschuss:
Der Process Explorer zeigt, dass der Windows-Process svchost.exe (verantwortlich für den Aufruf des Taskplaners) erfolgreich auf den Ordner:
C:\Windows\System32\Tasks\Microsoft\Windows\AfterRecovery
zugreifen kann. Schaue ich mir die im Windows Explorer (auch mit Anzeige von versteckten Systemdateien) an, gibt es den Pfad nicht. Und es kommt noch besser. Im Process Explorer wird mir angezeigt, dass der Prozess erfolgreich auf den Registrierungsschlüssel:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\
TaskCache\Tree\Microsoft\Windows\AfterRecovery
zugreifen kann. Der Versuch, diesen Schlüssel im Registrierungs-Editor aufzurufen, wird natürlich abgewiesen (auch wenn man als Administrator unterwegs ist). Also habe ich den Registrierungs-Editor mit:
SysinternalsSuite\PsExec.exe -s -i regedit
gestartet. PsExec stammt aus den Sysinternals-Tools und führt den Registrierungs-Editor unter dem Systemkonto aus. Mir ist allerdings die Kinnlade runtergefallen, als ich den obigen Zweig inspizieren wollte. Im Schlüssel Tree\Microsoft\Windows\ ist alles mögliche eingetragen. Nur taucht kein Schlüssel AfterRecovery auf.
Gut, dachte ich, vielleicht haben Microsofts Entwickler da ein Nullbyte mit reingehauen, um die Inspektion im Registrierungs-Editor zu verhindern (wird von Malware gerne genutzt). Also mal das Sysinternals Tool RegDelNull mit –s aufgerufen, um die Registrierung auf Einträge mit Nullbytes scannen zu lassen.
Das Tool durchläuft die Registrierung, meldet aber keine Einträge mit Nullbytes.
Und nun komme ich nicht weiter bzw. bin mit meinem Latein wieder am Ende. Der Process Explorer meldet Zugriffe auf Dateien, die es nicht gibt und führt Schlüssel in der Registrierung auf, die nicht vorhanden sind. Ich warte jetzt mal, ob über das Technet-Forum noch was sinnvolles zurück kommt – und werde mein Pferd vor der Apotheke losbinden. Denn was kann das arme Tier dafür, dass die MS-Entwickler solche undokumentierten Schweinereien veranstalten. Oder bin ich einfach nur grässlich betriebsblind und sehe die offensichtliche Lösung nicht?
Update: einige Teilerkenntnisse
Ein klitzekleines Stückchen bin ich wohl weitergekommen. Mein Thread im Technet-Forum [1] hat dazu geführt, dass sich Miya Yao (MSFT CSG – wohl Community Service Group) des Problems angenommen hat und nun mit mir rumrätselt, wie man dem Thema beikommen könnte. Weiter geht es in Teil 4.
Links:
1: Diskussion im Technet-Forum (Englisch)
Artikel:
a: Meldung “Die Wiederherstellung wurde abgeschlossen” Teil 1
b: Meldung “Die Wiederherstellung wurde abgeschlossen” Teil 2
c: Meldung “Die Wiederherstellung wurde abgeschlossen” Teil 3
d: Meldung “Die Wiederherstellung wurde abgeschlossen” Teil 4
