Windows Update: Error: -1073741819. HRESULT: -2147024894. Could not find file…

[doug]

Andy – Can you confirm the exact error message that you’re receiving, in its entirety?

It’s hard to say if NIC teaming would cause this or not, though I wouldn’t expect it to cause a problem, in general. However, anything is possible, and perhaps it depends on the exact configuration of the team. Are you seeing this only on servers with NIC teaming? Is it occurring on *all* servers with NIC teaming? Is it occurring on the VMs or the actual host machines or both? Are they all producing the *exact* same error message? (note both the error number as well as the HRESULT number because the same HRESULT can be paired with different error numbers)

Does psexec and/or paexec work *without* BatchPatch? Are you able to simply use psexec/paexec at the command line from the computer that runs BatchPatch to one of these problematic hosts? As a test you could try something simple in the CMD window such as:

psexec \targetComputer IPCONFIG

paexec \targetComputer IPCONFIG

[andydicken]

All Messages

Thu-09:06:34> Windows Update: Error: -1073741819. HRESULT: -2147024894. Could not find file ‘\xxxC$Program FilesBatchPatchBatchPatchTempResult.log’.

Thu-09:06:28> Windows Update: Executing BatchPatchRemoteAgent.exe…

Thu-09:06:28> Windows Update: Attempting to initiate Windows Update (Action: Search for updates. Server selection: Default / Managed) …

Thu-09:06:28> Windows Update: Establishing connection…

Thu-09:06:28> Windows Update: Initializing…

Thu-09:06:28> Windows Update: Queued…

The NIC teaming turns out to be a red herring. I have tried on some other hosts in a different domain with what is supposed to be an identical setup (including teaming) and they work fine. Perhaps some group policy is at play – but what could cause this behaviour?

Other files appear to be created and removed correctly in the working folder during a search.

Both psexec and paexec work fine with a test using ipconfig.

[andydicken]

Ok I have got it working, but am still at a loss as to why the error appears as it does.

I changed to a different WSUS server (which is 2012r2 as opposed to 2008r2), and it’s working.

Replicated by changing back, the same error comes back, then changed forward again and all OK.

The 2008r2 WSUS server is working fine for hundreds of clients, and indeed this client, if the traditional GUI is used on that machine…

Could there be something in the windowsupdate.log (special character or such like) that is preventing the file being created properly, when it connects to the older WSUS server?

[doug]

Andy – I’m a bit confused by what you’ve written. I’d like to make sure I understand everything clearly before proceeding. Please correct/clarify anything below that is not accurate.

1. You were running BatchPatch on a 2008R2 machine. BatchPatch would work successfully when targeting hundreds of machines, but a couple/few specific 2012R2 Hyper-V-enabled target machines were giving you this error:

Windows Update: Error: -1073741819. HRESULT: -2147024894. Could not find file '\xxxC$Program FilesBatchPatchBatchPatchTempResult.log'

2. You tried a number of different things mentioned in your previous posting such as paexec and psexec v1.98 etc, but none of those things fixed the issue.

3. You then launched BatchPatch on a 2012R2 machine (instead of the 2008R2 machine that was having a problem with a few targets), and everything seems to work fine on the 2012R2 machine against ALL target computers.

I don’t understand what you meant when you said “The 2008r2 WSUS server is working fine for hundreds of clients, and indeed this client, if the traditional GUI is used on that machine…” What is “this client,” and what is “the traditional GUI” and what is “that machine”? These references are ambiguous. I thought you said that the 2008R2 computer is the one that was having problems with certain Hyper-V targets. Now you’re saying it’s working fine?

Also, while I can say definitively that the issue is *not* related to the WindowsUpdate.log file, I’m also unsure what you mean when you say “when it connects to the older WSUS server?” What is “it?” And why is “it” connecting to the older WSUS server? I thought you were running BatchPatch console on your WSUS server? And so your WSUS server is not a target computer but is rather the console/source computer that would be establishing connections with all of your target computers.

Please note, I fear that even with your clarifications to the above questions I will still not be able to provide you with a useful answer as to what is causing the problem. Overall, this issue has only occurred for a *very* small number of BatchPatch users on an even smaller number of target computers. We have never been able to reproduce it. I don’t believe the issue is related to any type of configuration problem or group policy problem. Rather, I tend to think that this issue would be more accurately classified as a sort-of nondeterministic bug of some kind.

-Doug

[andydicken]

Hi Doug,

Thanks for your reply and sorry for the ambiguity!

1. For the purposes of this test, there is one client machine which I want to update (let’s call it A), and a choice of two WSUS servers (B and C respectively).

