Steps to resolve error 0xc1800118

(Alternative title: “Help, I followed the steps provided earlier and I’m still seeing failures!”

This applies to anyone who missed KB 3159706 when it was offered as a hotfix to Windows Server 2012/R2, and who subsequently enabled synching of Upgrades in their environment before patching WSUS.  The Upgrades that were likely downloaded most recently happen to be for the Windows 10 1607 feature update, but the steps referenced could be modified to suit a different set of content.)

In this scenario, WSUS has downloaded content that it cannot use.  Because parsing only happens once, and WSUS does not know what “Upgrades” are without having installed KB 3159706, it incorrectly identifies the upgrade as a quality update and saves it to the SUSDB (and managed clients) as such.  This will cause any future deployment of this content to fail until the patch is applied, unusable content is purged, and WSUS properly syncs the information.

If the symptom seems familiar, it is because the guidance for KB3095113 addresses a similar class of issue.  The steps detailed in that post are sufficient for repairing a WSUS that has downloaded unencrypted feature updates, but encrypted content involves a few more steps in order to fully clean your WSUS and its affected clients.  For information on why Upgrades are now being encrypted, please refer to our earlier blog post.

Full coverage of error 0xc1800118 (and how to clean your environment after downloading unsupported encrypted Upgrades to WSUS) can be found in KB 3194588, which was created to help address these failures in the wild.  Feel free to share questions and feedback for that KB by using the comments section for this post.  Finally, several folks shared some PowerShell advice in the comments section for the post regarding KB3095113: you may find it worthwhile to review that if the steps published do not quite fit your needs.


