New
#11
@all - ok, reading up on the in-place fix. I did delete the unknown user I had listed above and it didn't cause any issues.
I've rerun all the dism variations in sequence although the dism.log says differently. I have posted the dism issues.
BTW, I do have wim images of my C drive and drive E since some of my develop apps such as viz studio, eclipse, sql server and the associated user profiles were directed there during install. This cuts down on the clutter on drive C for imaging purposes,
So below is a summary of what microsoft says is good, vs. what the logs say for dism. note: sfc no change though.
working on the logs for dism will post.C:\Windows\system32>dism /Online /Cleanup-Image /CheckHealth
Deployment Image Servicing and Management tool
Version: 10.0.19041.3636
Image Version: 10.0.19045.3930
No component store corruption detected.
The operation completed successfully.
C:\Windows\system32>dism /Online /Cleanup-Image /StartComponentCleanup
Deployment Image Servicing and Management tool
Version: 10.0.19041.3636
Image Version: 10.0.19045.3930
[=========== 20.0% ]
The operation completed successfully.
C:\Windows\system32>dism /Online /Cleanup-Image /RestoreHealth
Deployment Image Servicing and Management tool
Version: 10.0.19041.3636
Image Version: 10.0.19045.3930
[==========================100.0%==========================] The restore operation completed successfully.
The operation completed successfully.
- - - Updated - - -
Errors/warnings in dism.log. Interesting the first one is for windowPE since I had followed the procedure for winre.wim due to the KB# that required me to increase the recovery partition size.
- - - Updated - - -2024-01-15 08:45:43, Warning DISM DISM Provider Store: PID=17360 TID=17352 Failed to load the provider: C:\Users\swegm\AppData\Local\Temp\A1E24098-DEF1-4C1D-BD19-DF5C76463694\PEProvider.dll. - CDISMProviderStore::Internal_GetProvider(hr:0x8007007e)
2024-01-15 08:45:43, Info DISM DISM Provider Store: PID=17360 TID=17352 Failed to get and initialize the PE Provider. Continuing by assuming that it is not a WinPE image. - CDISMProviderStore::Final_OnConnect
2024-01-15 08:45:43, Info DISM DISM Provider Store: PID=17360 TID=17352 Finished initializing the Provider Map. - CDISMProviderStore::Final_OnConnect
2024-01-15 08:45:43, Info DISM Initialized Panther logging at C:\Windows\Logs\DISM\dism.log
2024-01-15 08:45:43, Info DISM Initialized Panther logging at C:\Windows\Logs\DISM\dism.log
2024-01-15 08:45:43, Info DISM DISM Manager: PID=16512 TID=11628 Image session successfully loaded from the temporary location: C:\Users\swegm\AppData\Local\Temp\A1E24098-DEF1-4C1D-BD19-DF5C76463694 - CDISMManager::CreateImageSession
2024-01-15 08:45:43, Info DISM DISM.EXE: Target image information: OS Version=10.0.19045.3930, Image architecture=amd64
2024-01-15 08:45:43, Info DISM DISM.EXE: Image session version: 10.0.19041.3636
2024-01-15 08:45:43, Info DISM DISM Provider Store: PID=17360 TID=17352 Getting the collection of providers from an image provider store type. - CDISMProviderStore::GetProviderCollection
2024-01-15 08:45:43, Info DISM DISM Provider Store: PID=17360 TID=17352 Connecting to the provider located at C:\Users\swegm\AppData\Local\Temp\A1E24098-DEF1-4C1D-BD19-DF5C76463694\CbsProvider.dll. - CDISMProviderStore::Internal_LoadProvider
2024-01-15 08:45:43, Info DISM DISM Provider Store: PID=17360 TID=17352 Encountered a servicing provider, performing additional servicing initializations. - CDISMProviderStore::Internal_LoadProvider
2024-01-15 08:45:43, Info CSI 00000001 Shim considered [l:126]'\??\C:\Windows\Servicing\amd64_microsoft-windows-servicingstack_31bf3856ad364e35_10.0.19041.3745_none_7ded3f327ca60a41\wcp.dll' : got STATUS_OBJECT_PATH_NOT_FOUND
2024-01-15 08:45:43, Info CSI 00000002 Shim considered [l:123]'\??\C:\Windows\WinSxS\amd64_microsoft-windows-servicingstack_31bf3856ad364e35_10.0.19041.3745_none_7ded3f327ca60a41\wcp.dll' : got STATUS_SUCCESS
2024-01-15 08:45:43, Info DISM DISM OS Provider: PID=17360 TID=17352 Determined System directory to be C:\Windows\System32 - CDISMOSServiceManager::get_SystemDirectory
2024-01-15 08:45:43, Info DISM DISM Package Manager: PID=17360 TID=17352 Finished initializing the CbsConUI Handler. - CCbsConUIHandler::Initialize
2024-01-15 08:45:43, Info CSI 00000001 Shim considered [l:126]'\??\C:\Windows\Servicing\amd64_microsoft-windows-servicingstack_31bf3856ad364e35_10.0.19041.3745_none_7ded3f327ca60a41\wcp.dll' : got STATUS_OBJECT_PATH_NOT_FOUND
2024-01-15 08:45:43, Info CSI 00000002 Shim considered [l:123]'\??\C:\Windows\WinSxS\amd64_microsoft-windows-servicingstack_31bf3856ad364e35_10.0.19041.3745_none_7ded3f327ca60a41\wcp.dll' : got STATUS_SUCCESS
2024-01-15 08:45:43, Info DISM DISM Package Manager: PID=17360 TID=17352 CBS is being initialized for online use. More information about CBS actions can be located at: %windir%\logs\cbs\cbs.log - CDISMPackageManager::Initialize
2024-01-15 08:45:43, Info DISM DISM Package Manager: PID=17360 TID=17352 Loaded servicing stack for online use only. - CDISMPackageManager::CreateCbsSession
CSI 00000001 Shim considered [l:126]'\??\C:\Windows\Servicing\amd64_microsoft-windows-servicingstack_31bf3856ad364e35_10.0.19041.3745_none_7ded3f327ca60a41\wcp.dll' : got STATUS_OBJECT_PATH_NOT_FOUND
2024-01-15 08:45:43, Info CSI 00000002 Shim considered [l:123]'\??\C:\Windows\WinSxS\amd64_microsoft-windows-servicingstack_31bf3856ad364e35_10.0.19041.3745_none_7ded3f327ca60a41\wcp.dll' : got STATUS_SUCCESS
For all the dism command line switches used, the most the dism.log files shows is the STATUS_OBJECT_PATH_NOT_FOUND, which is probably expected, since it checked the alternate path and found it. I'm not sure if "ccleaner" went into this temp directory and deleted everything there.....
As for the PE error, probably expected to, since I'm not running in a winPE environment.
Before, I get to much into the update inplace will this be a possiblity to fix my issues?
a). Run in a winpe environment since I got my recovery winpe.wim updated by the latest KB #, then exit to the command prompt and run the sfc and/or dism command from there?
b). As a last resort go and delete the dlls in syswow64 for the hash errors that sfc seems to be finding, and then rerun the dism command to fix the missing dlls by putting them back before rebooting and recheck to see if the hashes got fixed?
In the worst case, I do have a wim image to restore the whole partition should things not bootup after doing this. Of course, my wim image has all the sfc problems in the image, so that upon restore of the partition, I'll get them back.....to try again with the in place update steps.
As for the dual ownership of the start menu and other directories. I could copy the stuff in each one out to a temp directory, delete the directory name, and contents, run dism to fix the missing directory and ownership and then copy back what I saved off. If one directory works, then do each one, one-by-one then. I'm wondering if the dual ownerships are in the registry vs. what is on the disk as properties????
- - - Updated - - -
Heres a CBS.log entry that doesn't make sense
The reason it doesn't make sense is,CBS Deleting directory: \\?\C:\Windows\CbsTemp\31082427_1262413624\
2024-01-15 09:06:23, Info CBS Moving directory from \\?\C:\Windows\CbsTemp\31082427_1262413624\ to \\?\C:\Windows\CbsTemp\31082427_1262413624\{ADABC26D-2EFE-4FE2-8C2E-0D32D78C9881}
2024-01-15 09:06:23, Info CBS Failed to move \\?\C:\Windows\CbsTemp\31082427_1262413624\ to temp directory \\?\C:\Windows\CbsTemp\31082427_1262413624\{ADABC26D-2EFE-4FE2-8C2E-0D32D78C9881} [HRESULT = 0x80070020 - ERROR_SHARING_VIOLATION]
2024-01-15 09:06:23, Info CBS Failed moving directory: \\?\C:\Windows\CbsTemp\31082427_1262413624\ to temp, will delete in-place instead [HRESULT = 0x80070020 - ERROR_SHARING_VIOLATION]
2024-01-15 09:06:23, Info CBS Deletion of: \\?\C:\Windows\CbsTemp\31082427_1262413624\ successful
a). It first deletes the directory "then" tries to move it to {......} that doesn't exist since the directory was deleted already.
b). "then" due to a failure to move, it does an inplace delete which is successful. How is that? it was deleted already so how can it do "another" in place delete and be successful? Moreover, the {.....} must have not been important either.
So there may be an issue with the steps that MSoft is doing here.....
- - - Updated - - -
Here's my attempt to fix the hash problems. The bottom line it restored the deleted srm dll files from store, but when it did the hash check it still says they are bad. Now there is an adrclient.dll hash problem.
- - - Updated - - -Directory of C:\Windows\SysWOW64
12/06/2019 10:48 PM 279,040 srm.dll
11/15/2023 04:15 PM 949,760 srmclient.dll -< hash error
12/06/2019 11:01 PM 90,112 srmlib.dll
11/15/2023 04:15 PM 467,456 srmscan.dll <-- hash error
11/15/2023 04:15 PM 125,440 srmshell.dll <- hash error
11/15/2023 04:15 PM 194,048 srmstormod.dll -< hash error
12/06/2019 10:49 PM 66,048 srmtrace.dll
12/06/2019 10:50 PM 16,896 srm_ps.dll
8 File(s) 2,188,800 bytes
0 Dir(s) 429,174,521,856 bytes free
After taking ownership and deleting the hash error files without rebooting
dism restorehealth didn't given any errors about missing files.
sfc /scannow put the missing files back in which match the dates above.
The CBS.log still shows the dual ownership on the directories. Moreover, this missing dll files were resintalled
2024-01-15 10:45:14, Info CSI 00000267 [SR] Verifying 100 components
2024-01-15 10:45:14, Info CSI 00000268 [SR] Beginning Verify and Repair transaction
2024-01-15 10:45:15, Info CSI 00000269 [SR] Repairing file \??\C:\Windows\SysWOW64\\srmclient.dll from store
2024-01-15 10:45:15, Info CSI 0000026a [SR] Repairing file \??\C:\Windows\SysWOW64\\srmscan.dll from store
2024-01-15 10:45:15, Info CSI 0000026b [SR] Repairing file \??\C:\Windows\SysWOW64\\srmshell.dll from store
2024-01-15 10:45:15, Info CSI 0000026c [SR] Repairing file \??\C:\Windows\SysWOW64\\srmstormod.dll from store
2024-01-15 10:45:15, Info CSI 0000026d [SR] Verify complete
Check the hash errors against these files now in the CBS.log after the files were restored. However, even after it restored the missing files I still get hash error.
Moreover, the adrclient.dll now has hash problems.
2024-01-15 10:45:30, Info CSI 00000291 [SR] Repairing 2 components
2024-01-15 10:45:30, Info CSI 00000292 [SR] Beginning Verify and Repair transaction
2024-01-15 10:45:30, Info CSI 00000293 [SR] Repairing file \??\C:\Windows\SysWOW64\\srmclient.dll from store
2024-01-15 10:45:30, Info CSI 00000294 [SR] Repairing file \??\C:\Windows\SysWOW64\\srmscan.dll from store
2024-01-15 10:45:30, Info CSI 00000295 [SR] Repairing file \??\C:\Windows\SysWOW64\\srmshell.dll from store
2024-01-15 10:45:30, Info CSI 00000296 Hashes for file member [l:13]'adrclient.dll' do not match.
Expected: {l:32 ml:33 b:21f74f7dbee094b39b119fa23ffb57583a9584b314e80f1dbefe0bcaf7cf988c}.
Actual: {l:32 b:7e3ba04edc4ee6c37bb9c7133369abe7fee401613ed4a17416b734965e104b91}.
2024-01-15 10:45:30, Info CSI 00000297 [SR] Repairing file \??\C:\Windows\SysWOW64\\adrclient.dll from store
2024-01-15 10:45:30, Info CSI 00000298 [SR] Repairing file \??\C:\Windows\SysWOW64\\srmstormod.dll from store
2024-01-15 10:45:30, Info CSI 00000299 Hashes for file member [l:13]'srmclient.dll' do not match.
Expected: {l:32 ml:33 b:8a39328615df355fe486aaa532beb3c5934eb8ea6115230b8a3ebed27c566c38}.
Actual: {l:32 b:1b0b86b04dabba626b22a0a289186d219cb5290e9815f1bc69bc890b0920bf40}.
2024-01-15 10:45:30, Info CSI 0000029a [SR] Repairing file \??\C:\Windows\SysWOW64\\srmclient.dll from store
2024-01-15 10:45:30, Info CSI 0000029b Hashes for file member [l:11]'srmscan.dll' do not match.
Expected: {l:32 ml:33 b:f194dd2815d4654a4e7fe69de849d311aa0ece9bf38eee85c078f6c0a6725e54}.
Actual: {l:32 b:22cd02ec611d7ed212ee86f7ab90979408c405c353a22123b84420e4db93f501}.
2024-01-15 10:45:30, Info CSI 0000029c [SR] Repairing file \??\C:\Windows\SysWOW64\\srmscan.dll from store
2024-01-15 10:45:30, Info CSI 0000029d Hashes for file member [l:12]'srmshell.dll' do not match.
Expected: {l:32 ml:33 b:03ce95d3a39dd49a2f33c3305d4b1d83b12c6b67f24edb26ec22032a3391372f}.
Actual: {l:32 b:a965c973b72ff433f5c44239d8cd5c606986a07a9cde6c89d50fc9c919e65c2c}.
2024-01-15 10:45:30, Info CSI 0000029e [SR] Repairing file \??\C:\Windows\SysWOW64\\srmshell.dll from store
2024-01-15 10:45:30, Info CSI 0000029f Hashes for file member [l:13]'adrclient.dll' do not match.
Expected: {l:32 ml:33 b:7e3ba04edc4ee6c37bb9c7133369abe7fee401613ed4a17416b734965e104b91}.
Actual: {l:32 b:21f74f7dbee094b39b119fa23ffb57583a9584b314e80f1dbefe0bcaf7cf988c}.
2024-01-15 10:45:30, Info CSI 000002a0 [SR] Repairing file \??\C:\Windows\SysWOW64\\adrclient.dll from store
2024-01-15 10:45:30, Info CSI 000002a1 Hashes for file member [l:14]'srmstormod.dll' do not match.
Expected: {l:32 ml:33 b:3300568140cc4269662e0edd8b71c7ef4fbc92ba8e87c5293d6815ac1410dda0}.
Actual: {l:32 b:3cb523323b2a7d84df82908f7610ff8b9b949bfdf554a12bd98ee1e77d23a046}.
2024-01-15 10:45:30, Info CSI 000002a2 [SR] Repairing file \??\C:\Windows\SysWOW64\\srmstormod.dll from store
2024-01-15 10:45:30, Info CSI 000002a3 [SR] Repair complete
==============================================
Downloaded the win10 x64 iso from Msoft and followed the procedure to do an in place install and save my apps and settings.
After getting to the point that it was going to do a restart, it gave a popup saying the installation failed.....
- - - Updated - - -
===========================
Summary of trying to fix sfc /scannow
A). Used media creation tool to create a bootable USB and an iso file which includes the Jan 2024 updates.
B). Used the media creation tool iso file by mounting it and then running setup. There are two ways to update/fix drive C.
a). First try was to NOT delete partiton 3 which is the OS, and keep my apps and settings.
b). Second try was to delete partition 3 and do a clean install
C). used the usb install disk.
a). First try and second try was to install the OS without keeping the apps and settings (couldn't get this to work to keeps settings).
D). Downloaded an x64 iso file not using media creation tool and do a new install to partion 3. This was done using the steps to get around MSofts website change to prevent downloading the x64 bit iso using this forums instructions.
For each of the above steps, upon install, I ran sfc /scannow. For all cases, it says files are still corrupt. Upon checking the cbs.log file, it was determined that the directory overlap with dual ownership still exists for the startup and syswow64 directories as listed at above in this thread. However, in all cases, the hash problem with the Srm*.dll files as listed above appear to be fixed.
Conclusion: although sfc /scannow on another laptop of the same model and updated to the current Jan 2024 update doesn't have sfc corruption. It's is surmised that a windows10 Home will pass sfc /scannow and windows 10 pro will not when either of these two are installed on two different Dell 7347 laptop..
I will now go and restore my wim image of drive C which will have sfc issues and live with MSofts issues....
- - - Updated - - -
====================
Reinstalled my wim image of win10pro that has all my apps already installed and activated. Upon sfc /scannow, there is no change in the CBS.log
A). Mounted an export of iso from Msoft with current updates but not via media creation tool. Tried to do an in place install without deleting my apps and setups, When it gets to the 100% mark to restart, it pops up a message saying it failed to install.
I guess one way to try this is to put the iso on a flash or dvd disk and bootup from them to try the install without the win OS running.
Last edited by swegmike; 16 Jan 2024 at 09:57.
Quote