2. The ‘client’ machine A is 2012r2, one of the WSUS servers (B) is 2012r2, the other (C) is 2008 sp2 (not 2008r2, my mistake earlier).

3. I can reproduce the problem running BP directly on the client (A) as admin, or from ‘some other’ machine (D or whatever) against A just the same.

4. When I use the registry to change the configured WSUS server that A points to, I reproduce the problem.

5. When A is configured to point to B (2012r2 WSUS), everything is OK

6. When A is configured to point to C (2008 sp2 WSUS), the error occurs.

7. NB Both WSUS servers (B and C) are working fine and servicing lots of clients in general.

Hope this helps. Let me know if you would like me to forward any other logs etc.

Thanks,

Andy

[doug]

I am having this problem on certain 2012r2 servers (which are running the Hyper-V role). The only difference I can think of with these is that they have nic teaming. What I have tried:

* Using paexec, and the 1.98 version of psexec (no dice)

* Running as the local administrator user on the local box

* Turning off UAC & rebooting

* Using IP instead of hostname

* Using fully qualified domain name

* Turning off firewall

* My user is a domain admin and (enterprise admin)

* Tried stopping wuauserv, deleting Software Distribution, and restarting service for good measure

* Ensuring the psexesvc service has been deleted

Could NIC teaming cause a problem?

[doug]

This is very interesting and peculiar. I’m going to send you an email so that we can converse bit more easily.

-Doug

[doug]

After examining the WindowsUpdate.log we found this line:

COMAPI WARNING: ISusInternal::GetEulaText failed, hr=80240033

It turned out the issue was with a particular Silverlight update on the 2008 SP2 WSUS. Andy was able to remove the approval for the Silverlight update, then run:

WSUSUTIL RESET

And then rerun the approval rule. This fixed the issue.

-Doug

[jjlandstrom]

I have the same issue of a couple of 2012 R2 systems.

Do you remember the versions of Silverlight?

Do I understand correctly that Silverlight update was set not approved. Patches were done and then the Silverlight patch was approved and then it was able to patch.

Thanks,

Jason

[doug]

Jason – When you say you have the same issue, are you sure? Have you examined the Windows Update log file (C:WindowsWindowsUpdate.log) on the target computer? If the WindowsUpdate.log file does not contain the following error, then I don’t know that you are dealing with the same issue:

COMAPI WARNING: ISusInternal::GetEulaText failed, hr=80240033

In Andy’s case, the particular update had been approved, but there had been some type of corruption in the eulatext of the update such that the target computers could not process it properly. 99.9% of Windows Update do not have a EULA. Typically only Silverlight, IE, and a few other updates would ever have a EULA in the first place. In order to resolve the issue he *removed* the update’s approval in WSUS. Then he ran the WSUSUtil.exe RESET command in order to clean up the WSUS content, which presumably deleted the problematic update from the WSUS server. Then when he re-approved it, the update would have been re-downloaded from Microsoft to the WSUS, but this time with no corruption in the update’s metadata or EULA text etc. If in your environment the update has already been downloaded to target computers, I could imagine that there could be an additional step involved to have the target/client computers purge the update from their cache too. However, this is just a guess. It might not be necessary.

If you are truly having this issue where the EULA text has somehow been corrupted in such a way that it’s causing this specific error, there might be other ways to address/fix. You might also be able to simply hide the update using BatchPatch, or you might uncheck the ‘Auto-accept EULAs during update installation, if required’ box in BP under ‘Tools > Settings > Windows Update’

Please reach out to us via email if we need to troubleshoot this further or examine logs etc.

Thanks,

Doug

[jjlandstrom]

I get this on a few 2012R2 systems.

Wed-00:10:46> Windows Update: Error: -1073741819. HRESULT: -2147024894. Could not find file ‘\c0oms02pC$Program FilesBatchPatchBatchPatchTempResult.log’.

2015-08-04 23:35:58:922 780 698 Agent * Found 2 updates and 74 categories in search; evaluated appl. rules of 422 out of 586 deployed entities

2015-08-04 23:35:58:922 780 698 Agent Reporting status event with 4 installable, 2 installed, 0 installed pending, 0 failed and 0 downloaded updates

2015-08-04 23:35:58:922 780 698 Agent *********

2015-08-04 23:35:58:922 780 698 Agent ** END ** Agent: Finding updates [CallerId = BatchPatch Id = 3]

2015-08-04 23:35:58:922 780 698 Agent *************

