Windows Update fails with 8000FFFF (E_UNEXPECTED)

Quick Solution:  Check the permissions on  the root of C: and ensure that BUILTIN\Users have Read access.

Long Story:

8000FFFF == E_UNEXPECTED, not very helpful…

Had a client where windows update was continually failing with the error code 8000FFFF.  When looking in the Windows Update log we’d see errors like this:

WARNING: PTError: 0x80248014
Handler FATAL: CBS called Error with 0x8000ffff, <— Checked the CBS.log file but that didn’t give any clues.
Handler FATAL: Error source is 106.
DnldMgr Error 0x8000ffff occurred while downloading update; notifying dependent calls.
AU        # WARNING: Download failed, error = 0x8000FFFF
AU        # WARNING: Download failed, error = 0x8000FFFF
AU      WARNING: BeginInteractiveInstall failed, error = 0x8024000C
CltUI   WARNING: AU directive Interactive Progress is exiting due to error 8024000C


And in the event viewer upon each run we’d see these events:

Log Name:      Application
Source:        ESENT
Date:          7/2/2008 3:05:16 PM
Event ID:      491
Task Category: General
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      XXXX
Catalog Database (1560) Catalog Database: An attempt to determine the minimum I/O block size for the volume "C:\" containing "C:\Windows\system32\CatRoot2\" failed with system error 5 (0x00000005): "Access is denied. ".  The operation will fail with error -1032 (0xfffffbf8).

Log Name:      Application
Source:        Microsoft-Windows-CAPI2
Date:          7/2/2008 3:05:16 PM
Event ID:      257
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      XXXX
The Cryptographic Services service failed to initialize the Catalog Database. The ESENT error was: -1032.

After seeing this data I did a stare and compare between my root permissions and his and found that he’d modified the c:\ permissions on his system:

His machine:
c:\temp\xcacls c:

C:\>xcacls c:\
c:\ BUILTIN\Administrators:F
    BUILTIN\Users:(OI)(CI)R <— This is the key one missing that was causing the headache.
    NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)C
    NT AUTHORITY\Authenticated Users:(special access:)

The Cryptographic Services runs under “Network Service” which would require Users to have read access.  I added BUILTIN\Users with read access to C and all worked again.

Hopefully this post will guide others with similar issues to the solution quickly.


