There are bunch of tutorials/instructions out there how to SFC-scan a Windows (Vista+) installation other than one booted, e.g.
Sfc.exe /ScanNow /OffBootDir=E:\ /OffWindir=D:\Windows /OfflogFile=E:\OffBoot.log
My problem is that the documentation is rather unclear on the meaning of /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
I understand OFFWINDIR, but what exactly is that OFFBOOTDIR supposed to point to? The drive where the BCD store is? Something else?
(There is a seemingly related q here in which the OP confused DISM with SFC. DISM and SFC don't do the same thing; I don't want to scan the image with DISM. I did that and it's fine. I'm really asking about SFC scanning the "fully extracted" files, so please no DISM answers.)
More concretely, I have two Win 10 installations, same build but different partitions/letter drives, and the BCD for them is on 3rd letter/partition. One of the Win 10 installation doesn't boot anymore, it's at the [in]famous black screen with movable mouse arrow but infinite spinning cursor (and the caps lock blinks every 10 seconds or so). I'm trying to SFC scan it from the healthy/working Win 10 installation.
I can scan the up-and-running Win 10 installation from within itself, no problem sfc /verifyonly or sfc /scannow or don't give any errors or trouble.
But pointing the OFFWINDIR to either the BCD drive or the "dead" Win 10 install drive, I got exactly the same error in the (two) logs (modulo the date), e.g.
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)
Found out by diffing the two logs. Since it's complaining about CRerooted, I suspect it's the offbootdir it doesn't like... (I see someone else encountered the same error, but with no real answer what that is about.) The drives mount fine otherwise and I can see the files.
The chkdsk for the "dead" (meaning ever-spinning) install drive only gives a few (mostly AppCrash) errors, no doubt caused by the forced power-off I had to use on it:
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.
I was able to use AppCrashView to load the crashed OS report (with /ReportsFolder and /ProfilesFolder pointing to the appropriate dirs on the "dead" Win10). It seems it's\WINDOWS\system32\sihost.exe which caused the appcrash (report) with error code 0x80270234. Actually, that was just the one that managed to hit the archive, the others were in the WER\ReportQueue, a whole bunch of them, as dwm cyclically crashed:
But that doesn't help much in figuring out why sfc refuses to run on the "dead" OS, when other tools seem ok with it.
Ok, so I've fixed the few disk errors with chkdsk /f at boot time. That didn't convince sfc to do its job though.
The most amusing thing is that I now fixed the underlying problem, so both Win 10 instances boot properly now... but sfc still didn't work to scan the offline installation, even after it was 100% ok & bootable.
The non-working installation had an incorrect HKLM/MountedDevices, which I fixed "offline" by loading the hive and changing the mapping. (I realized the self-mapping was not C: in the appcrash reports.) But even after doing this, the "offline" sfc still refuses to work (with the same error) even though after the change the installation boots ok, and I could run sfc /scannow from within it. (No errors were reported.)
So it seems to me the offline sfc scan is more theoretical than actually usable. I'm leaving this as an open question in case someone knows exactly what's going on with sfc offline.
