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 =
http://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 (11)

  1. Anonymous says:

    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.

  2. Atanu Dey says:

    Good One Vivek, This worked for me … 🙂

  3. Alex says:

    Thanks Vivel Saxena ! This for me work

  4. Marlon says:

    Thanks from Brazil! Worked like a charm!!

  5. Tony says:

    Perfect solution! Worked like a charm.

    Congratulations!!!

  6. whah says:

    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 /detectnow

  7. GURU says:

    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 resolved

  8. Cristian Ceobanu says:

    works with delete WOW64 folder ;). Thanks

  9. Ricardo says:

    Great… It works jut deleting WOW64… thank you

  10. Li says:

    Where is wow64 key?