Windows 10: Falle bei sfc in Windows PE

Nachdem bereits jeder 10. Rechner in Deutschland mit Windows 10 läuft, ist es Zeit für einen kleinen Blog-Beitrag, in dem es um die Systemprüfung mittels des Befehls sfc geht. Es gibt Berichte, dass sfc unter Windows PE nicht funktioniert.


Anzeige

Worum geht es genau?

Auf die Idee für diesen Blog-Beitrag hat mich dieser heise-Forenbeitrag gebracht. Der Nutzer bemängelt, dass der system file checker in der “Eingabeaufforderung” beim “Reparaturmodus” nicht funktioniert. Werfen wir einfach mal einen Blick auf die Sachlage.

1. Hierzu ist im Windows 10 Startmenü der Punkt Ein/Aus anzuwählen und dann der Punkt Neu starten bei gedrückter Umschalt-Taste anzuwählen.

Windows 10 startet dann in die Wiederherstellungsumgebung Windows PE und meldet sich mit folgendem Screen.

2. In Windows PE klickt man auf Problembehandlung und in der Folgeseite wählt man Erweiterte Optionen. Dann erscheint diese Seite.

3. Jetzt lässt sich der Punkt Eingabeaufforderung wählen und nach einem Neustart gelangt man nach einer Benutzeranmeldung in die Eingabeaufforderung.


Anzeige

Wer dann dort den Befehl sfc /scannow eingibt, um die Systemdateien auf Beschädigungen überprüfen zu lassen, erlebt eine Überraschung.

Der Befehl muckt und fordert zum Neustart auf. Aber nach einem Neustart kommt die gleiche Meldung – sfc ist offenbar unter Windows 10 kaputt?

Ins Knie geschossen – so geht’s

Ein kleiner Blick auf die Pfadangabe offenbart, dass der Befehl sfc auf die Dateien im Laufwerk X: anzuwenden ist. Dort liegt aber die Windows PE-Umgebung – der Befehl macht also keinen Sinn. Man muss die Systemdateiprüfung im Offline-Modus ausführen. Ich habe im Artikel Windows-Ressourcenschutz konnte den Reparaturdienst nicht starten den Ansatz beschrieben. Der einzugebende Befehl lautet:

sfc /offbootdir=d:\  /offwindir=d:\windows /scannow

wobei vorausgesetzt wird, dass die Windows 10-Installation auf dem Laufwerk D:\ liegt (lässt sich mit dir überprüfen). Dann sollte folgendes in der Eingabeaufforderung angezeigt werden.

Na bitte, geht doch! Ähnliches gilt übrigens für den dism-Befehl (siehe Windows 8: Komponentenstore reparieren). Dieser muss in Windows PE auch im Offline-Modus ausgeführt werden.

Im abgesicherten Windows 10 funktioniert es besser

Um Windows 10 auf beschädigte Dateien zu prüfen, sollte man die Eingabeaufforderung im abgesicherten Modus verwenden.

1. Gehen Sie wie oben beschrieben zum Aufrufen von Windows PE vor.

2. In Windows PE klicken Sie auf Problembehandlung und in der Folgeseite wählen Sie Erweiterte Optionen. Dann erscheint diese Seite.

3. Jetzt lässt sich der Punkt Starteinstellungen wählen und nach einem Neustart gelangt man zu einer Auswahlseite.

4. Dann wählen in folgendem Fenster den Punkt 4. Abgesicherter Modus aktivieren.

Jetzt gelangt man zur Windows-Anmeldung und dann in den abgesicherten Windows-Modus – dort ist der Desktop mit schwarzem Hintergrund versehen und der Text “Abgesicherter Modus” wird angezeigt.

Jetzt kann man, wie gewohnt, die Eingabeaufforderung über das Schnellstartmenü (Windows+X) öffnen und Befehle wie sfc oder dism ausführen.

