none
New updates (KB2633870 & KB2600217) failing with code 800B010B. Here we go yet again...

    Question

  • Dear Microsoft

    Here we go again... you issue an update to fix bugs / improve security.... we spend money and time downloading and installing those updates when themselves need debugging as they fail to install.

    Just like many other cases:

    I'm sorry but there has been ample time and community reports to fix these .NET install / update issues delivered via WSUS. I simply cannot afford to spend hours trying to figure out what fix is required this time and then to go and apply that manually to the 40+ servers on which this is failing.

    I'm not asking what the manual fix for the above issue is - I don't care anymore. I'm expecting the quality assurance team to pull out their finger and get to grips with these problems and work with your product teams to get these updates working properly through WSUS. Issue a revision to the updates and have them install successfully.

    Surely the great Microsoft can handle that? It is your updates for your software delievered through your software into hardware running your software. We the public are getting tired of fixing the same problem over and over, some don't get paid for it and it is becoming an intellectually wasteful past time.

    Rant over, but I'm serious about fixing the root cause instead of "plugging the hole" in each update on each computer.

    Friday, March 09, 2012 1:02 AM

Answers

  • Your policy settings are what is causing this problem, specifically "5) Offline revocation server OK (Commercial)..... FALSE".  After I made this setting on my machine I was able to reproduce the error you see.  I do see the inconsistency between 2633870 and 2600217 but I cannot see what would cause this.  I have reached out to the codesigning team at MSFT to see if they can determine the reason for the discrepency.

    The root cause for the need to cache CRLs is that .NET updates validate their payload using a flag that tells wintrust not to go to the internet when verifying the signature. 

    I have an open question to the codesigning team about best practices for populating the CRL cache.

    -Eric

    PS: I found the URLs to force cache by running clearing the CRL cache with certutil then running signtool verify /pa on a connected machine, then saw which CRLs got cached.  You can also do this by manually expecting the CRL Distribution Point property for each cert up chain, and the timestamp counter signature.

    • Marked as answer by Jaans Friday, March 23, 2012 6:17 AM
    Friday, March 23, 2012 3:32 AM
  • Hi Jaans,

    Thanks for the logs.  I think I understand the error you are hitting, its related to CERT_E_REVOCATION_FAILURE above.  Certificates are timestamped, the timestamp is used to verify that the file was signed within the valid period of the signing certificate.  The timestamp itself is a countersignature and will have a revocation list.  I didn't catch this in my first reply because the default settings on my machine were not to check the revocation list on the timestamp signer (you can view your system policy settings using the "setreg" tool).

    0x80096005 (TRUST_E_TIME_STAMP)

    As a generic workaround to all of the failures I have mentioned you can use the signtool.exe tool in the Windows SDK.  Running 'signtool.exe verify /pa <pathToPatch>' will verify the signature patch and automatically pull down CRLs and missing root certs.

    Hope this helps!

    Eric

    • Marked as answer by Jaans Thursday, March 22, 2012 2:44 AM
    Wednesday, March 21, 2012 3:00 PM
  • A couple things can cause 800B010B for .Net updates.  If you check the log for the patch (%TEMP%\KB*.html) you should be able to find a more specific error that was returned by WinVerifyTrust when .Net setup tried to check the signature on the file.  You'll see a statement such as "Signature verification for file <filename> (<filepath>) failed with 0x<error>".  Based on the value of <error> you can take additional steps to avoid the issue.

    0x800b010e (CERT_E_REVOCATION_FAILURE)

    0x800b010a (CERT_E_CHAINING) or 0x800b0109 (CERT_E_UNTRUSTEDROOT).

    If you see a different failure, or these options don't help please collect the logs as described here http://www.microsoft.com/download/en/details.aspx?id=12493 and let us know.

    Regards,

    Eric

    • Marked as answer by Jaans Thursday, March 22, 2012 2:44 AM
    Tuesday, March 20, 2012 9:43 PM

