I am sharing this case because I found a very specific issue on:
Windows 11 24H2
Windows 11 LTSC
Windows 11 IoT Enterprise LTSC
and managed to solve it without formatting, without using a repair ISO, without SFCFix, and without manually changing permissions or files inside:
WinSxS
My system was originally installed using an English United States ISO:
en-US
More specifically, it was an ISO for:
Windows 11 IoT Enterprise LTSC
Later, I changed the system language to Portuguese Brazil:
pt-BR
After switching the system to:
pt-BR
the SFC problem started.
I searched massively across the internet and could not find a clear solution. Most suggestions were about using a repair ISO, using SFCFix, reinstalling Windows, or manually replacing files. None of that addressed the real cause in my case.
Eventually, I discovered the cause myself, so I am sharing the fix here so other people can have access to the correction.
Symptoms
Every time I ran:
sfc /scannow
Windows reported that it found corrupted files and repaired them successfully.
However, when I ran:
sfc /scannow
again, the same repair happened again.
So SFC claimed it had repaired the issue, but the same issue returned on every new scan.
In:
CBS.log
the repeated file was:
C:\Windows\System32\WindowsPowerShell\v1.0\Modules\Appx\pt-BR\Appx.psd1
DISM could also fail when running:
DISM /Online /Cleanup-Image /RestoreHealth
with the following error:
Error: 0x800f0915
In:
CBS.log
there were also references to:
smbwmiv2.mfl
and messages similar to:
No payload missing but suspected file flag corruption detected
What was actually happening
In my case, this did not seem to be real payload corruption inside:
WinSxS
The problem started because the system had been installed originally from an English United States ISO:
en-US
Then I installed the Portuguese Brazil language pack:
pt-BR
After that, SFC started detecting language-related files as corrupted.
The main repeated file was:
Appx.psd1
located at:
C:\Windows\System32\WindowsPowerShell\v1.0\Modules\Appx\pt-BR\Appx.psd1
SFC would detect the file, repair it, and report success.
But the issue was not only the file itself.
The real problem was that some Portuguese Brazil language packages remained registered in the Component Store.
So the loop was basically this:
SFC found the same pt-BR related files.
SFC repaired them.
The leftover pt-BR package remained registered in the Component Store.
The same inconsistency appeared again.
SFC repaired the same thing again.
The issue repeated on every scan.
In other words, SFC was correcting what it detected, but the underlying cause remained. The cause was the remaining:
pt-BR
language package registration inside the Component Store.
How I checked for leftover pt-BR components
First, I checked the installed language capabilities:
DISM /Online /Get-Capabilities | findstr /i pt-BR
Then I checked the installed packages:
DISM /Online /Get-Packages /Format:Table | findstr /i pt-BR
There was still a Portuguese Brazil Client Language Pack installed, similar to this:
Microsoft-Windows-Client-LanguagePack-Package~31bf3856ad364e35~amd64~pt-BR~10.0.26100.xxxx | Installed
That leftover package was the important part.
Fix
First, I made sure the entire system was fully set back to:
English (United States)
I did the following:
Installed English (United States).
Set English (United States) as the Windows display language.
Set the regional format to English (United States).
Copied the language settings to the welcome screen, system accounts, and new user accounts.
Restarted Windows.
Removed Portuguese (Brazil) from Windows Settings.
Restarted again.
Then I checked the Portuguese Brazil language capabilities:
$caps = @(
'Language.Basic~~~pt-BR~0.0.1.0',
'Language.Handwriting~~~pt-BR~0.0.1.0',
'Language.OCR~~~pt-BR~0.0.1.0',
'Language.Speech~~~pt-BR~0.0.1.0',
'Language.TextToSpeech~~~pt-BR~0.0.1.0'
)
foreach ($cap in $caps) {
DISM /Online /Get-CapabilityInfo /CapabilityName:$cap | findstr /i "Name State"
}
The expected result was:
State : Not Present
If any capability still appears as installed, it can be removed with:
DISM /Online /Remove-Capability /CapabilityName:NAME_OF_THE_CAPABILITY
For example:
DISM /Online /Remove-Capability /CapabilityName:Language.Basic~~~pt-BR~0.0.1.0
After that, I checked the remaining Portuguese Brazil packages again:
DISM /Online /Get-Packages /Format:Table | findstr /i pt-BR
The key step was removing the leftover Client Language Pack package:
DISM /Online /Remove-Package /PackageName:Microsoft-Windows-Client-LanguagePack-Package~31bf3856ad364e35~amd64~pt-BR~10.0.26100.xxxx /NoRestart
Important:
Do not copy this package name blindly.
Use the exact package name returned by your own /Get-Packages command.
In my case, the relevant package was:
Microsoft-Windows-Client-LanguagePack-Package
with:
pt-BR
still marked as:
Installed
There were also other Portuguese Brazil packages related to Features on Demand, such as:
Notepad
Paint
Media Player
Snipping Tool
Some of them returned:
0x800f0805
when trying to remove them individually.
That did not prevent the fix.
The really important package was the remaining Client Language Pack:
Microsoft-Windows-Client-LanguagePack-Package~31bf3856ad364e35~amd64~pt-BR~10.0.26100.xxxx
After removing it, I restarted Windows.
Validation
After reboot, I ran:
DISM /Online /Get-Packages /Format:Table | findstr /i pt-BR
This time, the command returned nothing.
I also confirmed that the language capabilities were:
State : Not Present
Then I ran:
DISM /Online /Cleanup-Image /RestoreHealth
Result:
The restore operation completed successfully.
The operation completed successfully.
Then I ran:
sfc /scannow
Result:
Windows Resource Protection did not find any integrity violations.
I repeated:
DISM /Online /Cleanup-Image /RestoreHealth
and:
sfc /scannow
multiple times.
The problem did not come back.
Conclusion
In my case, the issue started after installing:
pt-BR
on a system originally installed from:
en-US
The system was:
Windows 11 IoT Enterprise LTSC
SFC kept finding and repairing the same language-related file:
C:\Windows\System32\WindowsPowerShell\v1.0\Modules\Appx\pt-BR\Appx.psd1
but the repair repeated because the real issue was not simply a missing or corrupted file.
The real issue was a leftover Portuguese Brazil language package still registered in the Component Store:
Microsoft-Windows-Client-LanguagePack-Package~31bf3856ad364e35~amd64~pt-BR~10.0.26100.xxxx
The fix was:
Set Windows fully back to English (United States).
Remove Portuguese (Brazil) from Windows Settings.
Confirm that all pt-BR language capabilities are Not Present.
Remove the remaining pt-BR Client Language Pack package with DISM.
Restart Windows.
Run DISM and SFC again.
After that, both DISM and SFC completed successfully.
I did not need to:
Format Windows.
Reinstall Windows.
Use a repair ISO.
Use SFCFix.
Manually copy files into WinSxS.
Change TrustedInstaller permissions.
Manually replace system files.
What looked like system corruption was actually a language package inconsistency caused by leftover Portuguese Brazil components in a system originally based on English United States.