Ähnliche Artikel:
Windows 10 Wiki/FAQ
Windows 10: Kumulatives Update KB3081424
Windows 10: Keine Startmenü- und App-Synchronisation
Windows 10 Upgrade-Troubleshooting FAQ – Teil 1
Windows 8: Komponentenstore reparieren
Windows 10: Administratorrechte verloren …
Windows 10: Anmeldung am Microsoft-Konto scheitert in Apps


Anzeige
Dieser Beitrag wurde unter Windows 10 abgelegt und mit , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

9 Antworten zu Windows 10: Falle bei sfc in Windows PE


  1. Anzeige
  2. Pingback: Windows 10 Updates und Buildupdates - Seite 92

  3. Matthias sagt:

    Hallo Günter,

    ich bin nun ein wenig verwirrt, Du schreibst folgendes:
    Der einzugebende Befehl lautet:

    sfc /offbootdir=d:\ /offwindir=d:\windows /scannow

    wobei vorausgesetzt wird, dass die Windows 10-Installation auf dem Laufwerk C:\ liegt (lässt sich mit dir überprüfen). Dann sollte folgendes in der Eingabeaufforderung angezeigt werden.

    mit Hinweis Windows muss auf C: liegen und der Befehl weist aber D: hin?
    Ist das so richtig?

    MfG
    Matthias

  4. Anzeige

  5. Matthias sagt:

    @Beserkus

    Wenn Windows auf Laufwerk/Partition C: Installiert ist, dann ist in der Regel dieses unter WinPe der Fall. Zumindest kenn ich das nicht anders.
    Ist Windows dann wirklich auf C: dann lautet der Befehl wahrscheinlich so:
    sfc /offbootdir=c:\ /offwindir=c:\windows /scannow

    Nachprüfen kann man es ja auch Notfalls über den Dateiexplorer den ich über das Notepad starten kann.
    Dazu in der Eingabeaufforderung folgenden Befehl ausführen: notepad
    Und im Notepad auf “Datei” und dann “Öffnen” gehen und schon öffnet sich der Explorer. So habe ich es mal in einem Lehrvideo eines bekannten Blog- und Buchautors gesehen.

    MfG
    Matthias

  6. floogy sagt:

    Ich habe ein Problem in Windows XP x64 (Ja, ich weiß, aber seit ich ein altes 32bit System wieder booten konnte, will ich das nun auch mit dem 64bit System versuchen). Die Systeme starte ich mit Grub und EasyBCD bzw. bootmgr, boot.ini. in chainloading (Grub>EasyBCD [WinXPx64, WinXP32, Win7, Win10]>boot.ini (NTLDR) D: (WinXPx64)| G: /WinXP32)> (D:) WinXPx64 (läd mit SplashScreen bis BSOD 0xc000021a, oder bei F8 bis SPTD.sys (Daemontools 4), den man überspringen kann. Dann hängt er afair bei ACPI.sys).

    Wenn ich von CD-ROM starte (nLite mit intel AHCI-Driver [IRST ICH7, Intel® 7 Series C216 Chipset Family SATA AHCI Controller, 11.1.5.1001]), dann werden mir die diversen Windows Installationen nach ‘R’ in der recovery console angeboten (C:, D:, G:, I:). Ich wähle D: und kontrolliere mit Dir, ob es auch die Windiows XP x64 Installation ist. Ich finde nach dem Administrator Login in %systemroot% (Windows) unter System32 die sfc.exe des XP x64 Systems. Diese lässt sich aber nicht starten. Das System kann sie nicht finden selbst wenn DIR .\sfc.exe sie zeigt, kann ich mit .\sfc.exe nicht ausführen, auch nicht mit vollem Pfad. Ich kann ausschließlich die Programme ausführen, die HELP mir anzeigt.

    Woran liegt das? Ich denke nicht, dass `sfc /scannow /offbootdir=c:\ /offwindir=c:\windows` dort helfen könnte, da sfc ja nicht gefunden wird.

    Idee: Kann ich im Dualboot mit den Parametern /offbootdir /offwindir im Muliboot-Szenario etwas erreichen?

    Ich habe auch die Hives aus dem XP x64 in MiTeC Windows Registry Recovery geladen und es werden mir ein Haufen installierter Treiber angezeigt, unter anderem, weil ich das System mal von amd64 Athlon 3500+ auf Intel i5-3475S@2.9GHz updatete.

    Im August 2014 hatte ich einen Switch in der Registry bearbeitet (weiß nicht mehr was), danach startete das XP x64 nicht mehr, dessen Kopie ich zuvor erfolgreich auf Windows 7 migriert hatte (oder neu aufgesetzt?). Danach startete es nicht mehr. Leider musste ich feststellen, dass ich aus Platzmangel den Computerschutz deaktiviert hatte und auch keine Wiederherstellungspunkte oder sich zeitnahe Kopien der Registry unter System Volume Information befanden.

    Meine Frage: Für SFC in der Recovery Console müsste ich es in nLite der XP x64 Installations-CD integrieren? Oder kann ich einen Suchpfad definieren und er kann dann die Programme in diesem Pfad ausführen?

    Funktionieren die /offbootdir /offwindir von Windows 10 aus, das ich gerade uinter C: benutze, und das zugriff auf D: hat (Windows XP x64)?

    Ich überlege, ob ich nicht alle Treiber in der System mit MiTeC lösche, und durch die Treiber aus einer Windows XP x64 VM ersetze? Intel® RST AHCI Treiber könnte ich wieder einfügen … Würde das System nicht alle Hardware-Komponenten so beim Start automatisch erkennen?

    Ein anderer Ansatz: Gibt es nicht Transaktions-Logs, der damaligen Registry-Bearbeitung, die Hinweise geben könnten, was damals geändert würde? Z.B. in System.log etc. Um so dem eigentlichen Fehler gezielt offline bearbeiten zu können?

    https://www.tenforums.com/performance-maintenance/37586-question-how-can-i-import-reg-files-non-booting-windows.html
    https://medium.com/dfir-dudes/regipy-automating-registry-forensics-with-python-b170a1e2b474
    https://ericzimmerman.github.io/#!index.md

    • floogy sagt:

      Von Windows 10 aus funktioniert es nicht. Vielleicht muss es die passsende sfc.exe und Umgebung für Windows XP SP2 x64 sein? Aber von der Recovery Console geht es ja auch nicht, obwohl sfc.exe unter D:\WINDOWS\SYSTEM32 liegt. Hm, vielleicht versuche ich mal die 32bit Version unter SysWOW64?

      floogy@Windows10 ~
      $ file “D:\WINDOWS\SysWOW64\sfc.exe”
      D:\WINDOWS\SysWOW64\sfc.exe: PE32 executable (console) Intel 80386, for MS Windows

      floogy@Windows10 ~
      $ file “D:\WINDOWS\system32\sfc.exe”
      D:\WINDOWS\system32\sfc.exe: PE32+ executable (console) x86-64, for MS Windows

      Microsoft Windows [Version 10.0.18363.476]
      (c) 2019 Microsoft Corporation. Alle Rechte vorbehalten.

      C:\Windows\system32>sc config trustedinstaller start=auto
      [SC] ChangeServiceConfig ERFOLG

      C:\Windows\system32>net start trustedinstaller
      Windows Modules Installer wird gestartet.
      Windows Modules Installer wurde erfolgreich gestartet.

      C:\Windows\system32>sfc /scannow /offbootdir=d:\ /offwindir=d:\windows /OFFLOGFILE=c:\sfc_offline_for_d_winxpSP2x64_20191124_log.txt

      Der Windows-Ressourcenschutz konnte den Reparaturdienst nicht starten.

      C:\Windows\system32>sfc /scannow

      Systemsuche wird gestartet. Dieser Vorgang kann einige Zeit dauern.

      Überprüfungsphase der Systemsuche wird gestartet.
      Überprüfung 100 % abgeschlossen.

      Der Windows-Ressourcenschutz hat keine Integritätsverletzungen gefunden.

      C:\Windows\system32>

Schreibe einen Kommentar zu Günter Born Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht.