locked
Feature update error 80070057, persistent on many PCs even with new WSUS (which works for fresh PCs) RRS feed

  • Question

  • Greetings,

    after lots of weeks dealing with this problem, the only reasonable next step
    is to speak to the experts! So here I am. I work in a small organization, with
    a WSUS server (2016) caching updates for all computers.

    On December, we started rolling out the 1903 feature update to all Windows
    10 machines (most of them on 1803). About two thirds of the population got
    the update normally, but the others (~100PCs) did produce the error 80070057.

    Troubleshooting steps taken for the 80070057 error:
    The step that fails is the call of WindowsUpdateBox.exe with the \predownload
    parameter. It lasts for about 3 seconds, then fails with said error (source: ProcMon)
    I have tried clearing the cache, changing locale (digit seperator), monitoring
    with Wireshark and Process Monitor - but the process just fails. WSUS' IIS
    doesn't report any 'denies' in its logs, like the request didn't reach him.
    Even a fresh 1803 install from media fails to get the approved 1903 feature
    update, with the same error. Redownliading the WSUS binaries didn't work,
    and the binaries appear to be OK. The only thing the clients have in common
    is that they all were previously upgraded from 1703 --> 1803 - but I'm not
    sure whether this has to do with anything. Altering the disk layout also didn't
    seem to have to do with the problem.

    After all this, we set up a new WSUS with the same major/minor version (OS
    and WSUS). We approved the 1903 update, and monitored the behaviour:

    • A fresh PC with 1803 recieves the update normally via the new WSUS server.
    • A PC recieving updates from the old WSUS, having encountered the 80070057
      error, still recieves the same error in the new one, even after reseting the WU
      agent (Soft. Distr remove, qmgr files remove, reregister dlls, reset Winsock).

    The problem is that we can't remedy the affected PCs, since the error is persistent
    across different WSUS server. The new WSUS server is a new install, and is serving
    the feature update to all PCs that have never encountered the 80070057 error.

    We also spent an awful lot of time to resolve the error, but couldn't identify a root
    cause - even after browsing through many forums & posts. It only affects the
    feature update - all other updates are installed normally. Since it affects clean OS
    installations as well, I'm confident that it is an issue affecting both the client and
    the server:

    • taking a disk image on the client before accessing any WSUS, enabled me to see
      that is fails on the old one and passes on the new one (client is the same, so the
      server surely does affect the error).
    • upon pointing to the new WSUS, a PC having encountered the error before will fail
      too - while a 'fresh' one will work seemlessly (server is the same, so the client
      surely keeps something even after a WU component reset).

    FYI, the organization utilizes a proxy server (not used for local access). Even getting the
    PC in the same subnet as WSUS doesn't remedy the error - so I don't think it's a network
    issue.

    Logs from all these are also available upon request.

    Thank you for your time,
    Anastasios Georgopoulos

    Wednesday, February 26, 2020 11:20 AM

All replies

  • Hi Anastasios,
       

    Thank you for your detailed description.
    First of all, did the clients that encountered upgrade difficulties install any installation software other than Windows Defender, so that WindowsUpdateBox.exe was blocked? This is my guess.
       

    Also, it seems that the troubleshooting methods often mentioned in some forums have already been tried. But in fact, for the problem of parameter errors, I think the source of the failure should be the problem of the client itself rather than WSUS, so please consider checking "Fix Windows Update errors" for any steps you have not tried.
        

    Regards,
    Yic

    Please remember to mark as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, February 27, 2020 5:40 AM
  • Hello Yic and thank you for your reply,

    The affected PCs had corporate software, and most notably McAfee VirusScan enterprise. From the first day though, I could replicate the exact error with a clean 1803 installation - so I came to the conclusion that third-party software could not have affected the outcome. Turning off Windows Firewall didn't help either.

    Being able to replicate on a fresh installation makes me sure that WSUS is a part of the equation going bad - but a considerate amount of time was also spent troubleshooting the client. As a result, I'm afraid that the page you refered has nothing that I haven't already tried.

    To help someone, I have also posted the WindowsUpdate.log and Bluebox.log (from the .exe stub file failing to execute and 'predownload' the binaries) on pastebin. WU: zPQ6HTjb BB: SNPCwJtW (I have requested to be verified to post links, but I understand it takes some time. Just paste the characters after the domain name/)

    Thank you for your time!,
    Anastasios G.

    Thursday, February 27, 2020 10:14 AM
  • Hi,
      

    Thank you for your reply.
    Any findings I will promptly reply in this thread. Please also wait for suggestions from other members in the forum. If you need to resolve this case as soon as possible, you can also start a support incident here with product support, and a Microsoft engineer can help you: Microsoft Support For Business.
      

    Regards,
    Yic

    Please remember to mark as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, February 28, 2020 5:54 AM
  • The issue has been resolved on a Spiceworks thread with the same subject.

    Thank you for your time,
    Anastasios G.

    Tuesday, March 3, 2020 2:32 PM