Windows Update services cannot be started (w10-64-1903)
So far
enabled "built in Admin account" and tried all items below (not necessarily in the order shown) in that context:
Troubleshooter, said it had found and fixed problems. The only one identified was getting BITS up and running again
ran DISM with "restorehealth" etc
ran SFC /scannow
attempted setting services
UsoSvc already running, no problem
Wuauserve disabled. Set to automatic. Started.
WaaSMedicSvc - disabled. Tried to set to automatic. Access denied.
Found refs to that happening when you try to DISABLE the service and that you can only do it with a 3rd party tool like Windows Update Blocker.
I do use a 3rd party tool - Winaerotweaker - which effectively disables windows updates whereever I want it to. But re-enabling them is as trivial as disabling them (remove 2 ticks) and that works across my client estate with Win 10 versions from 1511 to 1909 so I don't believe that it's the guilty party on this occasion.
Went to regedit
Waasmedic and Wuauserv both Start values set to 4, Reset to 2
on reboot or any attempt to restart services, those values reverted to 4 (disabled)
Changed ownwership on both keys from SYSTEM to Administrator, Reset start key. Same behaviour (reverts on reboot or attempt to run services
Downloaded windows10.0-kb4524569-x64
(latest service settings for 1903)
attempted to run multiple times before during and after the above fixes.
consistently failed to run with error 0x80070422
Am about to run 1903 setup from a usb stick but I'm doing all this remotely so I'm waiting for the user to buy a memory stick they can sacrifice to the cause. Meanwhile anyone got any other ideas?
Failing that, seen any good movies recently?
enabled "built in Admin account" and tried all items below (not necessarily in the order shown) in that context:
Troubleshooter, said it had found and fixed problems. The only one identified was getting BITS up and running again
ran DISM with "restorehealth" etc
ran SFC /scannow
attempted setting services
UsoSvc already running, no problem
Wuauserve disabled. Set to automatic. Started.
WaaSMedicSvc - disabled. Tried to set to automatic. Access denied.
Found refs to that happening when you try to DISABLE the service and that you can only do it with a 3rd party tool like Windows Update Blocker.
I do use a 3rd party tool - Winaerotweaker - which effectively disables windows updates whereever I want it to. But re-enabling them is as trivial as disabling them (remove 2 ticks) and that works across my client estate with Win 10 versions from 1511 to 1909 so I don't believe that it's the guilty party on this occasion.
Went to regedit
Waasmedic and Wuauserv both Start values set to 4, Reset to 2
on reboot or any attempt to restart services, those values reverted to 4 (disabled)
Changed ownwership on both keys from SYSTEM to Administrator, Reset start key. Same behaviour (reverts on reboot or attempt to run services
Downloaded windows10.0-kb4524569-x64
(latest service settings for 1903)
attempted to run multiple times before during and after the above fixes.
consistently failed to run with error 0x80070422
Am about to run 1903 setup from a usb stick but I'm doing all this remotely so I'm waiting for the user to buy a memory stick they can sacrifice to the cause. Meanwhile anyone got any other ideas?
Failing that, seen any good movies recently?
ASKER
Thanks for the response. Apologies for my own delay. I still don't receive email notifications from EE so it's a matter of chance as to when I'll remember to login and check for any responses to my open questions.
The first three dependencies are indeed running but I haven't tried reregistration. I'll be on site with the client later today or tomorrow and I'll report back. Not sure the last is relevant as I'm not trying to run an offline installer. The backstory may help.
This particular incident is actually in response to last week's story about the NSA revelation re the glitch in the Windoze crypto library (see
CVE-2020-0601) and the patches they've released to fix it. I downloaded about 5 different versions of the patch and set about installing them across a few dozen
individual workstations (owned by multiple business and private owners). About 75% worked from the offline installer. Of the 25% that failed, re-enabling their normal windows update services, allowing a full update, then disabling them again sorted the problem in all but 2 cases, one of which is this present case. On this occasion I didn't even try the offline installer because it was 6 months since we'd permitted any updates so my intention was to permit a full catchup.
Push to shove; we've got the latest version of Rollback installed on the problem device. Horizon boasts that it can protect us against even Microsoft's attack on the boot sector, and I haven't had a chance to test that claim yet. I suspect I shortly will. Hopefully, that'll roll it back, if necessary, to it's freshly built state, when Windows Update was still enabled. So I'll then be able to run the updates, take another baseline snapshot and only after that disable the updates. I could have done that to begin with but my real concern is to discover how or why this kind of problem is even possible with the OS and why it is so ludicrously difficult to diagnose.
The first three dependencies are indeed running but I haven't tried reregistration. I'll be on site with the client later today or tomorrow and I'll report back. Not sure the last is relevant as I'm not trying to run an offline installer. The backstory may help.
This particular incident is actually in response to last week's story about the NSA revelation re the glitch in the Windoze crypto library (see
CVE-2020-0601) and the patches they've released to fix it. I downloaded about 5 different versions of the patch and set about installing them across a few dozen
individual workstations (owned by multiple business and private owners). About 75% worked from the offline installer. Of the 25% that failed, re-enabling their normal windows update services, allowing a full update, then disabling them again sorted the problem in all but 2 cases, one of which is this present case. On this occasion I didn't even try the offline installer because it was 6 months since we'd permitted any updates so my intention was to permit a full catchup.
Push to shove; we've got the latest version of Rollback installed on the problem device. Horizon boasts that it can protect us against even Microsoft's attack on the boot sector, and I haven't had a chance to test that claim yet. I suspect I shortly will. Hopefully, that'll roll it back, if necessary, to it's freshly built state, when Windows Update was still enabled. So I'll then be able to run the updates, take another baseline snapshot and only after that disable the updates. I could have done that to begin with but my real concern is to discover how or why this kind of problem is even possible with the OS and why it is so ludicrously difficult to diagnose.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
- Remote Procedure Call (RPC) Service
- DCOM Server Process Launcher
- RPC Endpoint Mapper
Can you reregister WU service .dll files?
regsvr32.exe wuapi.dll
regsvr32.exe wuaueng.dll
regsvr32.exe wuaueng1.dll
regsvr32.exe wucltui.dll
regsvr32.exe wups.dll
regsvr32.exe wups2.dll
regsvr32.exe wuweb.dll
Also, it might be worth a try to delete C:\Windows\SoftwareDistrib