[SOLVED] Create "safe" test for SFC?

Twincam

Twincam

Member
Joined
Dec 4, 2014
Posts
15
Location
Cambridge UK
I am in the process of creating an automated batch file to run sfc [first in verify mode, then fix mode if error detected]. However, I have no current issues with any of the machines I have access to. Can anyone advise a "safe" method of creating a problem that sfc will resolve. I guess it would be a system file that I should delete. Which one would be a suitable and "safe" candidate for testing?

I know this, perhaps, sounds nuts but I'd rather be able to test ahead of a genuine problem, and in a controlled a manner. I have a 64-Bit "Windows 10" virtual machine for testing but my "live" machines are both running 64-Bit "Windows 11".

I wasn't sure which thread to post this in so my apologies if I've selected the wrong one! Thanks.
 
I would load the COMPONENTS hive on your test machine, it should be able in the %systemroot%\System32\config directory and then load it into RegEdit. Once it had loaded, then check under \DerivedData\Components and take note of a random component; most of them should have a proper name i.e. not just random numbers. Now, once you've noted down your component, go to the %systemroot%\WinSxS\<component name> and then delete a couple of files in that directory. Afterwards, run SFC and see if it detects any problems.
 
Thanks both. I tried the @x BlueRobot suggestion first and it didn't work. The result was that I "broke" sfc. The message “Windows Resource Protection could not perform the requested operation.” was returned. Perhaps I chose a "bad" component, so I will try again and post back afterwards. That might take some time because of "real life" getting in the way!

Corday said:
The scanfile option would be a good location so at least you're not messing with the entire OS.
Click to expand...

@Corday Where do I look for the "scanfile" location you mentioned? Thanks.
 
Just a word of caution, don't delete any components which have "servicing" in their name otherwise you may break SFC, otherwise if it fails again then please attach your CBS logs and I'll have a look at why it is failing.
 
Thanks guys! Referring to the link posted in #5 [above] this is what I did:

01 - Booted my "test" VM from an ISO [offline] image
02 - Deleted "write.exe" from the VM's "Windows" folder
03 - Booted the VM normally
04 - Tested and fixed my batch file

The original problem [and question] arose because sfc does not return %errorlevel% codes, so I had to use statements like these below to interpret the results via a "temporary" file

sfc /VERIFYONLY > %Temp%\%~n0-sfc-ver.txt
find "Windows Resource Protection did not find any integrity violations" %Temp%\%~n0-sfc-ver.txt >nul

They allow me to check whether I got a good result or not [by checking the %errorlevel% returned by "find"]. I am then able to trigger a "sfc /SCANNOW" code block [using the same method to check that result] if necessary.

All great, ta. And I now know that "write.exe" is a "safe" file to delete in order to force an error for test purposes. (y)
 
I'm glad you managed to find a suitable file to test with. It would have been better if they designed SFC so it returned an error code like DISM does.
 
x BlueRobot said:
I'm glad you managed to find a suitable file to test with. It would have been better if they designed SFC so it returned an error code like DISM does.
Click to expand...
Absolutely agree!

For the record my #4 post broke everything. I tried everything here [apart from "Method 5"] to fix it [and partly to familiarise myself with bits of Windows I did not know well] and it was a "no go" - even after I had restored the 2 component files I deleted; SFC simply would not run! I keep offine backups of the VM, so not a real problem.
 
x BlueRobot said:
Interesting, do you remember which component you deleted?
Click to expand...
I do. It was "amd64_microsoft-windows-c..-disposableclientvm_31bf3856ad364e35_10.0.19041.985_none_c3639a9e3ab1a351" and I deleted the following two files from its folder [located in WinSxS]:

WindowsSandbox.exe
WindowsSandboxClient.exe

I also recall it was not straightforward to delete them. I think I had to "Take Ownership" [which I probably did via their containing "folder"]. The last bit is difficult to confirm now as I restored the VM after sfc failed.
 
Thanks, and you would have to take ownership since those files are all owned by the TrustedInstaller. I've marked this thread as solved for you now too.
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top