EEHndlr WARNING: Failed to populate ServiceStartup entries in Cache: error 0x80070002
When running updates from WSUS 3.0 SP1 we are seeing the following error messages in the Windows Update Agent Log File C:\Windows\WindowsUpdate.log
We see these messages on all of our target Windows 2003 SP2 x64 servers WindowsUpdate.
2009-01-21 08:50:02:878 816 f2c PT +++++++++++ PT:
Synchronizing server updates +++++++++++
2009-01-21 08:50:02:878 816 f2c PT + ServiceId =
{3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL =
https://slon123456.csfb.cs-group.com/ClientWebService/client.asmx
2009-01-21 08:50:03:284 816 f2c EEHndlr WARNING: Failed to
populate ServiceStartup entries in Cache: error 0x80070002
2009-01-21 08:50:04:346 816 f2c EEHndlr WARNING: Failed to
populate ServiceStartup entries in Cache: error 0x80070002
2009-01-21 08:50:04:362 816 f2c EEHndlr WARNING: Failed to
populate ServiceStartup entries in Cache: error 0x80070002
2009-01-21 08:50:04:378 816 f2c EEHndlr WARNING: Failed to
populate ServiceStartup entries in Cache: error 0x80070002
2009-01-21 08:50:04:518 816 f2c PT +++++++++++ PT:
Synchronizing extended update info +++++
Cause:
When the Windows Update service starts up, we look to see whether there’s a registry key named
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate\Setup\ServiceStartup.
If that key doesn’t exist, then everything is fine, and there’s nothing to copy.
If that key does exist, we look to see whether it contains any keys.
- If it doesn’t, then everything is fine, and there’s nothing to copy.
- If it does, then we expect each of those keys to contain two string values, one
named CacheFile and one named TargetFile.
Then:
- If a given key contains the CacheFile and TargetFile values as expected, then we use those values to determine what file copy operations we need to do.
- If a given key is missing either the CacheFile or the TargetFile key or both, then we wind up throwing the 0x80070002 error.
So this is only a problem if there actually has been a self-update, and we actually do need to copy some files, and we can’t because a key has somehow gotten created in the ServiceStartup key that does not contain the CacheFile and TargetFile values we’re looking for.
Key named WOW64 can be seen in this area, only on 64-bit machines. That key didn’t contain CacheFile or TargetFile values, so it would result in the ServiceStartup 0x80070002 error being logged at startup.
Resolution:
In this set of circumstances, if you delete either the ServiceStartup key or just the WOW64 key, you should see the 0x80070002 warnings go away, with no effect on the system’s operation.
Comments
Anonymous
January 01, 2003
Thanks a lot for detailed description! I have delete the wow64, and the error message gone :) However, as I can read from description, this error msg is not harmful to the system. Thanks a lot again :) Windows 2003 R2 x64, clean install via IBM Serverguide.Anonymous
January 01, 2003
PingBack from http://www.keyongtech.com/5136709-server-wont-update-from-wsusAnonymous
June 20, 2011
Good One Vivek, This worked for me ... :)Anonymous
September 29, 2011
Thanks Vivel Saxena ! This for me workAnonymous
November 14, 2011
Thanks from Brazil! Worked like a charm!!Anonymous
January 08, 2013
Perfect solution! Worked like a charm. Congratulations!!!Anonymous
March 28, 2013
on some clients i see this error and have no issues getting patches. on other clients the fix resolved issues where not seeing the patches. no reboot is needed. just delete the WOW64 key and run wuauclt /detectnowAnonymous
July 16, 2013
I can't find the below register value in windows 2008 R2 STD SP1, but getting 0x80070002 is there any other method to get it resolvedAnonymous
May 15, 2015
works with delete WOW64 folder ;). ThanksAnonymous
September 24, 2015
Great... It works jut deleting WOW64... thank youAnonymous
February 01, 2016
Where is wow64 key?