Windows 7 update error 80070002 - the story of a fix.

The other day I wast^H^H^H^Hspent several hours wrestling with the Windows 7 update mechanism; now that it seems the problem is fixed, I'd like to share the story in the hope that it may be helpful for someone with a similar problem.

This is my first post to the forum, so I'd welcome remarks about style or detail ...

The system in question is a Windows 7 Pro, 64 bit, SP 1. It is a localized version, thus I can't always give the exact english wording of messages, sorry.

What was wrong

Compared to my rusty and trusty (private) Win XP, the Win 7 (developer) machine has always been somewhat brittle: It had sporadic Blue Screens in the past, but most of the time it worked.

The "situation" developed as I tried to update the system (the setting is automatic fetch, manual install). Windows Update failed with some error code I did not write down; I tried several rounds of sfc /scannow and reboots, and after some research I decided to try the "official" fix: KB947821, the "System Update Readiness Tool". This looked right for me:

System Update Readiness Tool fixes Windows Update errors in Windows 7, Windows Vista, Windows Server 2008 R2, and Windows Server 2008

After running for several hours (I was warnded about it) it finally finished installing, claiming a successful install. Unfortunately, the situation was even worse now: Search for updates consistently failed with error 80070002, and the system file check tool sfc /scannow also would not complete.

What I tried

Now was the time for more desperate measures, I found this:

Windows Update error 80070002

I manually emptied
\Windows\SoftwareDistribution\DataStore\* and
\Windows\SoftwareDistribution\Download\*
as recommended, restarted the Windows Update service - and still got the 80070002 error when searching for updates.

Then there was a vain attempt with the automatic repair tool msdt.exe and WindowsUpdateDiagnostic.diagcab. While it purported to have fixed some security settings and service registrations, the 80070002 problem was still there.

One thing in the report output from this automated tool was worrying: it showed the SFC output, which this time could not even start. And indeed, after reboot, a search for updates still produced a 80070002 error, and sfc /scannow also failed.

I tried another MS recommendation (this time with not too much hope): The Fixit 50202

How do I reset Windows Update components?

No change. The same Fixit again, but with aggressive option: No difference.

At this time, it seemed I ran out of MS-supplied support pages, Fixits, KB's and whatnot.

What helped

The first culprit to investigate was SFC. By this time, I had learned from seeking through forums and blogs that SFC writes a log file at \Windows\Logs\cbs\cbs.log.

I noticed that an attempt to search for updates (with the Windows Update GUI) also added entries to the log file - obviously the update process runs SFC itself, which means that the whole problem could be resting upon SFC.

From several Error entries in the log, this one provided a registry key I could look up:

2013-10-28 14:16:23, Error CSI 0000000d (F) STATUS_OBJECT_NAME_NOT_FOUND #2701499# from Windows::Rtl::SystemImplementationDirectRegistryProvider::SysOpenKey(flg = 0, key = {provider=NULL, handle=0}, da = (KEY_READ|KEY_WOW64_64KEY), oa = @0xa2cac0->OBJECT_ATTRIBUTES {s:48; rd:NULL; on:[150]"\Registry\Machine\Software\Microsoft\Windows\CurrentVersion\SideBySide\Winners\amd64_prnca00a.i nf-languegepack_31bf3856ad364e35_de-de_d8743cb7c94a0a96"; a:(OBJ_CASE_INSENSITIVE)}, disp = Unmapped disposition: 10669704 (0x00a2ce88))[gle=0xd0000034]

Shortly after that, the log reported

2013-10-28 14:17:31, Error CBS Failed to initialize store parameters with boot drive: and windows directory: [HRESULT = 0x80070002 - ERROR_FILE_NOT_FOUND]

The error code matched the observation in Windows Update. Next thing was to look in RegEdit for the named registry key (after interpreting "\Registry\Machine" als HKEY_LOCAL_MACHINE). It did actually exist, but selecting it produced a message box in RegEdit telling me that it cannot open the key because of an error: The system can't find the named file.

Now that was suspicous: In RegEdit, all other sibling keys in
HKLM\Software\Microsoft\Windows\CurrentVersion\SideBySide\Winners\
behaved normal when selected or opened. Only the amd64_prnca00a* key refused to be selected, opened, renamed or deleted - always invoking error message boxes. Exporting the Winners\ subtree to a registry script confirmed that the suspicious key did not show up in the generated text file. No wonder it caused a "not found" error.

