locked
WSUS 3.0 SP2 troubles after installing KB2938066 (0xC000000D) RRS feed

  • Question

  • Hi everyone,

    I ran into a problem in our WSUS environment after installing the latest hotfix KB2938066.

    We have WS2008R2 SP1 (fully patched) for WSUS-Upstream server and couple of the same servers for WSUS-Downstream.

    Previous functional version of WSUS was 3.2.7600.256.

    After installing KB2938066 (v3.2.7600.274) the WU/MU clients updated, but on some machines, mostly on servers with WS2008R2 SP1 (RADIUS and Domain Controllers), they now have problems installing updates.

    The error I see in '0xC000000D', which is something peculiar and not well searchable on the internet.

    Here is part of the WindowsUpdate log.

    I would appreciate any advice. Thx, John.

     

    Agent *************
    Agent ** START ** Agent: Finding updates [CallerId = AutomaticUpdates]
    Agent *********
    Agent * Online = Yes; Ignore download priority = No
    Agent * Criteria = "IsInstalled=0 and DeploymentAction='Installation' or IsPresent=1 and DeploymentAction='Uninstallation' or IsInstalled=1 and DeploymentAction='Installation' and RebootRequired=1 or IsInstalled=0 and DeploymentAction='Uninstallation' and RebootRequired=1"
    Agent * ServiceID = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7} Managed
    Agent * Search Scope = {Machine}
    Setup Checking for agent SelfUpdate
    Setup Client version: Core: 7.6.7600.320 Aux: 7.6.7600.320
    Misc Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wuident.cab with dwProvFlags 0x00000080:
    Misc Microsoft signed: NA
    Misc Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\TMPC435.tmp with dwProvFlags 0x00000080:
    Misc FATAL: Error: 0xc000000d when verifying trust for C:\Windows\SoftwareDistribution\SelfUpdate\TMPC435.tmp
    Misc WARNING: Digital Signatures on file C:\Windows\SoftwareDistribution\SelfUpdate\TMPC435.tmp are not trusted: Error 0xc000000d
    Setup FATAL: Ident cab verification failed with error 0XC000000D
    Setup WARNING: SelfUpdate check failed to download package information, error = 0xC000000D
    Setup FATAL: SelfUpdate check failed, err = 0xC000000D
    Agent * WARNING: Skipping scan, self-update check returned 0xC000000D
    Agent * WARNING: Exit code = 0xC000000D
    Agent *********
    Agent ** END ** Agent: Finding updates [CallerId = AutomaticUpdates]
    Agent *************
    Agent WARNING: WU client failed Searching for update with error 0xc000000d
    AU >>## RESUMED ## AU: Search for updates [CallId = {9CD5DB56-3B59-4481-90D0-FD1E34D65233}]
    AU # WARNING: Search callback failed, result = 0xC000000D
    AU # WARNING: Failed to find updates with error code C000000D
    AU #########
    AU ## END ## AU: Search for updates [CallId = {9CD5DB56-3B59-4481-90D0-FD1E34D65233}]
    AU #############

    Here is the WER file, which appeared in the application event log as information:

    Version=1
    EventType=WindowsUpdateFailure
    EventTime=130498849873184095
    Consent=1
    ReportIdentifier=73f3eedf-0bf6-11e4-8540-005056960b89
    Response.type=4
    Sig[0].Name=ClientVersion
    Sig[0].Value=7.6.7600.320
    Sig[1].Name=Win32HResult
    Sig[1].Value=c000000d
    Sig[2].Name=UpdateId
    Sig[2].Value=D67661EB-2423-451D-BF5D-13199E37DF28
    Sig[3].Name=Scenario
    Sig[3].Value=Scan
    Sig[4].Name=SourceId
    Sig[4].Value=101
    Sig[5].Name=Environment
    Sig[5].Value=Managed
    DynamicSig[1].Name=OS Version
    DynamicSig[1].Value=6.1.7601.2.1.0.274.10
    DynamicSig[2].Name=Locale ID
    DynamicSig[2].Value=1033
    FriendlyEventName=Windows Update installation problem
    ConsentKey=WindowsUpdateFailure
    AppName=Host Process for Windows Services
    AppPath=C:\Windows\System32\svchost.exe
    ReportDescription=A Windows update did not install properly. Sending the following information to Microsoft can help improve the software.


    • Edited by John Hroch Tuesday, July 15, 2014 8:49 AM
    Tuesday, July 15, 2014 7:59 AM

