BatchPatch Forums Home › Forums › BatchPatch Support Forum › Windows Update: Error 1611: -106 || Error 1620: -106
- This topic has 24 replies, 7 voices, and was last updated 7 years, 4 months ago by higginss.
-
AuthorPosts
-
March 3, 2016 at 8:50 pm #9176dougModerator
The symptoms are as follows:
-BatchPatch works fine/normally on all targets except for Win 10 targets
-When checking for Windows Updates on Win 10 targets manually using the control panel Windows Update GUI, the check works properly
-When checking for Windows Updates on Win 10 targets using BatchPatch when the Win 10 targets are pointing to a WSUS server, the following error occurs:Windows Update: Error 1611: -106. Failure Windows Update: -106G: Update search completed with errors: -2145124338
OR
Windows Update: Error 1620: -106. Failure Windows Update: -106G: Update search completed with errors: -2145124338
OR
Windows Update: Error 1611: -106. Failure Windows Update: -106G: Update search completed with errors: -2145116137
OR
Windows Update: Error 1620: -106. Failure Windows Update: -106G: Update search completed with errors: -2145116137
-When checking for Windows Updates on Win 10 targets using BatchPatch when BatchPatch is configured to bypass the local WSUS server and search instead on ‘Windows Update’ or ‘Microsoft Update,’ the check works properly.
Check your HRESULT value first. HRESULT -2145124338 has a different cause compared to HRESULT -2145116137
—————————————————————
—————————————————————
Resolution for HRESULT -2145116137:
—————————————————————
HRESULT -2145116137 => 0x80242017 WU_E_UH_NEW_SERVICING_STACK_REQUIRED The OS servicing stack must be updated before this update is downloaded or installed
More info at the following link, but your easiest option is probably to run Windows Update one time with the server selection in BP set to ‘Windows Update’ or ‘Microsoft Update’ (Tools > Settings > Windows Update > Server Selection). After installing updates that way and rebooting, a check for updates against the managed WSUS should work. If for some reason that doesn’t work then you’ll likely need to locate the standalone servicing stack update that your machines require in the Microsoft Update Catalog directly. Then install that SSU manually or with the Deployment feature in BP.
—————————————————————
—————————————————————
Resolution for HRESULT -2145124338:
—————————————————————The cause is that invalid result data is returned from the search for updates against the WSUS.
-2145124338 => 0x8024000E WU_E_XML_INVALID Windows Update Agent found invalid information in the update's XML data.
We realize that it’s strange that when the check for updates is performed manually on the Windows 10 machine using the control panel Windows Update interface, it succeeds. However, we suspect that the reason for this is due to Microsoft using a private API that we do not have access to. It might also be that the issue is actually a bug in the Windows Update Agent, but we have no way at the moment to confirm if this is the case.
In any case, there are a few options for resolution:
Option 0: Run the WSUS Server Cleanup Wizard (in the WSUS console select ‘Options > Server Cleanup Wizard.’ This cleanup routine may or may not fix the issue, but it is likely worth trying as a first step just because it’s easy to do.
Option 1: After a *lot* of testing with one customer’s database, we were able to determine the culprit update in his database to be AMD driver update for Pci Bus. I was able to decline this single update and then wait a few minutes, and the error disappeared. Note, after declining an update, it’s very important to wait a few minutes (or more) until the SQL database activity stops before testing again. It seems that when you decline an update in WSUS, under the hood there is some additional database activity that takes place, which can take a few minutes to complete. If you decline the correct/problematic update but don’t wait long enough before you test again, the error will still occur. Generally speaking in our testing we found that usually a minute or two was long enough, but in your environment this could be different depending on the size of the database and the CPU speed of the server. If you watch the sqlservr.exe process in task manager, you’ll be able to see when it stops processing.
One other customer reported the following other updates as potentially problematic:
AMD driver update for Pci Bus
Intel Corporation driver update for Intel(R) Wireless Bluetooth(R)
INTEL driver update for Intel(R) 8 Series/C220 Series PCI Express Root Port #1 – 8C10
INTEL driver update for Intel(R) 8 Series/C220 Series PCI Express Root Port #4 – 8C16
Intel driver update for Intel(R) Dual Band Wireless-AC 7265
INTEL driver update for Intel(R) H81 LPC Controller – 8C5C
Option 2: We selectively declined only the updates in the ‘Windows 10 and later drivers’ group and waited a few minutes. This made the problem go away. To do this we created a new update view on the WSUS by right-clicking on ‘Updates’ in the left-pane, and selecting the option for ‘New Update View…’ Then check the box ‘Updates are for a specific product.’ Then modify the checkbox list of products to include ONLY the checkbox for ‘Windows 10 and later drivers.’ Then specify a name for the view called ‘Windows 10 and later drivers’ or whatever you prefer. After that, change the the filter drop-downs to show “Approval: ‘Any Except Declined’ Status: ‘Any'”. Select all updates even if they are not approved, and go ahead and decline them. This worked in my test with a problematic database provided by one customer.
Option 3: Rebuild the WSUS database. Fortunately, it only takes about 30 minutes to install and configure WSUS from scratch, so this is not a painful process. Less than ideal, yes. However, in most cases it is probably quicker and easier than the 4th option.
Option 4: Find the problematic update and decline it. The problem with this approach is that we do not have a fast way to determine which update is the source of the problem without very painstaking, manual testing. At the time of this writing we only know of 4 users who have been affected by this problem. We do not know if the same update was the culprit for each user, but we do know that at least 2 of the users the issue was a driver update, and I believe there is a good chance that in all cases it might be the very same ‘AMD driver update for Pci Bus’ mentioned in option 1. If you find that to be the case, please post in this thread to let us know.
Thanks,
DougMarch 10, 2016 at 5:01 pm #11176dougModeratorAfter a lot of testing with one customer’s database, we were able to determine the culprit update in his database to be ‘AMD driver update for Pci Bus’ I was able to decline this single update and then wait a few minutes, and the error disappeared.
If you determine that this update is not the culprit on your server, the next best option would be to selectively declined all of the updates in the ‘Windows 10 and later drivers’ group. To do this…
1. create a new update view on the WSUS by right-clicking on ‘Updates’ in the left-pane, and selecting the option for ‘New Update View…’
2. Check the box ‘Updates are for a specific product.’
3. Modify the checkbox list of products to include ONLY the checkbox for ‘Windows 10 and later drivers.’
4. Specify a name for the view called ‘Windows 10 and later drivers’ or whatever you prefer and click OK.
5. Now make sure the new ‘Windows 10 and later drivers’ view that you just created is the selected view.
6. Change the the filter drop-downs to show
Approval: 'Any Except Declined' Status: 'Any'
7. Select all updates even if they are not approved, and go ahead and decline them. After the updates are declined you might still need to wait a few minutes (or longer) before the error will stop occurring.
-Doug
March 28, 2016 at 4:20 pm #11187kkoldewynParticipantWe’re another customer with exactly the same problem described by Doug. Luckily, I can confirm that just declining the single update “AMD driver update for Pci Bus” fixed the problem for us as well. Thanks, Doug!
– Kennis
March 28, 2016 at 4:35 pm #11188dougModeratorKennis – Thank you for reporting your success with declining the single update ‘AMD driver update for Pci Bus.’ I’m very glad to know that this fixed the issue for you!
-Doug
August 17, 2016 at 3:17 pm #11352dougModeratorI should also note to anyone else reading this posting that whenever possible we strongly encourage/recommend to users to not synchronize any drivers to WSUS. The drivers dramatically bloat the WSUS database and seem to only cause issues. In our experience, driver updates should generally be performed on computers as-needed and not through WSUS or Microsoft Update. You can find numerous postings on the web that agree with this sentiment. Updating drivers through the Windows Update mechanism generally seems to cause more problems than it solves.
-Doug
August 18, 2016 at 1:33 pm #11358dcauParticipantHi Doug,
We’ve had this problem for some time and finally found this post. Declining the driver update “AMD driver update for PCI Bus” made the error go away.
Thanks for the excellent customer service and support!
Danny
August 18, 2016 at 4:29 pm #11359dougModeratorDanny – Thanks for sharing your experience. Glad that fixed it for you!
-Doug
October 24, 2016 at 7:15 pm #11409jcityParticipantHi Doug,
A number of our Win7 domain machines are returning this error as well, but none of the fixes mentioned above have solved it. This is the error we are getting:
::Begin online search – Server Selection: Default
-106G: Update search completed with errors: -2145067007
The error in the Windows Update Messages column shows Error 1611: -106. Failure <date>
Any help is appreciated!
October 24, 2016 at 7:34 pm #11410dougModeratorThis error is:
0x8024e001 -2145067007 WU_E_EE_UNKNOWN_EXPRESSION
an expression handler was passed an expression that it
doesn't know aboutIt’s not something we have ever heard of or encountered before. What happens if you run Windows Update manually from the control panel Windows Update interface on one of the problematic target Windows 7 computers directly WITHOUT using BatchPatch?
-Doug
October 25, 2016 at 1:06 pm #11412jcityParticipantWhen I run Windows Update manually from the problematic targets, there are no new updates found – they’re up to date. I am only searching for “important” updates. I’ve had no problems with servers, but it seems standalone PC’s are giving me this error for nearly half of the inventory.
Thanks again.
October 25, 2016 at 2:49 pm #11413dougModeratorAnd can you confirm that you are using WSUS (as opposed to Windows Update)? If you go into BatchPatch Tools > Settings > Windows Update and change the ‘Server selection’ to ‘Windows Update’ does BatchPatch then work? I think the answer will be yes, as this is likely an issue with how WSUS is returning the search results. Let me know.
Thanks,
Doug
October 25, 2016 at 3:06 pm #11414jcityParticipantIt is still failing after selecting “Windows Update” in settings.
October 25, 2016 at 3:18 pm #11415dougModeratorInteresting. I’m going to send you an email to discuss further.
-Doug
November 9, 2016 at 8:08 pm #11435mccpcParticipantRemoving these helped in my setup/configuration.
AMD driver update for Pci Bus
Intel Corporation driver update for Intel(R) Wireless Bluetooth(R)
INTEL driver update for Intel(R) 8 Series/C220 Series PCI Express Root Port #1 – 8C10
INTEL driver update for Intel(R) 8 Series/C220 Series PCI Express Root Port #4 – 8C16
Intel driver update for Intel(R) Dual Band Wireless-AC 7265
INTEL driver update for Intel(R) H81 LPC Controller – 8C5C
November 23, 2016 at 1:31 pm #10839higginssParticipantI’m getting this same error trying to check updates on Windows 10 from another Windows 10 desktop.
Windows Update Messages
Error 1611: -106. Failure – 08:24:14
Remote Agent Log
LHIGGINS-VM 11/23/2016 08:24:09
::Begin online search – Server Selection: Default
-106G: Update search completed with errors: -2145124338
LHIGGINS-VM 11/23/2016 08:24:12
All Messages
Wed-08:24:14> Windows Update: Error 1611: -106. Failure
Wed-08:24:14> Windows Update: -106G: Update search completed with errors: -2145124338
Wed-08:24:08> Windows Update: Executing BatchPatchRemoteAgent.exe…
Wed-08:24:08> Windows Update: Attempting to initiate Windows Update (Action: Search for updates: ‘ImportantOnly’ | Server selection: Default / Managed) …
Wed-08:24:08> Windows Update: Establishing connection…
Wed-08:24:08> Windows Update: Initializing…
Wed-08:24:08> Windows Update: Queued… (Check for available updates)
Wed-08:21:32> Windows Update: Error 1611: -106. Failure
Wed-08:21:32> Windows Update: -106G: Update search completed with errors: -2145124338
Wed-08:21:27> Windows Update: Executing BatchPatchRemoteAgent.exe…
Wed-08:21:27> Windows Update: Attempting to initiate Windows Update (Action: Search for updates: ‘SoftwareOnly’ | Server selection: Default / Managed) …
Wed-08:21:27> Windows Update: Establishing connection…
Wed-08:21:27> Windows Update: Initializing…
Wed-08:21:27> Windows Update: Queued… (Check for available updates)
Wed-08:21:09> Windows Update: There are no applicable updates
Wed-08:20:59> Windows Update: Executing BatchPatchRemoteAgent.exe…
Wed-08:20:58> Windows Update: Attempting to initiate Windows Update (Action: Search for updates: ‘SoftwareOnly’ | Server selection: Windows Update) …
Wed-08:20:58> Windows Update: Establishing connection…
Wed-08:20:58> Windows Update: Initializing…
Wed-08:20:58> Windows Update: Queued… (Check for available updates)
If I try changing to Windows Updates, it works. I have my WSUS server on Server 2012R2 and I have it set to only sync updates for Windows 10. I double checked yesterday to make sure it’s not syncing any kind of driver or anything so in my case it shouldn’t be an issue with the drivers referenced in this thread. Any ideas?
November 23, 2016 at 1:35 pm #11460higginssParticipantI’m having this same error trying to check from updates on a Windows 10 desktop from a Windows 10 desktop. My WSUS server is on Server 2012 R2 and I confirmed yesterday is only set to get Windows 10 updates, no drivers. If I set it to use Windows updates it works.
Windows Update Messages
Error 1611: -106. Failure – 08:24:14
Remote Agent Log
LHIGGINS-VM 11/23/2016 08:24:09
::Begin online search – Server Selection: Default
-106G: Update search completed with errors: -2145124338
LHIGGINS-VM 11/23/2016 08:24:12
All Messages
Wed-08:24:14> Windows Update: Error 1611: -106. Failure
Wed-08:24:14> Windows Update: -106G: Update search completed with errors: -2145124338
Wed-08:24:08> Windows Update: Executing BatchPatchRemoteAgent.exe…
Wed-08:24:08> Windows Update: Attempting to initiate Windows Update (Action: Search for updates: ‘ImportantOnly’ | Server selection: Default / Managed) …
Wed-08:24:08> Windows Update: Establishing connection…
Wed-08:24:08> Windows Update: Initializing…
Wed-08:24:08> Windows Update: Queued… (Check for available updates)
Wed-08:21:32> Windows Update: Error 1611: -106. Failure
Wed-08:21:32> Windows Update: -106G: Update search completed with errors: -2145124338
Wed-08:21:27> Windows Update: Executing BatchPatchRemoteAgent.exe…
Wed-08:21:27> Windows Update: Attempting to initiate Windows Update (Action: Search for updates: ‘SoftwareOnly’ | Server selection: Default / Managed) …
Wed-08:21:27> Windows Update: Establishing connection…
Wed-08:21:27> Windows Update: Initializing…
Wed-08:21:27> Windows Update: Queued… (Check for available updates)
Wed-08:21:09> Windows Update: There are no applicable updates
Wed-08:20:59> Windows Update: Executing BatchPatchRemoteAgent.exe…
Wed-08:20:58> Windows Update: Attempting to initiate Windows Update (Action: Search for updates: ‘SoftwareOnly’ | Server selection: Windows Update) …
Wed-08:20:58> Windows Update: Establishing connection…
Wed-08:20:58> Windows Update: Initializing…
Wed-08:20:58> Windows Update: Queued… (Check for available updates)
November 23, 2016 at 3:43 pm #11461higginssParticipantI’m having this same issue. I’ve got a 2012 R2 WSUS server that I’ve got set to not sync drivers, only Windows 10. If I set batchpatch to use Windows updates it works fine, just get this error when trying to run the update check against WSUS.
June 27, 2017 at 11:02 pm #10536jc007ParticipantI realize this is an older post, but I wanted to see if anyone has an update on this error message. I get error 1611: -106 on some Windows 7 computers and I have tried using Windows Update and Microsoft Update, without success.
June 27, 2017 at 11:25 pm #10537dougModeratorIn order to troubleshoot we would need the complete error message with HRESULT value. Please look at your ‘All messages’ column where there should be an additional line that includes more detail. Additionally the ‘Remote agent log’ would also include more detail as would the BatchPatchError.log file on the target computer (default location would be C:Program FilesBatchPatchBatchPatchError.log.
Example:
Windows Update: Error 1611: -106. Failure
Windows Update: -106G: Update search completed with errors: -2145124338Thanks,
Doug
June 28, 2017 at 8:46 pm #10530jc007ParticipantThank you for the reply. Here is the error message.
Windows Update: Error 1611: -106. Failure
Windows Update: -106G: Update search completed with errors: -2145067007 2359301
June 28, 2017 at 11:02 pm #10532dougModeratorOK, the conversion for -2145067007 is 8024E001:
0x8024e001 -2145067007 WU_E_EE_UNKNOWN_EXPRESSION
an expression handler was passed an expression that it
doesn't know aboutWe have only ever heard of this error once before (you can see the user, jcity, posted about it higher up in this same thread). He ended up resolving the issue by installing a WSUS server in his environment. When the machine searched for updates against the WSUS, they no longer produced this error.
Do you currently have a WSUS? I know you said you have tried both Microsoft Update and Windows Update and that you see this error with both, but I’m curious if you have a WSUS and what happens when these machines are pointing to it?
Another thing that might provide more information about the cause of the error would be look in the WindowsUpdate.log, which is on the target computer at C:WindowsWindowsUpdate.log . Do a search in the WindowsUpdate.log for ‘8024E001’ without the quotes, and then copy the relevant line(s) into this thread (just make sure the timestamp matches the time that you saw the error in BatchPatch, so that we know for sure that we are looking at the right thing). I’m curious to know what it says.
Thanks,
Doug
June 29, 2017 at 3:27 pm #10533jc007ParticipantHere are entries from the WindowsUpdate.log:
EEHndlr FATAL: Parse failed: error 0x8024e001
EEHndlr FATAL: ParseMetadata failed: error 0x8024e001
EEHndlr FATAL: Parse failed with 0x8024e001
PT WARNING: PopulateDataStore failed: 0x8024e001
PT WARNING: Sync of Drivers failed (Software succeeded): 0x8024e001
I have seen other forum entries mentioning that drivers installed from WSUS could cause this issue, but with these particular computers I am not using WSUS to patch and I have not selected any driver updates within the BatchPatch Windows Update settings. My WSUS server is integrated with and controlled by SCCM. Since it isn’t a stand-alone WSUS server, I don’t think BatchPatch can use it as an update source.
June 29, 2017 at 6:14 pm #10520dougModeratorStrange. This is very similar to what we saw in the WindowsUpdate.log in the case of the other error mentioned at the top of this post (-2145124338 => 0x8024000E WU_E_XML_INVALID). I don’t think this is going to work, but what happens if under ‘Tools > Settings > Windows Update’ you choose ‘Search for *all* software updates’ or ‘Search for *only* important updates’ ? Do either of those settings work? Make sure that ‘search for *all* drivers’ is UNchecked.
You are correct that with your WSUS server being controlled by SCCM, BatchPatch will never find any available updates when the target computers are pointing to the SCCM-controlled WSUS. You would have to set up a new/separate WSUS that is not controlled by SCCM in order for BatchPatch targets to search for updates against WSUS.
-Doug
June 30, 2017 at 5:27 pm #10508jc007ParticipantI tried selecting Search for *all* software updates and Search for *only* important updates, but the results are the same.
June 30, 2017 at 6:14 pm #10509dougModeratorAnd to be clear you’re seeing this on *some* Win 7 targets but not *all* Win 7 targets? It does sound like there must be a driver on those problematic targets that does not exist on the other targets, though of course it’s not clear why the search results are coming back as unparsable.
At the moment I do not have a solution, but perhaps one possible workaround would be to identify the driver on the target computer and disable it there so that the update search does not try to include it. This might work, though I realize it’s not a great workaround even if it does work.
Another option would be to build a WSUS that is not linked to your SCCM. I think there is a good chance that if you point these systems to a WSUS then you won’t have any issues with the search.
I will report back if/when I have any other suggestions.
-Doug
-
AuthorPosts
- You must be logged in to reply to this topic.