Worauf bezieht sich „Offline-Startverzeichnis“ in der SFC-Option /OFFBOOTDIR?

Worauf bezieht sich „Offline-Startverzeichnis“ in der SFC-Option /OFFBOOTDIR?

Es gibt eine Menge Tutorials/Anleitungendort draußenSo scannen Sie eine andere Windows (Vista+)-Installation als die gebootete, mit SFC, z. B.

Sfc.exe /ScanNow /OffBootDir=E:\ /OffWindir=D:\Windows /OfflogFile=E:\OffBoot.log

Mein Problem besteht darin, dass in der Dokumentation die Bedeutung von nicht ganz klar ist /OffBootDir:

/OFFWINDIR     For offline repair, specify the location of the offline windows directory
/OFFBOOTDIR     For offline repair, specify the location of the offline boot directory

Ich verstehe OFFWINDIR, aber worauf genau OFFBOOTDIRsoll das verweisen? Auf das Laufwerk, auf dem sich der BCD-Speicher befindet? Auf etwas anderes?

(Es gibt eine scheinbarverwandte q hierin dem der OP DISM mit SFC verwechselt hat. DISM und SFCmach nicht das Gleiche; Ich möchte das Image nicht mit DISM scannen. Das habe ich gemacht und es ist kein Problem. Ich frage eigentlich nach SFC, das die „vollständig extrahierten“ Dateien scannt, also bitte keine DISM-Antworten.)


Genauer gesagt, ich habe zwei Win 10-Installationen, dieselbe Build, aber unterschiedliche Partitionen/Laufwerksbuchstaben, und der BCD für sie befindet sich auf dem 3. Buchstaben/der 3. Partition. Eine der Win 10-Installationen bootet nicht mehr, es ist der [berüchtigte] schwarze Bildschirm mit beweglichem Mauszeiger, aber unendlich drehendem Cursor (und die Feststelltaste blinkt etwa alle 10 Sekunden). Ich versuche, sie mit SFC von der fehlerfreien/funktionierenden Win 10-Installation aus zu scannen.

Ich kann die laufende Win 10-Installation problemlos von selbst scannen sfc /verifyonlyund sfc /scannowes treten keine Fehler oder Schwierigkeiten auf.

Aber wenn ich OFFWINDIRentweder auf das BCD-Laufwerk oder das "tote" Win 10-Installationslaufwerk verweise, erhalte ich in den (beiden) Protokollen genau den gleichen Fehler (modulo das Datum), z. B.

0000129a@2020/7/1:16:02:35.036 (F) onecore\base\wcp\sil\fs_rerooted.cpp(424): Error c0000039 [Error,Facility=(system),Code=57 (0x0039)] originated in function Windows::Rtl::SystemImplementation::CRerootedFileSystemProvider::SysCreateFile expression: (null)

Habe es durch Vergleichen der beiden Protokolle herausgefunden. Da es sich über beschwert CRerooted, vermute ich, dass es das ist, offbootdirwas es nicht mag ... (Ich verstehejemand anderes hatte denselben Fehler, aber keine wirkliche Antwort darauf, worum es geht.) Die Laufwerke werden ansonsten problemlos gemountet und ich kann die Dateien sehen.

Das chkdsk„tote“ (d. h. sich ständig drehende) Installationslaufwerk weist nur wenige Fehler (hauptsächlich AppCrash-Fehler) auf, die zweifellos durch das erzwungene Ausschalten verursacht wurden, das ich durchführen musste:

  62386 reparse records processed.
                                                                                Index entry Report.wer in index $I30 of file C801 is incorrect.
Index entry Report.wer in index $I30 of file C831 is incorrect.
Index entry Report.wer in index $I30 of file C8A1 is incorrect.
Index entry Report.wer in index $I30 of file C8BF is incorrect.
Index entry Report.wer in index $I30 of file C915 is incorrect.
Index entry Report.wer in index $I30 of file C9A3 is incorrect.
Index entry Report.wer in index $I30 of file C9B5 is incorrect.
Index entry Report.wer in index $I30 of file C9C3 is incorrect.
                                                                                Index entry AP1CC0~1.EXE in index $I30 of file 662D5 is incorrect.
Index entry AP1D30~1.EXE in index $I30 of file 662D5 is incorrect.
Index entry AP4032~1.EXE in index $I30 of file 662D5 is incorrect.
Index entry APA3A9~1.EXE in index $I30 of file 662D5 is incorrect.
Index entry APA768~1.EXE in index $I30 of file 662D5 is incorrect.
Index entry AppCrash_dwm.exe_602785ff1ad84b4251fd4d4d968a49205c4997_25529819_50b89d74-3097-4aa9-b867-7c9c3c5dae6a in index $I30 of file 662D5 is incorrect.
Index entry AppCrash_dwm.exe_602785ff1ad84b4251fd4d4d968a49205c4997_25529819_58d875dd-29ab-429e-ba1f-82d14fd237d5 in index $I30 of file 662D5 is incorrect.
Index entry AppCrash_dwm.exe_602785ff1ad84b4251fd4d4d968a49205c4997_25529819_e0e33150-ba5c-471f-98be-c25484e60dae in index $I30 of file 662D5 is incorrect.
Index entry AppCrash_LogonUI.exe_663467edba6d197a625e1e79c1e876af21ec6c_6f8885ad_29c4cfb1-f7d8-4751-819a-ed51573d6a5e in index $I30 of file 662D5 is incorrect.
Index entry AppCrash_LogonUI.exe_663467edba6d197a625e1e79c1e876af21ec6c_6f8885ad_37ed6e37-8e90-4d53-b676-414831b028a4 in index $I30 of file 662D5 is incorrect.
                                                                                Index entry AP29BE~1.EXE in index $I30 of file 662FC is incorrect.
