WSUS 3 Unpredictable Client Update Failure Errors 0×80190193 0×80244018
This one pops up all over the web. Not sure if post XP SP3 updates as cause. WSUS 3 XP clients fail to update after a certain point. Note this is not consistent or predictable (e.g. based on service packs applied) but now affects a significant number of our systems.
Same error appears in the WSUS client diagnostic. Have tried using IP only. Have checked no proxying by accident. Have done the re-register dlls. Have cleaned out the SoftwareDistribution folder. Have reinstalled WSUS3 client software c/o microsoft package. All to no avail.
Here is the classic slice of client update log:
2008-10-16 13:43:10:486 1524 1f4c AU #############
2008-10-16 13:43:10:486 1524 1f4c AU ## START ## AU: Search for updates
2008-10-16 13:43:10:486 1524 1f4c AU #########
2008-10-16 13:43:10:486 1524 1f4c AU <<## SUBMITTED ## AU: Search for updates [CallId = {A581B5CE-2066-41B7-83D6-C8AB96566C50}]
2008-10-16 13:43:10:486 1524 1958 Agent *************
2008-10-16 13:43:10:486 1524 1958 Agent ** START ** Agent: Finding updates [CallerId = AutomaticUpdates]
2008-10-16 13:43:10:486 1524 1958 Agent *********
2008-10-16 13:43:10:486 1524 1958 Agent * Online = Yes; Ignore download priority = No
2008-10-16 13:43:10:486 1524 1958 Agent * Criteria = "IsHidden=0 and IsInstalled=0 and DeploymentAction='Installation' and IsAssigned=1 or IsHidden=0 and IsPresent=1 and DeploymentAction='Uninstallation' and IsAssigned=1 or IsHidden=0 and IsInstalled=1 and DeploymentAction='Installation' and IsAssigned=1 and RebootRequired=1 or IsHidden=0 and IsInstalled=0 and DeploymentAction='Uninstallation' and IsAssigned=1 and RebootRequired=1"
2008-10-16 13:43:10:486 1524 1958 Agent * ServiceID = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}
2008-10-16 13:43:10:580 1524 1958 Misc WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x80190193
2008-10-16 13:43:10:580 1524 1958 Misc WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x80190193
2008-10-16 13:43:10:627 1524 1958 Misc WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x80190193
2008-10-16 13:43:10:627 1524 1958 Misc WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x80190193
2008-10-16 13:43:10:658 1524 1958 Misc WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x80190193
2008-10-16 13:43:10:658 1524 1958 Misc WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x80190193
2008-10-16 13:43:10:674 1524 1958 Misc WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x80190193
2008-10-16 13:43:10:674 1524 1958 Misc WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x80190193
2008-10-16 13:43:10:674 1524 1958 Misc WARNING: DownloadFileInternal failed for http://infowsus.otago.ac.nz/selfupdate/wuident.cab: error 0x80190193
2008-10-16 13:43:10:674 1524 1958 Setup FATAL: IsUpdateRequired failed with error 0x80244018
2008-10-16 13:43:10:674 1524 1958 Setup WARNING: SelfUpdate: Default Service: IsUpdateRequired failed: 0x80244018
2008-10-16 13:43:10:674 1524 1958 Setup WARNING: SelfUpdate: Default Service: IsUpdateRequired failed, error = 0x80244018
2008-10-16 13:43:10:674 1524 1958 Agent * WARNING: Skipping scan, self-update check returned 0x80244018
2008-10-16 13:43:10:674 1524 1958 Agent * WARNING: Exit code = 0x80244018
2008-10-16 13:43:10:674 1524 1958 Agent *********
2008-10-16 13:43:10:674 1524 1958 Agent ** END ** Agent: Finding updates [CallerId = AutomaticUpdates]
2008-10-16 13:43:10:674 1524 1958 Agent *************
2008-10-16 13:43:10:674 1524 1958 Agent WARNING: WU client failed Searching for update with error 0x80244018
2008-10-16 13:43:10:674 1524 d1c AU >>## RESUMED ## AU: Search for updates [CallId = {A581B5CE-2066-41B7-83D6-C8AB96566C50}]
2008-10-16 13:43:10:674 1524 d1c AU # WARNING: Search callback failed, result = 0x80244018
2008-10-16 13:43:10:674 1524 d1c AU # WARNING: Failed to find updates with error code 80244018
2008-10-16 13:43:10:674 1524 d1c AU #########
2008-10-16 13:43:10:674 1524 d1c AU ## END ## AU: Search for updates [CallId = {A581B5CE-2066-41B7-83D6-C8AB96566C50}]
2008-10-16 13:43:10:674 1524 d1c AU #############
2008-10-16 13:43:10:674 1524 d1c AU AU setting next detection timeout to 2008-10-16 05:43:10
2008-10-16 13:43:10:674 1524 d1c AU Setting AU scheduled install time to 2008-10-16 16:00:00
2008-10-16 13:43:15:486 1524 1958 Report REPORT EVENT: {2C8F136B-6CFA-46FD-AAC7-7C096713A864} 2008-10-16 13:43:10:674+1300 1 148 101 {D67661EB-2423-451D-BF5D-13199E37DF28} 0 80244018 SelfUpdate Failure Software Synchronization Windows Update Client failed to detect with error 0x80244018.
Software/Hardware used:
Software/Hardware used:
ASKED:
October 21, 2008 11:10 PM
UPDATED:
November 19, 2008 4:17 AM
Answer Wiki:
I've noticed that in the past few months, quite a few machines would stop updating. Reviewing the WindowsUpdate.Log file showed that the client detected updates, but would never notify the user nor apply the updates. I'm pretty sure it is a specific update that is causing the problem as almost every new machine we build gets "hung".
The solution I've found is to clear the SoftwareDistribution folder AND the registry.
Here's a script that I have to automate things:
@echo off
net stop wuauserv
REG DELETE "HKLMSoftwareMicrosoftWindowsCurrentVersionWindowsUpdate" /va /f
del /q/s c:windowssoftwaredistribution
net start wuauserv
wuauclt.exe /resetauthorization /detectnow
It generally takes an additional "wuauclt /detectnow" to really get things back to work, but only if I'm in a hurry to get the machine up-to-date.
Give it a try and see if it works for you.
To see all answers submitted to the Answer Wiki: View Answer History.
Yes this is one of the roughly 4 standard answers which include things like reinstalling the wsus 3.0 client (or optionally installing the wsus 2.0 client and having it autoupdate itself).
No – it and the other solutions didn’t work or did not work consistently (i.e. for more than one system). This method worked on one out of 15 failing machines.
We did notice one machine that was failing worked when we changed its IP address.
To add to the confusion we are not sure if it is the server or the client.
Changing IP address made updates happen. Reverting to the previous address stopped them again. No other changes to machine. Both IP addresses should be valid. Most odd.
Well we’ve made some progress in the what, if not why or how. Note we don’t run the ADS at our site, being a department in a division, although we do have administrative access and delegation.
We have now worked out that the clients fail when members of the domain. We do know that the domain supplies an auto-proxy configuration. Which we [believe we] do not participate in and have autoconfiguration of the proxy (for IE anyway) turned off. Note that yes we can access the selfupdate and simpleauth pages through IE without any authentication or use of a proxy. We also noted that some of our machines are reported on the WSUS MMC control as using the proxy they have set up.
So… we now know the following (and it is consistent and repeatable):
member of domain with odd IP = NO updates
member of domain with good IP = NO updates
member of workgroup with *any* IP = updates
Which is kind of nice as it implies not a serious internal problem with the clients or the WSUS server.
The WSUS client diag says no proxy & proxycfg says winhttp has direct access, and the IP addresses that both work and fail are in the same subnet so any filtering by their proxy (if it is being used) is more sophisticated than either we or they know.
So – can we verify or check proxy usage any other way?
Pter
I am adding this to the discussion as it isn’t an answer but a fix for us.
We set the proxy via proxycfg, and anything will do for the proxy name, but importantly put in a bypass for the local network. e.g.
proxycfg -p noproxyatall “*.our.domain,123.210.*,127.0.0.1,<local>”
This has overridden whatever is being pushed onto us from the domain and updates are now happening. So there’s obviously nothing wrong with client OR server. However as to why this fixes it and no proxy was reported by proxycfg when we set it to -d, which you’d expect if one was being set, we don’t yet know. But at least we can get on without worrying about updates.