Comments (33)

  1. Poison Dwarf says:


    Based on Article KB 3159706, there is some weird stuff about the SubDB SQL commands

    declare @NotNeededFiles table (FileDigest binary(20) UNIQUE);
    insert into @NotNeededFiles(FileDigest) (select FileDigest from tbFile where FileName like ‘%14393%.esd’ except select FileDigest from tbFileForRevision);
    deletefrom tbFileOnServer where FileDigest in (select FileDigest from @NotNeededFiles)
    delete from tbFile where FileDigest in (select FileDigest from @NotNeededFiles)

    That deletefrom is obvious but I mean query part

    (select FileDigest from tbFile where FileName like ‘%14393%.esd’ except select FileDigest from tbFileForRevision);

    The whole query result 0 rows affected If there is that “except select FileDigest from tbFileForRevision” part included

    What I am missing or doing wrong?

    1. Poison Dwarf says:


      I have to use also

      $s = Get-WsusServer
      $1607Updates = $s.SearchUpdates(“versio 1607”)
      $1607Updates | foreach { $_.Decline() }
      $1607Updates | foreach { $s.DeleteUpdate($_.Id.UpdateId) }

      Because finnish 🙂

      1. Great point, Poison Dwarf: the search query that we specify is in English, so you’ll need to translate to whatever language your WSUS is configured to use. Thanks for sharing!

      2. Oliver Prade says:

        In my Case, i had to use:

        $s = Get-WsusServer
        $1607Updates = $s.SearchUpdates(“version [Release]”)
        $1607Updates | foreach { $_.Decline() }
        $1607Updates | foreach { $s.DeleteUpdate($_.Id.UpdateId) }

        There were 372 Updates with this Name inside.

        In my Case, the German Version does not show the name correctly

        The Updates were named like this, when i opened the SCCM Mangement Console (German):
        Funktionsupdate für Windows 10 Enterprise, Version [Release], [Sprachencode]

        After enable Upgrades classification, I deleted the files in the Database with:

        declare @NotNeededFiles table (FileDigest binary(20) UNIQUE);
        insert into @NotNeededFiles(FileDigest) (select FileDigest from tbFile where FileName like ‘%14393%.esd’ except select FileDigest from tbFileForRevision);
        delete from tbFileOnServer where FileDigest in (select FileDigest from @NotNeededFiles)
        delete from tbFile where FileDigest in (select FileDigest from @NotNeededFiles)

        I checked the Database with step 1 -> Total Result is 0

        The Upgrade to 1607 is now working 🙂

        1. Great news, Oliver. We’re also updating the KB with a note that the guidance is for English OS installations, to help prevent confusion from this.

    2. Lukas Rozsypalek says:

      I have the same problem as Poison Dwarf.
      This query (select FileDigest from tbFile where FileName like ‘%14393%.esd’ except select FileDigest from tbFileForRevision) result is 0 rows affected.

      But if i run query:
      select TotalResults = Count(*)
      from tbFile
      where (IsEncrypted = 1 and DecryptionKey is NULL) or (FileName like ‘%14393%.esd’ and IsEncrypted = 0)
      Result is: TotalResults 48.

      What is wrong?

  2. Daniele Montagnoli says:

    The sql codes in is not correct, it’s possible have it ?

    1. We did have a typo in the first draft (changes should go live later today): “deletefrom” should be “delete from”. Did you notice any other errors?

      Also, some formatting oddities showed up on some browsers after the initial publish; we’re working those out, as well.

      1. Henry says:

        declare @NotNeededFiles table (FileDigest binary(20) UNIQUE);

        + declare @NotNeededFiles table (FileDigest binary(20) UNIQUE);
        + ~~~~~~~~~~
        + CategoryInfo : ObjectNotFound: (FileDigest:String) [], CommandNotFoundException
        + FullyQualifiedErrorId : CommandNotFoundException

        1. Henry says:

          Okay, i figured it out, its not powershell, its sql. 🙂

  3. Jon Larson says:

    YES, finally. This has solved my issues with WSUS and SCCM 2012 1606 deploying the anniversary update.

  4. BradG87 says:

    Just for fun, I ran the query in KB3194588. The results are below:

    Changed database context to ‘SUSDB’.

    Next, I did this –> del %windir%\SoftwareDistribution\DataStore\*

    on the client PC, after stopping the service.

    The PC’s download other updates like defender updates and cumulative updates to 1511. When trying to download the feature update to 1607, it just sets at 0% downloading.

    Any help with this issue would be appreciated.


    1. Please post this in our TechNet forum to get assistance from the community as well as our support staff. Without seeing your client logs, I couldn’t tell you exactly what’s going on here.

  5. Sven J says:

    How do I run this script on 2012R2 if I don’t have SQL management studio..?

    1. There is a free version of SQL Management Studio (Express) that you can use. With that said, we acknowledge this is a painful workaround; better solutions are coming, but we wanted to get this guidance out there for the DIY crowd.

  6. Ole R says:

    Out of curiosity: Why do we need to delete the datastore to get this working?

    1. The client will not update the metadata for any files it has already downloaded. Both it and WSUS have long assumed that metadata never changed, so this was no issue. What’s different now is that an unpatched WSUS will essentially save different metadata (and so will the client). After patching, the metadata will remain the same, so the problem persists. You have to purge the incomplete files after enabling the scenario in order to repair it.

      1. sialaser says:

        I make a big error, I deleted from tbFile all FileName like ‘%14393%.esd’ without exclude FileDigest from tbFileForRevision.
        Now all clients do not see Windows 10 1607 update anymore.
        I try a wsusutil /reset, I also reapprove 1607 update… WSUS redownload the file but select * from tbFile where FileName like ‘%14393%.esd’ return 0 records.
        How can I solve this?

      2. sialaser says:

        Finally I solved the problem.
        Using the powershell command (change “version” with my localization) now WSUS redownload 1607 update:
        $s = Get-WsusServer
        $1607Updates = $s.SearchUpdates(“versione 1607”)
        $1607Updates | foreach { $_.Decline() }
        $1607Updates | foreach { $s.DeleteUpdate($_.Id.UpdateId) }

        Thanks for this best post!

  7. CSAD Florenc says:

    Thank you, Support guys, for updating
    Do you think, is this workaround ready for worldwide deployment, or should we wait some more time?
    Thank You, Amarok

    1. This is a heavy workaround; we’re working on cutting out the step to “modify database tables directly”, which will lead to our final solution. If you can wait until this is released, then we recommend doing so.

      1. CSAD Florenc says:

        Any news about upcoming hotfix? We realy don`t want to install SSMS on our WSUS (also DC) server. Thank you.

  8. John David says:

    I’m having trouble being able to connect to the database to run the commands. I’ve tried using SQL Management Studio and the sqlcmd line as well. Any ideas? The KB article gives no indication on how to connect to the DB, which I’ve never had to do before.

    Doing research I found information saying to install SQL Mgt Studio and connect to \\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query which fails. I also tried this command line: sqlcmd -s np:\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query

    and I get the following:
    Sqlcmd: Error: Microsoft ODBC Driver 13 for SQL Server : Named Pipes Provider: C
    ould not open a connection to SQL Server [2]. .
    Sqlcmd: Error: Microsoft ODBC Driver 13 for SQL Server : Login timeout expired.
    Sqlcmd: Error: Microsoft ODBC Driver 13 for SQL Server : A network-related or in
    stance-specific error has occurred while establishing a connection to SQL Server
    . Server is not found or not accessible. Check if instance name is correct and i
    f SQL Server is configured to allow remote connections. For more information see
    SQL Server Books Online..

    Any help would be greatly appreciated.

    1. Sorry for the confusion, John. This isn’t our ideal workaround, and we’re looking to ship something that fixes this issue without having to open SQL Management Studio. If you can hang on until Thanksgiving, then we recommend waiting for that (which we’re hoping to ship before the US holiday); otherwise, you’ll need to debug your connection issue. From the error, it looks like you might have the named pipe incorrect.

  9. Chris says:

    The query to detect if WSUS is in a bad state on KB3194588 returns 0 for me so it is in a good state yet still seeing 0xc1800118 on clients in UpdateHandler.log. I have tried to delete %windir%\SoftwareDistribution\DataStore\* incase a previous bad download or something might have been the cause I also cleared %windir%\ccmcache and it seemed to work however I am not getting 0xc190012f in the WUAHandler.log after rebooting. No idea what this error is, not much info on the web about it other than people experiencing it.

    1. Please post this in the TechNet forum so that it can be properly discussed. If your WSUS is not in a bad state, then all that remains is to make sure your client is healthy. Sounds like there might be one more step to getting that particular result.

  10. Rodrigo says:

    There is the possibility to launch the latest cumulative update for Windows 10 v1607 as GDR-DU on WSUS?
    So it would install with the upgrade and solve the problem of not updating by WSUS.

    1. The issue is that you’ve synched content to WSUS before installing KB3159706 (and following the manual steps). Patching the client is fine, and your suggestion is a good one, but it alone cannot prevent this error.

  11. Luke says:

    We have encountered this issue and can verify that deleting the datastore contents on a client machine fixes the issue (and the upgrade proceeds without error). But can you verify what other action is recommended on the server? The WSUS database is not in a bad state.
    We don’t want to have to delete the datastore contents on every machine. Thanks

    1. If your WSUS is not in a bad state, then you need delete nothing. Getting upgrades to proceed without error is the goal: if you’re there, then you’re done.

      1. Luke says:

        Thanks Steve, so the answer is “we need to delete the %windir%\SoftwareDistribution\DataStore\*” on every machine before proceeding? Manual intervention is required for every upgrade?

        1. BradG87 says:

          I hope your results are different but deleting the data store on the PC make no difference for me.

Skip to main content