sfc and DISM both fail, windows 10 version 1803

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

Hi,

On the other thread, it looked like there was some question as to what had fixed the problem - maybe the upgrade to 1909. Here, sfc and dism seem to be working. Hadn't run sfc for a few days; today it got to 44% again with no errors, then

2019-11-24 15:39:00, Error                 CSI    000028ab (F) c000a2a7 [Error,Facility=(system),Code=41639 (0xa2a7)] #36210529# from Windows::Rtl::SystemImplementation::DirectFileSystemProvider::SysReadFile(h = a18 ('\Device\HarddiskVolume5\Windows\WinSxS\amd64_microsoft-windows-n..orkconnectionbroker_31bf3856ad364e35_10.0.17134.1_none_422fdc892e0c33b3\ncbservice.dll'), evt = 0, apcr = NULL, apcc = NULL, iosb = @0x296af7b4f0, data = {l:0 b:}, byteoffset = 0, key = (null))

[gle=0xd000a2a7]

2019-11-24 15:39:00, Error                 CSI    000028ac@2019/11/24:20:39:00.847 (F) onecore\base\wcp\sil\ntsystem.cpp(3533): Error c000a2a7 [Error,Facility=(system),Code=41639 (0xa2a7)] originated in function Windows::Rtl::SystemImplementation::DirectFileSystemProvider::SysReadFile expression: (null)

[gle=0x80004005]

So is this a problem with the integrity of the installed s/w (consistent results of corruption in compressed file's resource table), not with the diagnostics s/w?

pete vh

Did you check the other thread?

Does your DISM log have a line like Failed to bind the online servicing stack in the listing..?

If you have the same situation as the other thread, it was solved..  You might ask that poster..