Why Does SFC Always Get Stuck On This One File?

Question

When I boot Windows the log shows then instead of the login screen it shows a black screen with a cursor. The same thing happens with safe mode.

When running Startup Repair the SrtTrail.txt says a recently serviced boot binary is corrupt. but it doesn't tell me which one!

Therefore, I am booting into the Windows Recovery Environment from an install USB to try to repair my system files.

My Windows drive is mounted as F:\ so I am running dism with:

dism.exe /Image:F:\ /Cleanup-Image /Restorehealth

Which seems to suggest that there is no corruption so I then run sfc with:

sfc /scannow /offbootdir=F:\ /offwindir=F:\Windows /offbootdir=F:\Windows\System32\LogFiles\sfc-1.txt

However, whenever I run that command, SFC fails with

Windows Resource Protection could not perform the requested operation.

and at the bottom of the log it says:

00001177 [SR] Verify complete
00001178 [SR] Verifying 1 components
00001179 [SR] Beginning Verify and Repair transaction
0000117a@2020/1/4:12:46:43.995 (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)
0000117b (F) c0000039 [Error,Facility=(system),Code=57 (0x0039)] #2775836# from Windows::Rtl::SystemImplementation::CSystemIsolationLayer_IRtlSystemIsolationLayerTearoff::OpenFilesystemDirectory(flags = 0, da = (FILE_GENERIC_READ|FILE_EXECUTE), dn = [l:7]'\??\C:\', sa = (FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE), oo = (FILE_DIRECTORY_FILE|FILE_SYNCHRONOUS_IO_NONALERT|FILE_OPEN_FOR_BACKUP_INTENT), dir = NULL, disp = (null))
0000117c (F) c0000039 [Error,Facility=(system),Code=57 (0x0039)] #2775835# from CFileInstaller::CommitChanges(...)
0000117d (F) c0000039 [Error,Facility=(system),Code=57 (0x0039)] #2775834# from PrimitiveInstaller::CCoordinator::FinalizeChanges(...)
0000117e Direct SIL provider: Number of files opened: 25318.
0000117f Direct SIL provider: Number of files opened: 4.
00000003 Servicing stack shim unable to mark handle 1e0 ('\Device\Ramdisk{d9b257fc-684e-4dcb-ab79-03cfa2f6b750}\Windows\temp\SSS_8f26c8f8fcc2d501010000005c032403\msdelta.dll') for delete-on-close, error STATUS_CANNOT_DELETE
00000004 Servicing stack shim unable to mark handle 198 ('\Device\Ramdisk{d9b257fc-684e-4dcb-ab79-03cfa2f6b750}\Windows\temp\SSS_8f26c8f8fcc2d501010000005c032403') for delete-on-close, error STATUS_DIRECTORY_NOT_EMPTY

I tried moving F:\Windows\System32\msdelta.dll to a different directory and re-running sfc but I still get the same error for the same file.

The same thing happens even after a reboot. It gets stuck on that same file even if it isn't in the System32 directory.

The error seems to be saying that it can't delete the file after it has finished with it rather than saying that there is anything wrong with it.

Is there anything I can do to avoid this?

The only option I can think of is to write a bat file that loops over all the files in System32 and calls sfc with the scanfile option instead.

EDIT: I ran sfc with the /scanfile option to check a single file and got the same message at the end of the log file:

    sfc /scanfile=F:\Windows\System32\dwm.exe /offbootdir=F:\ /offwindir=F:\Windows /offbootdir=F:\Windows\System32\LogFiles\sfc-1.txt

Gives

00000003 [SR] Verifying 1 components
00000004 [SR] Beginning Verify and Repair transaction
00000005 [SR] Verify complete
00000006 Direct SIL provider: Number of files opened: 22.
00000007 Direct SIL provider: Number of files opened: 4.
00000003 Servicing stack shim unable to mark handle 84 ('\Device\Ramdisk{d9b257fc-684e-4dcb-ab79-03cfa2f6b750}\Windows\temp\SSS_fbc9cb9692c3d50101000000f006f406\msdelta.dll') for delete-on-close, error STATUS_CANNOT_DELETE
00000004 Servicing stack shim unable to mark handle 194 ('\Device\Ramdisk{d9b257fc-684e-4dcb-ab79-03cfa2f6b750}\Windows\temp\SSS_fbc9cb9692c3d50101000000f006f406') for delete-on-close, error STATUS_DIRECTORY_NOT_EMPTY

Which makes me think that the reference to msdelta.dll is maybe not the problem here, although it is strange and confusing as to why it appears in the log every time.