All replies

  • Hi,

    DeploymentAction='Uninstallation' or IsInstalled=1 and DeploymentAction='Installation' and RebootRequired=1 or IsInstalled=0 and DeploymentAction='Uninstallation' and RebootRequired=1"

    According to the log, it seems that the server is pending a restart.

    Wednesday, July 16, 2014 9:00 AM
  • Hi,

    thank you for your reply...

    I already tried:

    • to restart the server several times -- no success.
    • to stop & disable the Windows Update service and clear c:\SoftwareDistribution folder -- no success
    • reindex the WSUS database and run WSUS cleanup wizard -- no success

    According to our findings the issue is related to RADIUS servers and Domain Controllers, but it is not the common denominator in all the cases (some DCs are updating just fine).


    • Edited by John Hroch Wednesday, July 16, 2014 9:11 AM
    Wednesday, July 16, 2014 9:11 AM
  • I'm sorry to hear you are having issues. I have a few follow up questions:

    1. Have you configured client computers to sync with WSUS over HTTPS?
    2. If so, are you using a self-signed or enterprise-signed certificate? If so, is the certificate trusted by the client computers? Try accessing the WSUS web service URL with a web browser.
    3. Ensure that all TLS settings are in their default configuration on the WSUS server. Changing the TLS configuration, including disabling or enabling non-default versions of TLS, could cause this issue. The proper TLS configuration is documented in the KB article.

    Thanks,
    Ben Herila

    Program Manager, Windows Server

    Wednesday, July 16, 2014 8:43 PM
  • Hi Ben,

    first of all, thank you for your suggestions, I appreciate your help... and now to you questions:

    1. Yes, all clients are configured using GPO to sync with WSUS over HTTPS (custom site 8531).
    2. We are using the certificate signed by our Enterprise CA. The trusted root cert is distributed through AD/GPO; for clients in workgroups cert is distributed manually or alongside with custom image. The WSUS web service URL is accessible and trusted by both affected (non-functional) and functional clients.
    3. I can confirm that TLS 1.0 (and SSL 3.0) are the only protocols enabled, i.e. servers are made from identical image and changing to different protocols has not been done. Fe. we have 2 DCs created on the same day and configured exactly the same way, one is affected by this issue the other works fine.

    Sniffing the communication between the client and WSUS server I can see that the client is able to connect the WSUS server and check for updates. This confirms even our AV system (ESET), which from time to time checks for health of the server and reports if there are any pending updates (...yes, there are some...).

    When I go to Control Panel | Windows Update and check for the updates, the WU agent ends up with above mentioned error (but is able to pinch the WSUS server). Looking in the log on affected servers, there are the same warnings and errors telling me that signature and trust for TMP file in SelfUpdate folder cannot be verified. This is where the process stops with the error.

    It seems that I am not the only one experiencing this issue; take a look here at Charles Aderson's comment.

    Thank you, John.



    • Edited by John Hroch Friday, July 18, 2014 6:24 AM
    Thursday, July 17, 2014 5:42 AM
  • You need a support case opened up?  Holler at susan-at-msmvps.com (change the -at- to @) and I can set one up for you.

    Unfortunately TechNet subscriptions aren't coming back, sorry folks :-(

    Friday, August 1, 2014 8:38 PM
  • Hi, is there any update to this issue?  My Windows 2012 R2 WSUS box has this problem.  I removed the update, and things start working again, but it may have broke updating on Windows 8.1 clients.

    Friday, August 8, 2014 2:55 PM
  • Hi, is there any update to this issue?  My Windows 2012 R2 WSUS box has this problem.  I removed the update, and things start working again, but it may have broke updating on Windows 8.1 clients.


    Hi S. Lee, can you email Susan above to get a support case set up for you free of charge?
    Friday, August 8, 2014 3:06 PM
  • Case set up, will keep everyone in the loop as to what is found.

    Unfortunately TechNet subscriptions aren't coming back, sorry folks :-(

    Friday, August 8, 2014 5:23 PM
  • Thanks. I also pinged the WU client team and they are looking into it.
    Friday, August 8, 2014 5:42 PM
  • OK- to everyone experiencing this issue:

    Are you willing to collect CAPI2 logs while reproducing it? Instructions are below:

    Also, Visual Studio install apparently hits a similar error and there is evidence that a third-party may be messing this up: http://blogs.msdn.com/b/vsnetsetup/archive/2013/10/04/visual-studio-2012-fails-with-an-error-the-pipe-is-being-closed.aspx

    Enabling CAPI2 Logging

    1. Open Event Viewer

    2. Browse to 'Application and Services Logs' > Microsoft > Windows > CAPI2 > Operational.

    3. Right click on 'Operational' in the directory tree, and select 'Enable log'

    4. Reproduce the problem.

    5. Refresh the event display in the event viewer.

    5. Click “Save All Events as …”

    Then upload this file somewhere and post the URL we can access it at.

    Thanks,
    Ben


    Saturday, August 9, 2014 12:16 AM
  • Hello everyone,

    We have the same problem with 3 workstations (out of 120)
    They are the only PCs that have an electronic signature software installed.
    I uninstalled the software on one of them and it reconnects to wsus immediately
    The software used is Entrust Entelligence Security Provider for Windows (like your Visual Studio example above)
    Sorry but no CAPI2 logs for the moment

    Excerpt of the windows update log with the software installed

    Checking for agent SelfUpdate
    2014-07-31 11:21:22:306 648 1208 Setup Client version: Core: 7.6.7600.320  Aux: 7.6.7600.320
    2014-07-31 11:21:24:630 648 1208 Misc Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wuident.cab with dwProvFlags 0x00000080:
    2014-07-31 11:21:36:034 648 1208 Misc Microsoft signed: NA
    2014-07-31 11:21:36:049 648 1208 Misc Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\TMP4F80.tmp with dwProvFlags 0x00000080:
    2014-07-31 11:21:43:334 648 1208 Misc FATAL: Error: 0xc000000d when verifying trust for C:\Windows\SoftwareDistribution\SelfUpdate\TMP4F80.tmp
    2014-07-31 11:21:43:334 648 1208 Misc WARNING: Digital Signatures on file C:\Windows\SoftwareDistribution\SelfUpdate\TMP4F80.tmp are not trusted: Error 0xc000000d
    2014-07-31 11:21:43:334 648 1208 Setup FATAL: Ident cab verification failed with error 0XC000000D
    2014-07-31 11:21:43:334 648 1208 Setup WARNING: SelfUpdate check failed to download package information, error = 0xC000000D
    2014-07-31 11:21:43:334 648 1208 Setup FATAL: SelfUpdate check failed, err = 0xC000000D
    2014-07-31 11:21:43:334 648 1208 Agent  * WARNING: Skipping scan, self-update check returned 0xC000000D
    2014-07-31 11:21:43:334 648 1208 Agent  * WARNING: Exit code = 0xC000000D


    Excerpt of the log when the software is uninstalled

    Checking for agent SelfUpdate
    2014-08-11 13:55:54:999 648 278 Setup Client version: Core: 7.6.7600.320  Aux: 7.6.7600.320
    2014-08-11 13:55:57:307 648 278 Misc Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wuident.cab with dwProvFlags 0x00000080:
    2014-08-11 13:55:57:338 648 278 Misc Microsoft signed: NA
    2014-08-11 13:55:57:338 648 278 Misc Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\TMP9388.tmp with dwProvFlags 0x00000080:
    2014-08-11 13:55:57:354 648 278 Misc Microsoft signed: NA
    2014-08-11 13:55:57:354 648 278 Misc Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wsus3setup.cab with dwProvFlags 0x00000080:
    2014-08-11 13:55:57:354 648 278 Misc Microsoft signed: NA
    2014-08-11 13:55:57:354 648 278 Misc Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wsus3setup.cab with dwProvFlags 0x00000080:
    2014-08-11 13:55:57:354 648 278 Misc Microsoft signed: NA
    2014-08-11 13:55:57:369 648 278 Setup Determining whether a new setup handler needs to be downloaded
    2014-08-11 13:55:57:369 648 278 Setup SelfUpdate handler is not found.  It will be downloaded
    2014-08-11 13:55:57:369 648 278 Setup Evaluating applicability of setup package "WUClient-SelfUpdate-ActiveX~31bf3856ad364e35~amd64~~7.6.7600.320"
    2014-08-11 13:55:57:369 648 278 Setup Setup package "WUClient-SelfUpdate-ActiveX~31bf3856ad364e35~amd64~~7.6.7600.320" is already installed.
    2014-08-11 13:55:57:369 648 278 Setup Evaluating applicability of setup package "WUClient-SelfUpdate-Aux-TopLevel~31bf3856ad364e35~amd64~~7.6.7600.320"
    2014-08-11 13:55:57:385 648 278 Setup Setup package "WUClient-SelfUpdate-Aux-TopLevel~31bf3856ad364e35~amd64~~7.6.7600.320" is already installed.
    2014-08-11 13:55:57:385 648 278 Setup Evaluating applicability of setup package "WUClient-SelfUpdate-Core-TopLevel~31bf3856ad364e35~amd64~~7.6.7600.320"
    2014-08-11 13:55:57:400 648 278 Setup Setup package "WUClient-SelfUpdate-Core-TopLevel~31bf3856ad364e35~amd64~~7.6.7600.320" is already installed.
    2014-08-11 13:55:57:400 648 278 Setup SelfUpdate check completed.  SelfUpdate is NOT required.

    The problem is definitely around third-parties software 

    Thanks

    Joce

    Tuesday, August 12, 2014 1:22 AM
  • We're starting August patching, so I have no time to verify ATM, but this makes sense.  We have Entrust installed on some computers (maybe 1/4 to 1/3), which roughly correlates to the number of WSUS failures.  I won't have time to test this for a while, unfortunately.

    Tuesday, August 12, 2014 8:00 PM
  • Hi Ben,

    here is the link for the CAPI2 log: http://1drv.ms/1sUGsvA

    Thx, John.

    Wednesday, August 13, 2014 10:29 AM
  • We also have Entrust installed on 100% of our clients, plus a minimal ESP install on the WSUS server itself to handle automatic certificate renewals.

    Further testing has revealed that updating ESP on the clients will resolve the issue. We had failures on 9.2.70.3292 that went away on 9.2.140.3464.

    • Edited by C.Anderson Thursday, August 14, 2014 6:39 PM
    Wednesday, August 13, 2014 7:05 PM
  • I can now confirm that combining latest WSUS patch with Entrust ESP for Windows (v9.10.0000) causes failty behaviour described above.

    Uninstalling the Entrust ESP for Win on WS2008R2SP1 servers and restarting OS resolved the issue for me, but it is not definitely ideal solution; especially for those relying on Entrust CA (...we swiched to MS CA for server machines...)

    Newer version of Entrust ESP for Win (>=9.20) installed on client OS do not seem to cause any issues, but I haven't tested it on server OS.


    • Edited by John Hroch Thursday, August 14, 2014 9:33 AM
    Thursday, August 14, 2014 9:28 AM