2015-08-04 23:35:58:922 780 698 IdleTmr WU operation (CSearchCall::Init ID 3, operation # 61) stopped; does use network; is not at background priority

2015-08-04 23:35:58:922 780 698 IdleTmr Decremented idle timer priority operation counter to 0

2015-08-04 23:35:58:922 1184 90c COMAPI >>– RESUMED — COMAPI: Search [ClientId = BatchPatch]

2015-08-04 23:35:58:934 1184 90c COMAPI – Updates found = 2

2015-08-04 23:35:58:934 1184 90c COMAPI

---

2015-08-04 23:35:58:934 1184 90c COMAPI — END — COMAPI: Search [ClientId = BatchPatch]

2015-08-04 23:35:58:934 1184 90c COMAPI

---

2015-08-04 23:35:58:934 1184 318 COMAPI WARNING: ISusInternal::GetEulaText failed, hr=80240033

2015-08-04 23:36:03:659 780 b98 Report REPORT EVENT: {705A590A-60C0-4499-88A4-86CAFEC5D67D} 2015-08-04 23:35:58:922-0500 1 147 [AGENT_DETECTION_FINISHED] 101 {00000000-0000-0000-0000-000000000000} 0 0 BatchPatch Success Software Synchronization Windows Update Client successfully detected 2 updates.

2015-08-04 23:36:03:659 780 b98 Report REPORT EVENT: {E51D0667-9166-4AA9-8B41-A5761632A8B3} 2015-08-04 23:35:58:922-0500 1 156 [AGENT_STATUS_30] 101 {00000000-0000-0000-0000-000000000000} 0 0 BatchPatch Success Pre-Deployment Check Reporting client status.

2015-08-04 23:36:03:659 780 b98 Report CWERReporter finished handling 4 events. (00000000)

2015-08-04 23:36:04:596 780 b98 EP Got WSUS Client/Server URL: “http://172.22.191.145/ClientWebService/client.asmx”

2015-08-04 23:36:04:596 780 b98 EP Got WSUS Reporting URL: “http://172.22.191.145/ReportingWebService/ReportingWebService.asmx”

2015-08-04 23:36:04:596 780 b98 Report OpenReportingWebServiceConnection, reporting URL = http://172.22.191.145/ReportingWebService/ReportingWebService.asmx

2015-08-04 23:36:04:596 780 b98 IdleTmr WU operation (CLegacyEventUploader::HandleEvents) started; operation # 70; does use network; is at background priority

2015-08-04 23:36:04:596 780 b98 Report Uploading 4 events using cached cookie.

2015-08-04 23:36:04:608 780 b98 Report Reporter successfully uploaded 4 events.

2015-08-04 23:36:04:608 780 b98 IdleTmr WU operation (CLegacyEventUploader::HandleEvents, operation # 70) stopped; does use network; is at background priority

I will test your ideas in the next few days.

[doug]

OK, sounds good. Let me know how it goes.

Thanks,

Doug

[jjlandstrom]

I tried unchecking ‘Auto-accept EULAs during update installation, if required’. Then I attempted to disable the tried hiding KB2668562. I also stopped the WU service and deleted the downloaded patches. None have worked so far. I can try more tomorrow night.

[doug]

OK. Too bad those options didn’t work. Sounds like at this point you’ll need to remove the particular update approval at the WSUS, as mentioned above.

-Doug

[jjlandstrom]

I found it easier to download the Silverlight patch and push it with the deployment function. It is the quickest way to address the issue since it continues to show up on each new VM deployed. Chances are that the issue is in the VM image we are using.

Note that this is clearly not an issue with BatchPatch since I am not able to run Windows Updates manually.

I am going see about getting our VM image resolved soon so I don’t have to continue addressing this issue.

[doug]

Thanks for the update. However, to be clear, I don’t think it’s an issue with your image. I think it’s an issue with the content that was downloaded to your WSUS and subsequently to your computers. You might be correct, and I am not 100% certain since I might be incorrect about exactly what’s happening in your environment, but I believe that the update was downloaded to your WSUS with corruption in the EULA. That subsequently was downloaded to your target computers’ update caches, and then that causes them to fail installation regardless of whether you use WSUS or manual Windows Update / Microsoft Update. So, I believe the solution is to remove the approval for that particular update on your WSUS, which would then cause your clients to remove the update from their local cache. Then when you re-download that update on your WSUS (or directly on the clients), it should be good the second time around (hopefully). Another option might be to just delete/rename the C:WindowsSoftwareDistribution folder, because that’s where the local update cache is stored. And then have the computers pull the update fresh from Microsoft or from a different WSUS that doesn’t have a corrupt EULA cached.

Good luck!

-Doug

[Author]

Posts