sfc and DISM both fail, windows 10 version 1803

You only need the latest one of a SSU..

You said earlier the SFC would not complete.  If it does not, then if you look at the listing, starting from the bottom up, you will see a "Cannot repair member file" or something similar...

Hi,

The findstr string doesn't seem to generate anything useful. It yields blocks of "verifying (x) components", "beginning verify and repair...", and "verify complete". If x=1, it tests 4-5 components and always completes. If x=100, it loops through many times, but the last loop never completes. The file just starts over again later with a new run, not even a space between entries.

The dism runs do contain error msgs related to servicing stacks. See the extracted msgs above from 14 Nov.

Not sure how to track between those error msgs and the installed updates. I have looked at the list of 1803 updates for the past few months and confirmed what can be uninstalled and what can't. Control panel shows 2 windows code kb files and 2 for .net framework that can be uninstalled. There are also 2 ssu updates that can not be backed out. Based on the windows catalog pgs, it looks like there are about 15 updates to be installed. Maybe some of those were completely overwritten by later updates, so the list appears to be longer.

thanks,

pete

When the SFC stops at 44%, you are correct, it finds an error or errors bad enough it will not continue.  You should be able to find what file caused it to stop by using the string below.  It will put a text file on your desktop and if you start at the bottom and work up you should find some errors which might mention "cannot repair member file".  If you knew what those were, it might help.

findstr /c:"[SR]" %windir%\Logs\CBS\CBS.log >"%userprofile%\Desktop\sfcdetails.txt"

The problems I saw in the other thread were Errors in the Dism Log.  My dism log has warnings.., most logs do but no errors.  There is a file named wpc.dll which seems to be involved.  It has, in the past, been involved in other situations.  It seems to be related to the TrustedInstaller and when that utility starts up the TiWorker, the wpc.dll gets involved.

You might be able to start the TrustedInstaller by itself but the TiWorker starts up during an upgrade session.

Then DISM fails to correct the situation for some reason.  Possibly it cannot find a provider for your specific packages it needs.  It may be looking for a servicing stack.

To check for servicing stacks and see if your current one is consistent with your install, you should be able to find what that log is and check the Settings-Update-view installed updates and the uninstall updates option on the upper left.. See if it is listed there.  These are steps we went through in the other thread which did not help.

I wish I could help but I am not getting any useful info regarding the situation...

Hi,

Thanks for the response. I think we have 2 separate problems.

My earlier comment on sfc & dism was not worded very well. What I meant was that the tools themselves appear to work correctly. They can be started and run until they find an error, then clean up and quit. dism with /analyzecomponentstore or /checkhealth both complete. With /scanhealth or /restorehealth, they both fail at the same % complete. So my guess is that they find problems with the current installation data that they can't repair, and quit.

The failures installing 1903 seem to be a result of a problem between the Intel graphics processor, win10 versions 1809 & forward, and the i7 processors in the g510. Msoft has tried to initiate updates to 1903 since early Oct, sometimes several times  day. I have tried several times to update using several methods. All of these have failed.

Since I can't go to 1903, an install of the latest build doesn't seem like a fix for the problems encountered by dism. That lead me to the question of whether I can uninstall the updates back to about Aug, and reinstall them. That may be prior to when the problem started.

Also, I forgot to answer your earlier question in the previous post. The dism log does have the statement

2019-11-14 09:09:18, Warning               DISM   DISM OS Provider: PID=5132 TID=7632 Unable to set the DLL search path to the servicing stack folder. C:\Windows may not point to a valid Windows folder. - CDISMOSServiceManager::Final_OnConnect

but then it appears to find a workaround and continue.

2019-11-14 09:09:19, Info                  DISM   DISM Provider Store: PID=5132 TID=7632 Encountered a servicing provider, performing additional servicing initializations. - CDISMProviderStore::Internal_LoadProvide

Will take a look at your link above.

thanks again,

pete

I am a little confused.  You state SFC and DISM are working normally but then you say it stops at 44%.  The normal process is to then run DISM to /restorehealth for the system.  It doesn't sound like you have run DISM..

In the other thread, we believe that refreshing the binaries in at least one of those two folders, DISM or Downlevel is what allowed 1903 to install.  1909 is not a separate build upgrade but installs a couple of updates during that upgrade process..

I cannot do much more unless you want to supply a setupact.log in .zip format on OneDrive or some other hosting service.

If you want to go to the linked site and download and run the setupdiag utility and paste the resulting listing.

https://docs.microsoft.com/en-us/windows/deployment/upgrade/setupdiag