All replies

  • What is the .NET4 application that you are using in your enterprise?

    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin

    Friday, March 09, 2012 4:27 AM
    Moderator
  • It does not matter what applications we are using that depends on the .NET 4 framework.
    What matters is that we need the .NET 4.0 Framework installed on these servers.

     The REAL issue is that Microsoft's Updates for their .NET 4 framework doesn't work properly.

    Friday, March 09, 2012 4:59 AM
  • What matters is that we need the .NET 4.0 Framework installed on these servers.

    Fair enough. But until somebody calls PSS and opens a TICKET relating to these alleged defects AND they can be reproduced in the Microsoft Labs -- posting your complaint in this forum is just blowing smoke up a tree.

    *WSUS* is not responsible for *CONTENT*; WSUS is merely the delivery mechanism, and there's nothing we can do in this forum to assist you with installation issues. Once the installer is on the client system, and the WUAgent kicks off that installation -- WSUS and the WUAgent are out of the picture, and it's solely a product issue beyond that.

    If you want to complain about the content then you need to direct those complaints to the forum where the content people are found -- i.e. the MSDN .NET Framework forums and/or PSS. So far, yours is the first (and only) complaint I've seen about these behaviors with these updates. Three of those four errors actually suggest a certificate defect on the target system. If those really were package defects, I trust you a LOT of people would be commenting on something like that -- but, so far, yours is the only one I've seen.

    As a specific example, KB2656351 was released at the end of December -- over two months ago. I just did a search on the PatchManagement.org mailing list (which I subscribe to and read religiously), and nary a single person has offered any indication that they've had any issues with that update since its release.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin

    • Proposed as answer by Travis Plunk [MSFT] Tuesday, March 13, 2012 2:33 AM
    • Marked as answer by Clarence ZhangModerator Thursday, March 15, 2012 3:06 AM
    • Unmarked as answer by Jaans Thursday, March 22, 2012 2:44 AM
    • Unproposed as answer by Jaans Thursday, March 22, 2012 2:45 AM
    Friday, March 09, 2012 10:52 PM
    Moderator
  • Lawerence

    I have over 30 customers that have the exact issue on the net framework,,uninstall, reinstall,, no matter what you do,,, still fails.  

    This problem reminds me of the Windows Installer service in Windows 7 not being able to be accessed... just another problem MS has...

    i'll take your advice and post this in the correct forum.  Regards,  Chris

    Thursday, March 15, 2012 3:09 PM
  • A couple things can cause 800B010B for .Net updates.  If you check the log for the patch (%TEMP%\KB*.html) you should be able to find a more specific error that was returned by WinVerifyTrust when .Net setup tried to check the signature on the file.  You'll see a statement such as "Signature verification for file <filename> (<filepath>) failed with 0x<error>".  Based on the value of <error> you can take additional steps to avoid the issue.

    0x800b010e (CERT_E_REVOCATION_FAILURE)

    0x800b010a (CERT_E_CHAINING) or 0x800b0109 (CERT_E_UNTRUSTEDROOT).

    If you see a different failure, or these options don't help please collect the logs as described here http://www.microsoft.com/download/en/details.aspx?id=12493 and let us know.

    Regards,

    Eric

    • Marked as answer by Jaans Thursday, March 22, 2012 2:44 AM
    Tuesday, March 20, 2012 9:43 PM
  • Hi Eric

    First of all, thank you for taking ownership and for you help. Your reply is succint and very helpful because it tells us where to look for the relevant log file, what to look for in the log file and some suggestions to help diagnose.

    I made sure the machine has an updated certification revocation list cache by running the commands you referred to above. And the servers are all Windows Server 2008 R2 servers, so the "Automatic Root Update mechanism" *should* be taking taking care of that part. I cleared the %temp% folder and reattempted the installation and it failed.

    Looking at the %temp%\KB2633870*.html log file and then found the following:

    [3/21/2012, 4:22:12]c:\40f6b9b9585d880fc0\NDP40-KB2633870.msp - Signature verification for file NDP40-KB2633870.msp (c:\40f6b9b9585d880fc0\NDP40-KB2633870.msp) failed with error 0x80096005 (The timestamp signature and/or certificate could not be verified or is malformed.)
    [3/21/2012, 4:22:12]No FileHash provided. Cannot perform FileHash verification for NDP40-KB2633870.msp
    [3/21/2012, 4:22:12]File NDP40-KB2633870.msp (c:\40f6b9b9585d880fc0\NDP40-KB2633870.msp), failed authentication. (Error = -2146869243). It is recommended that you delete this file and retry setup again.
    [3/21/2012, 4:22:12]Failed to verify and authenticate the file -c:\40f6b9b9585d880fc0\NDP40-KB2633870.msp
    [3/21/2012, 4:22:12]Please delete the file, c:\40f6b9b9585d880fc0\NDP40-KB2633870.msp and run the package again
    ...
    [3/21/2012, 4:22:13]Final Result: Installation failed with error code: (0x800B010B), "Generic trust failure. "(Elapsed time: 0 00:00:01).

    The same issue applies to KB2600217.

    I also downloaded the KBs and manually tried an update just to rule out that the ones coming from WSUS weren't corrupted, but the same error happened with these too.

    What do you think? Something wrong with the automatic root update mechanism perhaps? Is there a way to force an update / check logs etc.

    Ps: Where should I send the "collect" results .CAB file to?
    • Edited by Jaans Wednesday, March 21, 2012 2:47 AM Added PS
    Wednesday, March 21, 2012 2:41 AM
  • Hi Jaans,

    You can send the cab (%TEMP%\vslogs.cab) to netfxsetup_at_microsoft_dot_com  (Alias: netfxsetup)

    Thanks,

    Vivek Mishra - MSFT


    Vivek Mishra - MSFT

    Wednesday, March 21, 2012 6:11 AM
  • Thanks. I just sent it.
    Wednesday, March 21, 2012 6:26 AM
  • Hi Jaans,

    Thanks for the logs.  I think I understand the error you are hitting, its related to CERT_E_REVOCATION_FAILURE above.  Certificates are timestamped, the timestamp is used to verify that the file was signed within the valid period of the signing certificate.  The timestamp itself is a countersignature and will have a revocation list.  I didn't catch this in my first reply because the default settings on my machine were not to check the revocation list on the timestamp signer (you can view your system policy settings using the "setreg" tool).

    0x80096005 (TRUST_E_TIME_STAMP)

    As a generic workaround to all of the failures I have mentioned you can use the signtool.exe tool in the Windows SDK.  Running 'signtool.exe verify /pa <pathToPatch>' will verify the signature patch and automatically pull down CRLs and missing root certs.

    Hope this helps!

    Eric

    • Marked as answer by Jaans Thursday, March 22, 2012 2:44 AM
    Wednesday, March 21, 2012 3:00 PM
  • Hi Eric

    Thank you for your help.

    Running the following commands to update the CRL lists fixes the problem only for KB2633870. Unfortunately this doesn't work for KB2600217:
      certutil -URLCache -f http://crl.microsoft.com/pki/crl/products/microsoftrootcert.crl
      certutil -URLCache -f http://crl.microsoft.com/pki/crl/products/MicCodSigPCA_08-31-2010.crl
      certutil -URLCache -f http://crl.microsoft.com/pki/crl/products/MicrosoftTimeStampPCA.crl

    I had to find the setreg tool where the Windows/.NET 1.1 SDK had been installed, but I could then copy the setreg.exe to the servers to run it.
    The setreg tool returned different values than what the MSDN pages state the default values are. Most notably the following values:
    Software Publishing State Key Values (0xc9):
       1) Trust the Test Root........................... FALSE
       2) Use expiration date on certificates........... TRUE
       3) Check the revocation list..................... TRUE
       4) Offline revocation server OK (Individual)..... FALSE
       5) Offline revocation server OK (Commercial)..... FALSE
       6) Java offline revocation server OK (Individual) FALSE
       7) Java offline revocation server OK (Commercial) FALSE
       8) Invalidate version 1 signed objects........... FALSE
       9) Check the revocation list on Time Stamp Signer TRUE
      10) Only trust items found in the Trust DB........ FALSE

    Trying to interpret the values, it would seem that with 4,6 set to false and 9 to true will be more "secure".
    Interestingly when I run the certutil without -f (force) option the response is "*****  OFFLINE  ******. I guess this could relate to items 4 and 6, but now I starting to grasp at straws I know too little about.

    Could it be that these settings are the cause for the issues? I thought these are set via Active Directory Group Policies (or something else)? The strange thing looking at GPResult I could not find anything that looks like it affects this. Also this is only happens with some servers that are under the same GP policies as other where it works.

    Next step, running the "signtool.exe verify /pa" against the package. So I proceed to manually download the individual KB updates and when I run it against KB2633870 the response is "Successfully verified". But when I run it against KB2600217 then I get the following failure:

      SignTool Error: WinVerifyTrust returned error: 0x800B010E
            The revocation process could not continue - the certificate(s) could not be checked.

    Perhaps the above explains something of the underlying problem?


    In summary, by using the certutil utility we've managed to workaround one of the problems (KB2633870), but KB2600217 still is an issue.

    Bigger picture:
    Running the above commands on many multiple servers isn't easy administration and seems to be fixing a symptom and not the problem.
    I guess what I trying to get at is what is the root cause; why is this happening / the certificate validation not being done as it should be?
    Any ideas on how to avoid this problem?

    PS: How did you know which URL's to use with the certutil?

    Thursday, March 22, 2012 2:44 AM
  • Your policy settings are what is causing this problem, specifically "5) Offline revocation server OK (Commercial)..... FALSE".  After I made this setting on my machine I was able to reproduce the error you see.  I do see the inconsistency between 2633870 and 2600217 but I cannot see what would cause this.  I have reached out to the codesigning team at MSFT to see if they can determine the reason for the discrepency.

    The root cause for the need to cache CRLs is that .NET updates validate their payload using a flag that tells wintrust not to go to the internet when verifying the signature. 

    I have an open question to the codesigning team about best practices for populating the CRL cache.

    -Eric

    PS: I found the URLs to force cache by running clearing the CRL cache with certutil then running signtool verify /pa on a connected machine, then saw which CRLs got cached.  You can also do this by manually expecting the CRL Distribution Point property for each cert up chain, and the timestamp counter signature.

    • Marked as answer by Jaans Friday, March 23, 2012 6:17 AM
    Friday, March 23, 2012 3:32 AM
  • Thanks Eric - that helps.

    The only way I could get it to work is if I use the SetReg tool to change the setting in question.

    I'm a little at a loss as to what the full implication of that setting change will be.
    Also, I wonder how / what made a change to the setting in the first place?

    Friday, March 23, 2012 6:17 AM
  • Dear Microsoft

    Here we go again... you issue an update to fix bugs / improve security.... we spend money and time downloading and installing those updates when themselves need debugging as they fail to install.

    Just like many other cases:

    I'm sorry but there has been ample time and community reports to fix these .NET install / update issues delivered via WSUS. I simply cannot afford to spend hours trying to figure out what fix is required this time and then to go and apply that manually to the 40+ servers on which this is failing.

    I'm not asking what the manual fix for the above issue is - I don't care anymore. I'm expecting the quality assurance team to pull out their finger and get to grips with these problems and work with your product teams to get these updates working properly through WSUS. Issue a revision to the updates and have them install successfully.

    Surely the great Microsoft can handle that? It is your updates for your software delievered through your software into hardware running your software. We the public are getting tired of fixing the same problem over and over, some don't get paid for it and it is becoming an intellectually wasteful past time.

    Rant over, but I'm serious about fixing the root cause instead of "plugging the hole" in each update on each computer.

    I keep having issues and tried to trouble with several updates.  These are the same updates I've had problems d/l since January.  These include KB2633870, KB2656351, KB2656368, & KB2600217.  Can you please issue a fix for these?  I did see these are important to d/l.  Plus, I tried to troubleshoot to fox the issues but it didn't work. 

    Thanks Cherie Peach

    Wednesday, April 25, 2012 1:50 PM
  • Any progress on this?  I've been fighting this as well and had read anecdotal information that a GPO was the culprit.

    Here's another thread on a different forum that I made that has a bit more info in it.  KB2656351, KB2656368, KB2600217 all fail, all are .NET 4 updates.  I ran the CAPI2 tool on a Win7 box to get some more details though I don't know what they are telling me that's useful.

    http://techreport.com/forums/viewtopic.php?f=6&t=81352

    I'd rather have a solution like, "change this GPO and it'll work!" than have to do something that I need to manually do on every workstation in the organization.

    Here's what I have:

    Software Publishing State Key Values (0xc9):
       1) Trust the Test Root........................... TRUE
       2) Use expiration date on certificates........... TRUE
       3) Check the revocation list..................... TRUE
       4) Offline revocation server OK (Individual)..... FALSE
       5) Offline revocation server OK (Commercial)..... FALSE
       6) Java offline revocation server OK (Individual) FALSE
       7) Java offline revocation server OK (Commercial) FALSE
       8) Invalidate version 1 signed objects........... FALSE
       9) Check the revocation list on Time Stamp Signer TRUE
      10) Only trust items found in the Trust DB........ FALSE

    • Edited by superproz Tuesday, May 08, 2012 5:22 PM added setreg info
    • Proposed as answer by Bent Schrader Wednesday, May 09, 2012 12:03 PM
    • Unproposed as answer by Bent Schrader Wednesday, May 09, 2012 12:03 PM
    Tuesday, May 08, 2012 4:18 PM
  • Hi there,

    I solved my problems regarding the KB2656351, KB2656368 and KB2600217 - I wrote an solution guide on my blog:http://bent-blog.de/fehler-80070643-und-800b010b-bei-microsoft-net-4-windows-updates-kb2656351-kb2656368-und-kb2600217/

    The key is to change the Software Publishing State Key Value within the registry:

    [HKCU\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing]

    Change the DWORD Key "State" with value 0xc9 to the value 0x22849. See my blog post for further information (It's in german language but google will help you translate it).

    Regards,

    Bent

    • Proposed as answer by Bent Schrader Wednesday, May 09, 2012 12:09 PM
    Wednesday, May 09, 2012 12:09 PM
  • This appears to be exactly it.  For those German-impaired: 

    http://translate.google.com/translate?sl=auto&tl=en&js=n&prev=_t&hl=en&ie=UTF-8&layout=2&eotf=1&u=http%3A%2F%2Fbent-blog.de%2Ffehler-80070643-und-800b010b-bei-microsoft-net-4-windows-updates-kb2656351-kb2656368-und-kb2600217%2F

    It's some kind of crazy hex bitmask.

    Yes, to get TRUE you must use negative values on some of them.

     1) Trust the Test Root........................... TRUE  0xA0
     2) Use expiration date on certificates........... TRUE -0x100
     3) Check the revocation list..................... TRUE -0x200
     4) Offline revocation server OK (Individual)..... TRUE  0x400
     5) Offline revocation server OK (Commercial)..... TRUE  0x800
     6) Java offline revocation server OK (Individual) TRUE  0x1000
     7) Java offline revocation server OK (Commercial) TRUE  0x2000
     8) Invalidate version 1 signed objects........... TRUE  0x10000
     9) Check the revocation list on Time Stamp Signer TRUE -0x20000
    10) Only trust items found in the Trust DB........ TRUE  0x40000

    I don't understand exactly how this bitmask works.  It hurts my head with the negative values.  I guess the baseline is 0x20300 instead of 0x00.

    At some point someone who set up the domain said, "these values are for SECURITY!" and for only .NET 4 it jacks up the updates.  I might take a gander at something like http://www.nsa.gov/ia/_files/app/I731-008R-2006.pdf to see if I can understand more about what these settings do and what risks are involved with our current default settings.

    Anyway, the fact that Bent found the right key to manipulate gives me hope that we can deploy this via a GPO and call it done.  I kinda agree with Jaans that this should be addressed--why do no other .NET versions have this issue?  And why are organizations running into this issue?  Not a problem for regular users, just businesses.  Bent gives us hope for a decent workaround but in the end it's still a workaround.

    Bent's post should be listed as the answer for now.

    Wednesday, May 09, 2012 8:24 PM
  • Hi,

    just to explain how I came to those values. The first hex mask 0x22849 is the result after changing all setting as described on Microsoft's website for the DEFAULT values: http://msdn.microsoft.com/en-us/library/windows/desktop/aa387700(v=vs.85).aspx

    But the default "State" value on a "fresh" machine/user profile is 0x23c00! So it's different from Microsofts recommendations - really strange.

    Nevertheless I still have no idea who is responsible for the change to 0xc9 (or better the setting no# 5 Offline revocation server OK (Commercial)), which causes the .NET update problems.

    Regards,

    Bent

    Thursday, May 10, 2012 9:14 AM
  • And in checking on two freshly installed and fully updated/patched machines, one XP SP3 and one Win7 Enterprise x64, they both have 0x23C00 as you have also seen.  I know some IE settings overlap this registry key:

    Check for publisher's certificate revocation TRUE -0x200

    But also there may be some undocumented settings found in WinTrust.h:

    #define WTPF_TRUSTTEST              0x00000020  // trust any "TEST" certificate
    #define WTPF_TESTCANBEVALID         0x00000080  //
    Check any test certificate for validity

    Assuming those are valid, that leaves me with 0x09 that I can't account for in my GPO.  If it were a bitmask, I'd guess it'd be 0x08 and 0x01.  I am trying to figure out how to hunt those settings down.


    • Edited by superproz Thursday, May 10, 2012 9:33 PM Added comment on 0x80
    Thursday, May 10, 2012 4:08 PM
  • BTW, I came up with a different value for the default settings.  I manually set the registry key to 0x00 and then used setreg to get the following:

    Updated Software Publishing State Key Values (0x22800):

       1) Trust the Test Root........................... FALSE

       2) Use expiration date on certificates........... TRUE

       3) Check the revocation list..................... TRUE

       4) Offline revocation server OK (Individual)..... FALSE

       5) Offline revocation server OK (Commercial)..... TRUE

       6) Java offline revocation server OK (Individual) FALSE

       7) Java offline revocation server OK (Commercial) TRUE

       8) Invalidate version 1 signed objects........... FALSE

       9) Check the revocation list on Time Stamp Signer FALSE

      10) Only trust items found in the Trust DB........ FALSE

    I am not sure where you got the 0x49 from but it's probably some other random setting in IE or who knows what. 

    Thursday, May 10, 2012 5:10 PM
  • Ok, is this a bug, then?  Take a look at this:  http://social.technet.microsoft.com/Forums/en-CA/winserverGP/thread/a2f5ae71-c4e8-4523-8817-dbc9161396a1

    Same issue we're seeing here.  Relevant quote:

    The point is we are trying to set the following advanced options in IE7 to disabled:

    •Check for publisher's certificate revocation
    •Check for server certificate revocation

    Creating this gpo supposedly should set the following registry key:

    HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing

    •default setting (both settings enabled): 0x00023c00 (166432)
    •after manually setting both disabled: 0x23e00 (146944)
    •after applying the GP preference settings: 0x002c9 (713)

    ...yup.  So applying these in the GPO, the 0x200 one applies fine but something else just totally wipes out the other values and adds 0xC9 instead.  It could be that there's really no mystery settings in the low range of the bitmask but some field overrun might be the cause.  Using process monitor from sysinternals shows that messing with various other IE settings does touch this registry key but all it does is read the key and write the same value, then write a value to a totally different key in a different location.  If it is a bug in applying GPOs or some IE GPOs specifically, what would be the next step to get MS to look into this?  We're on a Win2K8 R2 network here using XP SP3 and Win7 Pro x64 workstations.

    Thursday, May 10, 2012 9:41 PM
  • Hi,

    same Problem with WIN7.

    uncheck only these Options in IE

    •Check for publisher's certificate revocation
    •Check for server certificate revocation

    Now updates insalled without error. Perfect, thanks!

    Stefan

    Sunday, June 10, 2012 10:23 AM
  • So, in simple ... whydo  I have a 85 GB virtual partition (brother to a long lived cock roach) on my system which I don't conciously remember authorizing, or even worse, it seems to be the root cause of my having to format and rebuild a workstation which I use for deployment and other administrative actions. The partition seems to survive, regardless of my efforts done under "extreme sanction".

    I was and may still end up installing a new drive. I have

    It is an irritant, wasting disk space and an intrusion. So is it also dangerous? Will something important fail?  

    windows 7, Ultimate ver. dated 1/05/11. so far: ran ERD Commander (6.5/7.0)to format drives, rebuild volumes partitions and yet is still returns?


    Yes, ... that Beoweolf


    • Edited by Beoweolf Thursday, June 21, 2012 5:37 PM
    Thursday, June 21, 2012 5:31 PM
  • Hi,
    Use MS FixIT --> http://support.microsoft.com/kb/971058
    BR,
    //Rolands
    Monday, November 05, 2012 10:26 AM
  • Open command prompt as administrator and run the following command
    "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\setreg.exe"
    
    This will list out teh Software Publishing State Key values. 
    
    If either items 3) or 9) are set to true then you may need to change their values to false using the following two commands
    
    "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\setreg.exe" 3 false
    "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\setreg.exe" 9 false
    
    You should then be able to run the patch installation
    
    When the installation is complete, you should run the following two commands if the values of items 3) and 9) were originally set to true
    "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\setreg.exe" 3 true
    "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\setreg.exe" 9 true

    
    Tuesday, November 20, 2012 5:43 PM
  • Just wanted to throw this out there that a certain TLA organization requires this to be set to a rather strict value.  A value so strict you can't install or update .NET components after doing so.  To work around this I've created a set of .reg files that allow me to swap between the secure value and the value that allows me to install updates.  However where their settings differ is you're digging into more places than just the one discussed.

    HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing\State

    You also have to dig into HKU in addition to HKCU to undo these changes.

    HKEY_USERS\S-1-5-18\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing\State
    HKEY_USERS\S-1-5-19\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing\State
    HKEY_USERS\S-1-5-20\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing\State

    If you don't touch those as well then you will continue to have installation failures.


    Systems Administrator Senior - University of Central Florida

    Monday, February 04, 2013 6:36 PM
  • On Windows Server 2008 32-bit Log in to Regedit and browse to the

    HKEY_Current_User\Software\Microsoft\Windows\CurrentVersion\WinTrust\TrustProviders\Software Publishing

    Change the State Value data from c9 (or whatever it has changed from) to 23c00 for value data- Base on Hexadecimal - Decimal should be at 146432

    Updates installed successfully!

    Wednesday, March 06, 2013 9:50 PM
  • Thank you so much for this solution.  It's been bugging me on several servers for months.  All .NET 4 updates now installed correctly.
    Wednesday, May 08, 2013 6:04 AM
  • Great Highlander,

    I am having the same problem installing Microsoft .NET Framework 4 Client Profile for Windows 7 x64-based Systems (KB982670).

    My Laptop Lenovo is running Windows7. Because virus, I restored back to old image created 2 years ago. When I did the Windows Update, I ran into this problem. Found the forum, and tried changing registry HKEY_Current_User\Software\Microsoft\Windows\CurrentVersion\WinTrust\TrustProviders\Software Publishing

     c9 and 23c00 , nothing works so far.

    Can you tell me how to resolve this issue for windows 7? Where to uncheck the options in IE, in registry table?

    Thanks.

    Friday, November 15, 2013 4:11 AM
  • You saved my day! This solved the problem with several updates I could not install! :-)
    Friday, August 01, 2014 12:22 PM