Comments (53)
  1. Anonymous says:

    Recently, I was helping a colleague troubleshoot an installation error in the .NET Framework 3.5 SP1

  2. Anonymous says:

    yep – saved me too – thanks

  3. BooRadely says:

    Careful though, you can always crew up omre stuff if you adjust permissions on the root and then apply it to all folder/subfolders.  

    Make sure you backup that machine before doing this!

  4. Mark-NC says:

    This has been plaguing me for over a month. Never would have connected the Cryptographic problem with this. Great article, nice work!

  5. BooRadely says:

    @scott:  The fix is to add BUILTINUsers to the ACL on the C drive and give it read access.  If you dont understand what this means I'd suggest finding someone to help you as adjusting the permissions can be dangerous (if done wrong).    If you're familar with Windows, then it's simply going to the security tab and adding in BUILTINUsers.

  6. BooRadely says:

    @scott, thje windows update does not run as your account.  The Cryptographic Services runs under “Network Service” which would require Users to have read access.

  7. BooRadely says:

    That’s why I put ’em out here!

  8. Vipe says:

    Thanks , solved my problem, hardening W2K8 is not that straight forward.

  9. brentil says:

    I spent a bunch of time hunting around trying to find a solution to this issue.  We remove the Users group from the root of our servers but don’t cascade the change down on the system drive.  We’ve done this with NT4, Win2000 Server, Win2003 Server, and thought we’d be able to do it with Win2008 Server but apparently not.

    Adding it back in worked like a charm, however I don’t necessarily like having it there.  If I knew exactly where else it belonged I’d prefer to just add it to the needed directories.

  10. Chris Walsh says:

    Any tech note / kb from Microsoft on this issue?

    I am going to try this now and if it works, remove the BUILTINUsers (R) from root again.

    Hopefully, it is a one off for updates.

  11. Jon Nolen says:

    I spent a lot of time trying to research this, and finally something works!  Thanks!!!

  12. mike says:

    I’ve been looking everywhere for a resolution to this problem.  Finally a solution that works.

    Thanks for the opening line about root security – rather stupitly I removed local user read rights

  13. Simon K says:

    Thank you very much for this.. I couldn’t work out why either, and most people have no idea what they are talking about, or post irrelevant information.

    This was spot on, cheers!

  14. andres says:

    dude you are the man!!.. wasted 2 hours on this and finally worked.

  15. Eric says:

    Thank you soooo much! I spent almost all day trying to figure this out!

    I never would have figured this out!! You saved my day and about 100 hours! Thanks again!

  16. RP says:

    Wow…. after MONTHS of searching, finally an answer that works! We removed the Users group from the root for security purposes, and that’s been stopping our updates since February!!

    THANK YOU!!!!!!

  17. james says:

    Dude you freaking ROCK!!! I’m sitting here in the middle of Afghanistan with limited everything and I have been messing with this for a week now. Found your blog and fixed it in 1 minute. Thank You!!!

  18. Randall says:

    I agree you rock, I’ve been messing with this error for a couple months off and on.

  19. Unis says:

    Thank you very much for this.. You Rock ||

  20. CS says:

    You are great! Thank you so much for posting this!

  21. NADEEM says:

    Thanks for the Quick Solution, it worked with my Windows 2008 SP1 x64 server

  22. uk says:

    you sir a genius, thanks a million 🙂

  23. ML49448 says:

    good job,

    this advice saved a lot of time


  24. Daniel B says:

    Grand, thanks for this post it saved me from a huge headache.

  25. Grateful Windows Admin says:

    This guy needs a buy me a beer button.  Thank you!

  26. bridantay says:

    Even microsoft havent worked this one out yet

  27. mohamed mahmoud says:

    please write the solution again please

  28. Tyler says:

    Awesome.  Finally a fix that worked.  Great job.

  29. sAnTos says:

    Yes, it's works, but… I don't want that users of my domain have read acces to some folders. Could it be possible changing Cryptographic Services to work under Local system account instead of Network Service? I did it with DNS Server by the same problem and it works.

  30. jim says:


  31. Monica says:

    Checked… Mine has

    BUILTINUsers: (OI)(CI)(RX)

    And it's having problem when updating. More specifically, installing the Vista SP2. Any clue?

  32. Matthew says:

    Yay, thanks so much for this!!!  Now, if only I understood what this meant I could finally install SP2…. Can anyone explain for us stupid people 😀  Simple step-by-step directions such as checking if I even have this thing to begin with.  It'd be much appreciated!

  33. Steve Ruffin says:

    That worked. Thanks!

  34. abdul says:


    i think i am missing the picture. Is servernameusers the same as builtinusers? If not, then how do I add builtinusers. I tried to add builtinusers and chose the local server in the "from this location" box and could not add in builtinusers

  35. Rolly says:


    I'm in the same boat and would appreciate if someone could help me with how to restore the permissions for the builtinusers. I have tried everything else I could find on this problem and this is the last thing to try. It seems from the comments that this would work!

  36. nelson says:

    I inherited a server with messed up permissions and could not figure out why it could not update. You had it right!

    Thank you!

  37. op says:

    Brad, all I can do is echo the sentiments that have already been expressed. Thanks for resolving and then posting, as this ends a long and frustrating issue!

  38. Sago says:

    Thanks you are the best!!!!

  39. Scott says:

    Brad, I can't seem to get through the concept of this but think it would fix my problem.  What exactly does your fix entail?

  40. Scott says:

    Ok, I was just getting direction.  Thanks.  I will try to do this and see if it works.  BTW if I am logged in as administrator shouldn't the builtinadministrator account preside the builtinuser account?

  41. Ran Davidovitz says:

    We faced this now, i would think that this should have been fixed already…

  42. mike says:

    THANK YOU!!!

  43. Scott says:

    This worked like a charm for me.

  44. Denis says:

    How can i open this permission windows and add the string?

  45. Thank you! Fantastic..

  46. Aurelio Corsini says:


  47. BUILTINUser says:

    You can add "users", it will accomplish same result (worked for me, same issue). I didn’t check eventvwr, I just assumed the error windows update was reporting was all I’d see but looking now I see it’s specific about the permission error. Good grief,
    I’d like to beat the idiot with a stick who did this to our one server…! 🙂

  48. John says:

    Great article. Thank you. it solved my problem.

  49. Grateful says:

    This worked for me. Thank you very much.
    I have spent many hours searching for a way to solve this problem. I really appreciate your post.

  50. Bogdan says:

    Its work’s- thanks.
    After "added BUILTINUsers with read access to C" – I must restart service Windows update and it work’s

  51. this is a lie says:

    Your a liar. None of that *** is on my computer. I just reset it to factory. And nothing. You liar.

  52. Morris says:

    This is over my head. Is there a simpler or automatic fix for windows update

  53. John Margaris says:

    This is it. This solution worked for me as well.
    Well done!

Comments are closed.

Skip to main content