Index entry AP2A31~1.EXE in index $I30 of file 662FC is incorrect.
Index entry AP4213~1.EXE in index $I30 of file 662FC is incorrect.
Index entry AP5D1D~1.EXE in index $I30 of file 662FC is incorrect.
Index entry AP6F64~1.EXE in index $I30 of file 662FC is incorrect.
Index entry AP8027~1.EXE in index $I30 of file 662FC is incorrect.
Index entry AP8B28~1.EXE in index $I30 of file 662FC is incorrect.
Index entry APB701~1.EXE in index $I30 of file 662FC is incorrect.
Index entry APD8D4~1.EXE in index $I30 of file 662FC is incorrect.
Index entry APD90D~1.EXE in index $I30 of file 662FC is incorrect.
Index entry AppCrash_dwm.exe_602785ff1ad84b4251fd4d4d968a49205c4997_25529819_3c6809aa-e39d-4112-80ed-d9c20f6429b4 in index $I30 of file 662FC is incorrect.
Index entry AppCrash_dwm.exe_602785ff1ad84b4251fd4d4d968a49205c4997_25529819_ebccbc17-b8e5-4ab9-a4f5-738a3378fdf7 in index $I30 of file 662FC is incorrect.
Index entry AppCrash_LogonUI.exe_663467edba6d197a625e1e79c1e876af21ec6c_6f8885ad_08a0074d-89ad-4ae3-a2fe-cc8d74833eb9 in index $I30 of file 662FC is incorrect.
Index entry AppCrash_LogonUI.exe_663467edba6d197a625e1e79c1e876af21ec6c_6f8885ad_195a3824-35fa-4eeb-90f5-cd80e543becf in index $I30 of file 662FC is incorrect.
Index entry AppCrash_LogonUI.exe_663467edba6d197a625e1e79c1e876af21ec6c_6f8885ad_1c50c522-08b8-460e-8f9e-e0d0d09202ac in index $I30 of file 662FC is incorrect.
Index entry AppCrash_LogonUI.exe_663467edba6d197a625e1e79c1e876af21ec6c_6f8885ad_74d589b1-3d92-49fe-bf0b-e6d62a4912b8 in index $I30 of file 662FC is incorrect.
Index entry AppCrash_LogonUI.exe_663467edba6d197a625e1e79c1e876af21ec6c_6f8885ad_8a604bac-dde8-4835-bfb4-c0006a6af03c in index $I30 of file 662FC is incorrect.
Index entry AppCrash_LogonUI.exe_663467edba6d197a625e1e79c1e876af21ec6c_6f8885ad_db10a313-935a-4127-b193-d9fa596ee322 in index $I30 of file 662FC is incorrect.
Index entry AppCrash_LogonUI.exe_663467edba6d197a625e1e79c1e876af21ec6c_6f8885ad_eccb09a4-0826-4648-a1ac-418df36f1328 in index $I30 of file 662FC is incorrect.
Index entry AppCrash_LogonUI.exe_663467edba6d197a625e1e79c1e876af21ec6c_6f8885ad_f1607dcd-f286-4ce4-abbe-a923d06cb11b in index $I30 of file 662FC is incorrect.
                                                                                                                                                                  662946 index entries processed.                                               

Ich konnte verwendenAppCrashViewum den Bericht zum abgestürzten Betriebssystem zu laden (mit /ReportsFolderund /ProfilesFoldermit Verweis auf die entsprechenden Verzeichnisse auf dem „toten“ Win10). Es scheint, dass es das ist, \WINDOWS\system32\sihost.exewas den App-Absturz (Bericht) mit dem Fehlercode verursacht hat 0x80270234. Tatsächlich war das nur das eine, das es geschafft hat, das Archiv zu erreichen, die anderen waren im WER\ReportQueue, eine ganze Menge davon, da dwm zyklisch abstürzte:

Bildbeschreibung hier eingeben

Das hilft aber nicht viel dabei, herauszufinden, warum sfces sich weigert, auf dem „toten“ Betriebssystem zu laufen, während andere Tools damit problemlos zurechtzukommen scheinen.


Ok, ich habe also die paar Festplattenfehler beim chkdsk /fBooten behoben. Das hat SFC allerdings nicht überzeugt, seine Arbeit zu erledigen.

Das Amüsanteste ist, dass ich jetzt das zugrunde liegende Problem behoben habe, sodass beide Win 10-Instanzen jetzt ordnungsgemäß booten ... aber sfcTrotzdemDas Scannen der Offline-Installation hat nicht funktioniert, obwohl sie 100 % in Ordnung und bootfähig war.

Die nicht funktionierende Installation hatte ein falsches HKLM/MountedDevices, das ich „offline“ behoben habe, indem ich den Hive geladen und die Zuordnung geändert habe. (Mir ist aufgefallen, dass die Selbstzuordnung in den Appcrash-Berichten nicht C: war.) Aber selbst danach weigert sich das „Offline“-SFC immer noch zu funktionieren (mit demselben Fehler), obwohl die Installation nach der Änderung ordnungsgemäß bootet und ich sie sfc /scannowvon innen ausführen konnte. (Es wurden keine Fehler gemeldet.)

Mir scheint also, dass der Offline-SFC-Scan eher theoretisch als tatsächlich nutzbar ist. Ich lasse dies als offene Frage stehen, falls jemand genau weiß, was mit SFC offline los ist.

verwandte Informationen