Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.

"0xc1800118" error when you push Windows 10 Version 1607 by using WSUS


View products that this article applies to.

Home users: This article is only intended for technical support agents and IT professionals. If you're looking for help with a problem, please ask the Microsoft Community.

↑ Back to the top


Symptoms

Consider the following scenario:
 
  • You have Windows Server Update Services (WSUS) configured in your environment.
  • On the WSUS server, you install update 3159706 to enable decryption of the new feature update for Windows 10.
  • You approve the feature update for Windows 10 Version 1607.
  • You notice that WSUS clients detect and download the feature update to C:\Windows\ccmcache, and that files populate correctly in C:\Windows\SoftwareDistribution\DataStore.
In this scenario, the installation starts, and files are decompressed to C:\$Windows.~BT. However, the process fails and returns the following error code:
 
0xC1800118


Additionally, the following entry may be logged in the setuperr.log and setupact.log logs:

From setuperr.log:
 <Date> <Time>, Error SP CSetupPlatform::ResurrectNewSystem: Cannot resurrect new
 system.: Win32Exception: \\?\C:\$Windows.~BT\Sources\NewSystem.dat: The system
 cannot find the file specified. [0x00000002] __cdecl UnBCL::FileStream:
 :FileStream(const class UnBCL::String *,enum UnBCL::FileMode,enum UnBCL:
 :FileAccess,enum UnBCL::FileShare,unsigned long) [gle=0x00000002]

 <Date> <Time>, Error CONX Windows::Compat::Appraiser::SetupAppraiser:
 :StopEtlLogger (2884): Waiting on generaltel process failed:
 [258].[gle=0x00000102]

 <Date> <Time>, Error MOUPG RecoverCrypto: File is encrypted, but no key was
 provided.

 <Date> <Time>, Error MOUPG CDlpActionRecoverCrypto::DoCrypto(1713): 
 Result = 0xC1800118

 <Date> <Time>, Error MOUPG CDlpActionRecoverCrypto::ExecuteRoutine(2465): 
 Result = 0xC1800118

 <Date> <Time>, Error MOUPG CDlpActionImpl<class CDlpErrorImpl<class
 CDlpObjectInternalImpl<class CUnknownImpl<class IDlpAction> > > >:
 :Execute(441): Result = 0xC1800118
From setupact.log:
 <Date> <Time>, Error MOUPG RecoverCrypto: File is encrypted, but no key was
 provided.

 <Date> <Time>, Error MOUPG CDlpActionRecoverCrypto::DoCrypto(1713):
 Result = 0xC1800118

 <Date> <Time>, Error MOUPG CDlpActionRecoverCrypto::ExecuteRoutine(2465):
 Result = 0xC1800118

 <Date> <Time>, Warning MOUPG CSetupDiagnostics::ReportData - Not reporting
 WINDLP data point [0x2101]

 <Date> <Time>, Warning MOUPG CSetupDiagnostics::ReportData - Not reporting
 WINDLP data point [0x2100]

 <Date> <Time>, Error MOUPG CDlpActionImpl<class CDlpErrorImpl<class
 CDlpObjectInternalImpl<class CUnknownImpl<class IDlpAction> > > >:
 :Execute(441): Result = 0xC1800118

 <Date> <Time>, Info MOUPG RecoverCrypto: Leaving Execute Method

 <Date> <Time>, Error MOUPG CDlpTask::ExecuteAction(3243): Result = 0xC1800118


Error Details

 Hex code - 0xc1800118

 Symbolic Name - WINDLP_E_RECOVERCRYPTO_WIM_DECRYPTKEY_MISSING

 Error Description - No key was provided to decrypt the specified WIM file 

↑ Back to the top


Cause

This problem occurs if the Windows 10 Version 1607 update is encrypted but does not appear as encrypted in the WSUS database. The problem may occur if the updates are synced before you apply KB 3159706.
 

↑ Back to the top


Workaround