I found an interesting posting

Registry: Error opening key - can't delete it - TechRepublic

where someone described how to edit the registry with SYSTEM credentials using the Sysinternals psexec command:

psexec -i -d -s c:\Windows\RegEdit.exe

But still the dysfunctional key could not be accessed, while it's siblings could be edited without a problem. So this was not a case of insufficient access privileges.

Unable to get rid of the bad key or change it, I devised a workaround. In the exported registry script file for Winners\, I added the missing key manually. Its content was easy to guess since all other similar keys had the same content. I then renamed the containing key in the registry from Winners\ to Winners_bad\ (maybe Losers\ would have been a better name ...), and re-imported the edited registry script. That gave me a new Winners\ subtree again, with the editor-created replacement of the problematic key.

Trying out sfc /scannow once again affirmed that the hack has helped - it finished through without error. An attempt to delete the Winners_bad\ subtree was not completely successful - as expected, all keys but the one where deleted in Winners_bad\.

So now I have the sole bad key stuck in Winners_bad\ until eternity (or a new system install, which is probably earlier). Nevertheless, since then, Windows Update and SFC work as expected.

What I learned

Investigate the log files. The psexec trick is very useful. If nothing else helps, hack the registry.

What I'd like to know

I have no idea how this registry key got damaged, and have not seen such a key before. I was under the impression that the Windows registry is secured with transactional logs and backups and prepared to survive a "system failure" aka BSOD in a consistent state. The fact that a system registry key can be corrupted, lose its content and remain seemingly unrepairable is really unsettling. Does anyone know how that could have happened or what could be done about such a key?

Thank you for the explanation!

Concerning the bit flip - wow, well spotted. I'll take another look in the registry when I'm back at the Win 7 machine (at work).

I know and use HxD, but I'll refrain from trying to fix the HKLM\Software hive this way - I can live well with the abandoned bad key in there. But good to know in case of a really bad emergency.

I still hope that bit flips like this are extremely rare occurances, else the registry would be pretty insecure. Could the cause be a memory defect? From looking into older minidumps, the machine had rather spontaneous BSODs, with no obvious driver involved, thus the suspicion.

I realize that this thread is over a year old, but just wanted to shout out a very sincere thanks to the OP as it has been a lifesaver! Over the past 12 months I've tried to fix this very issue - I'd spend a couple of hours searching for new threads on different boards and applying various patches - all to no avail. I'd give up for a month or two and then the itch would start again and a couple days ago I resolved to (finally!) this thing resolved once and for all.
Well, what do you know? Found the bad registry key, applied the workaround and presto! Seeing that window open up with "83 updates found" almost felt like Christmas :)
Thanks again for your perseverance in finding the problem and posting your solution.

@rockytt: Thank you for your kind remarks! I'm very glad my story did turn out to be useful for someone else. By the way, on the machine concerned "memtest86" actually reported a memory issue later (while running over a weekend ...). After replacing the memory modules, the installation runs and updates just fine ever since.

Another Kudos to tinpot for this posting, over 2 years later! Nicely done. Thanks for taking the time to write it up. A note: after the patch, sfc failed at 81% for some as yet unknown reason but the update ran just fine. --Fred

Tinpot,

I wanted to let you know that 3 years later, your solution is the only one that worked for me. Your solution was one of the first that I found when I encountered the issue, but frankly I was a little intimidated by it. I put on my old programmer hat and tried it anyway, but could not open the log file \Windows\Logs\cbs\cbs.log - access denied. So, I moved on and tried various other solutions, including programs that claim to fix registry issues and finally came back to this. One thing I learned from the various other things that I tried was that I was able to open the cbs.log file in safe mode and logged in as administrator (maybe one of these criteria was enough). My culprit key was different than yours, but I was able to fix it using the same method. sfc /scannow finally works.

Checking for updates is still checking, but at least I did not get the dreaded Windows Update error 80070002.

Thank you again for the post, I was about to throw my laptop out the window!!

Hats off to the OP!

3 years later and this fix worked for me.

FYI, to open the log just launch notepad.exe in admin mode and open it from there. I.e. type notepad.exe in the search bar then right click on it to Run as Administrator.