Software updates issue - access denied

We encountered this problem recently on a customer site. The customer uses ConfigMgr to patch their Windows 10 estate. They've not had any major issues for quite some time but then the January CU for Windows 10 v1909 (KB5009545) started to fail with the Access is denied error (0x80070005).

We could see the error in the UpdatesHandler.log file.

WSUS update (92c58401-7a51-4e9d-9457-ca1a93c3e3d9) installation result = 0x80070005, Reboot State = NoReboot

Update execution failed.

But what did that mean? Nothing had changed so why all of a sudden was access denied? What specifically was being denied access?

We found the answer in the CBS.log file. CBS refers to Component-Based Servicing. Some components might be installed or uninstalled during Windows updates, and CBS.log is a file that includes details of these components. This file logs detailed information from your most recent Windows installed updates, and thus it can be used for troubleshooting issues related to your updates.

This log file is located in %windir%\Logs\CBS\ folder. There were several errors like this repeating over and over

2022-02-08 19:32:05, Info                  DPX    DpxMoveFileExW failed, source: \\?\C:\Windows\SoftwareDistribution\Download\55d2d88ec6c8540e1de4d959136d1809\inst\_Windows10.0-KB5009545-x64.cab_\$dpx$.tmp\4f76f8be37b84846a53e298df591e679.tmp, destination: \\?\C:\Windows\SoftwareDistribution\Download\55d2d88ec6c8540e1de4d959136d1809\inst\_Windows10.0-KB5009545-x64.cab_\amd64_microsoft-windows-e..-unifiedwritefilter_31bf3856ad364e35_10.0.18362.449_none_f216a3681960d832\r\uwfservicingscr.scr, hr 0x80070005

We could see similar issues using Procmon

8:51:31.2419935 PM  TiWorker.exe  10516  SetRenameInformationFile C:\Windows\SoftwareDistribution\Download\7998dad7da209654d66a9b53acb8a555\inst\_Windows10.0-KB5010345-x64.cab_\$dpx$.tmp\8bdd9ac34e21374c8fe95160faa8a43e.tmp        ACCESS DENIED            ReplaceIfExists: True, FileName: C:\Windows\SoftwareDistribution\Download\7998dad7da209654d66a9b53acb8a555\inst\_Windows10.0-KB5010345-x64.cab_\x86_microsoft-windows-photoscreensaver_31bf3856ad364e35_10.0.18362.1316_none_1d493b2302fc0b6b\r\photoscreensaver.scr

This error referred to TiWorker.exe which is the TrustedInstaller process and suggested that it did not have Full Control or Full Access to all the folders or sub-folders within the directory named SoftwareDistribution (C:\Windows\SoftwareDistribution). This didn't make much sense as nothing had changed in the environment.

We noticed that all the files that were blocked had a .SCR extension. These were screensaver files that were being updated by the January CU. Then we discovered that there was a McAfee access protection rule in place to block access to .SCR files. 

The fix was then straightforward. We excluded the TiWorker.exe process from the Block all SCR rule and the updates started to install.

I hope this helps if you find yourself in a similar situation. CBS logs and Procmon are your friends 😀

Until next time........