To work around this problem, follow these steps on all WSUS servers in the environment.
 

  1. Detect whether WSUS is in a bad state. To do this, run the following query: 
     
    select Count(*)
    from tbFile as f, tbFileForRevision as fr, tbRevision as r, tbUpdate as u, tbProperty as p
    where f.FileDigest = fr.FileDigest and fr.RevisionID = r.RevisionID and r.LocalUpdateID = u.LocalUpdateID
    and p.RevisionID = r.RevisionID and 
    (f.FileName like '%15063%.esd' or f.FileName like '%14393%.esd' or f.IsEncrypted = 1) 
    and f.DecryptionKey is null
    and p.PublicationState = 0

    Note If the results show a "TotalResults > 0" entry, this indicates that the server is in a bad state.
  2. If WSUS is in a bad state, take the following steps in the listed order and in the indicated locations:
     


    Order of steps

    1. Disable the “Upgrades” classification (USS or stand-alone WSUS)
    2. In Windows PowerShell ISE (admin), decline all Windows 10 upgrades.
    3. Remove all the upgrades for Windows 10 from the SUSDB.
    4. Delete files from the tbFile table in the WSUS database.
    5. Re-enable the classification in Windows PowerShell.
    6. Force a sync (PowerShell).
    • Step 1: Disable the “Upgrades” classification (USS or stand-alone WSUS).
      Get-WsusClassification | Where-Object -FilterScript {$_.Classification.Title -Eq “Upgrades”} | Set-WsusClassification -Disable 
    • Step 2: In Windows PowerShell ISE (admin), decline all Windows 10 upgrades.
      [reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")
      $wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer();
      $wsus.GetUpdates() | Where {$_.UpdateClassificationTitle -eq 'Upgrades' -and $_.Title -match 'Windows 10'} `
      | ForEach-Object {$_.Decline(); Write-Host $_.Title declined} 
      
    • Step 3: Remove all the Upgrades for Windows 10 from the SUSDB.

      Note Make sure that you run the deletion first on the WSUS server that is highest in your hierarchy. Then, work your way down. Otherwise, your deletions may be replaced by the USS on the next sync attempt.
      [reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")
      $wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer();
      $wsus.GetUpdates() | Where {$_.UpdateClassificationTitle -eq 'Upgrades' -and $_.Title -match 'Windows 10'} `
      | ForEach-Object {$wsus.DeleteUpdate($_.Id.UpdateId.ToString()); Write-Host $_.Title removed}
      
    • Step 4: Delete files from the tbFile table in the WSUS database. On the WSUS database, run the following commands from SQL Server Management Studio:
      declare @NotNeededFiles table (FileDigest binary(20) UNIQUE)
      insert into @NotNeededFiles(FileDigest) (select FileDigest from tbFile where FileName like '%.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)
    • Step 5: Re-enable the classification in Windows PowerShell.
      Get-WsusClassification | Where-Object -FilterScript {$_.Classification.Title -Eq “Upgrades”} | Set-WsusClassification
      
    • Step 6: Force a Sync (PowerShell):
      $s = Get-WsusServer
      $sub = $s.GetSubscription()
      $sub.StartSynchronization()
      
  3. If you are using System Center Configuration Manager (ConfigMgr), follow these steps:
     
    1. On the topmost ConfigMgr server in the hierarchy, open <sccm Install directory>\inboxes\wsyncmgr.box.
    2. In the wsyngmgr.box folder, create a file that is named "FULL.SYN" (this file forces ConfigMgr to do a full sync for updates). Monitor the wsyncmgr.log to verify that the file ran.
  4. On each client, do the following:
     
    1. In an elevated Command Prompt window, run the following command:

      net stop wuauserv
    2. Run the following command:

      del %windir%\SoftwareDistribution\DataStore\*


      Note This command also forces a full scan from the client.
    3. Make sure that there's no hidden ~BT folder on drive C. If there is, delete the folder.
    4. Run the following command:

      net start wuauserv

↑ Back to the top


Keywords: kb

↑ Back to the top

Article Info
Article ID : 3194588
Revision : 26
Created on : 10/22/2018
Published on : 10/22/2018
Exists online : False
Views : 1552