« SharePoint Branding Issues: Edit In Datasheet View
SharePoint Tricks: Content By Query for Single Web »

SharePoint Internals: Clearing Configuration Cache Caveat

I’m pretty sure most of you have heard of the SharePoint Cache. This is a directory full of cached objects, nicely wrapped in XML. Sometimes however this cache can become corrupted. A great example of this occurs when developing SPJobDefinitions (TimerJobs for SharePoint). These definitions use this cache, so everytime you deploy new versions of the assemblies, you’ll have to clear the cache. More info about this:

Clearing the cache, means deleting all the XML files. But what if you delete the entire directory? Well, it gets messy.. ;-) SharePoint TimerJobs just stop working all together. And to top it off, you get these nice error messages:

SPTimerStore.InitializeTimer: SPConfigurationDatabase.RefreshCache returned SPConstants.InvalidRowVersion 
The timer service could not initialize its configuration, please check the configuration database.  Will retry later.

Great! :p

So what happened? The directory in question is: C:\Documents and Settings\All Users\Application Data\Microsoft\SharePoint\Config\<guid>\. So the name of the directory is some kind of identifier. Looks pretty innocent, huh..  it isn’t!
When this happened to me earlier on today, I wasn’t really feeling at ease. The timerjobs didn’t want to run, and no one seemed to know what this guid was. After a few hours of reverse engineering however, I found discovered this was actually the config DB ID. Nice! But where can I find it? Luckily it was not hard to find out. You’ll have to open up the registry and go to: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\Secure\ConfigDB. 

The config DB registry key.

The config DB registry key.

In this key, you’ll find the config DB id. Now all you have to do, is create a directory with this guid and restart the SharePoint Timer service. And you’ll see your XML files reappearing, and soon after your timerjobs restarting. Phuw, that was a close one.. :-)

’till next time!

Tags: , , , , ,
This entry was posted on Wednesday, July 30th, 2008 at 21:46 and is filed under SharePoint. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

7 Responses to “SharePoint Internals: Clearing Configuration Cache Caveat”

  1. Links (7/31/2008) « Steve Pietrek - Everything SharePoint Says:
    August 1st, 2008 at 2:12

    [...] SharePoint Internals: Clearing Configuration Cache Caveat [...]

  2. Jeremy Thake Says:
    August 29th, 2008 at 8:51

    Absolute lifesafer! Followed instructions elsewhere and removed the GUID folder rather than contents and nothing was deploying! Thanks mate!

  3. Luis Lugo Says:
    October 2nd, 2008 at 16:35

    Very good blog, thanks.

    My problem is that both the folder and registry settings you describe above are zeroed out (00000-000…). Is there anywhere else I can find the correct GUID? I tried looking in the Objects table of the config db to no avail, something in there must be the correct GUID, but can’t figure out which one. I looked on a test server and found that the GUID is the ID of the object that has a property of SPConfigurationDatabase, but could not find the same on the sick system. Any suggestions? I’m trying very hard not to rebuild my entire system…

  4. Luis Lugo Says:
    October 2nd, 2008 at 20:13

    I have verified that the problem was a corrupt configuration database. The Objects table was missing the record for the config db which has the GUID used for the cache elements you describe above. The only way I could recover from that was to run psconfig’s configdb -create command (-connect does not recreate the record and does not recreate the folder and registry GUIDs). After that came all the fun of reconfiguring the whole site from scratch.

  5. Tombo Says:
    October 2nd, 2008 at 23:20

    Luis> Nice to know you recovered your SharePoint farm. Coincidentally I had a similar problem today where my farm got corrupted. Luckily after restoring a backup of the Config database, the farm went back online. It was a close call. :-)

  6. Fixing the Timer Service when everything breaks down « Thoughts on computing, SharePoint and all the rest Says:
    January 14th, 2009 at 12:37

    [...] above procedure is grabbed from tomblog’s excellent post (that will also help if you actually did delete the folder [...]

  7. Allan Hvam Petersen Says:
    March 19th, 2009 at 11:01

    Thx!

Leave a Reply