ESENT errors can occur if a JET database is corrupted.

JET databases are used by numerous Windows utilities including DHCP, Automatic Update etc. In this particular case, we are seeing errors in the Application Event Log from the Automatic Update client (wuauclt.exe), e.g.
Event Type: Error Event Source: ESENT Event Category: Logging/Recovery Event ID: 454 Date: 06/05/2009 Time: 13:06:41 User: N/A Computer: 210L-ICT-23 Description: wuauclt (2284) Database recovery/restore failed with unexpected error -551.

This seems to coincide (on some machines) with a 1 or 2 minute hang at Shut-down time. The explanation for this is that the Automatic Update client is trying to do its default: check-for-updates, download and prompt-for-install, but is timing out because the AU database is corrupt. To verify this, you could try setting Control Panel -> Automatic Updates to Turn off Automatic Updates. Article http://support.microsoft.com/kb/822798 suggests no less than 11 different ways of fixing this, re-install Windows being the 11th and last resort. So, a bit of trial and error might be needed. Not all Jet database corruptions are related to Automatic Update of course, so other databases and their apps might require completely different fixes. The Esentutl utility is generally useful as a verify-and-fixit tool. See Help & Support. esentutl /? for syntax. Of the 11 methods in kb822798, the easiest and most hopeful seems to be #3: rename the CatRoot2 folder & reboot. Either: 1. Reboot in safe mode, rename c:\windows\system32\CatRoot2 to (say) oldcatroot, then reboot normally, or 2.
net stop cryptsvc ren %systemroot%\System32\Catroot2 oldcatroot2 del %systemroot%\system32\CatRoot\{F750E6C3-38EE-11D1-85E500C04FC295EE}\tmp*.cat (optional) del %systemroot%\system32\CatRoot\{127D0A1D-4EF2-11D1-860800C04FC295EE}\tmp*.cat (optional) del %systemroot%\system32\CatRoot\{127D0A1D-4EF2-11D1-860800C04FC295EE}\kb*.cat (optional) del %systemroot%\system32\CatRoot\{ F750E6C3-38EE-11D1-85E500C04FC295EE}\kb*.cat (optional) del %systemroot%\inf\oem*.* net start cryptsvc (or reboot)

Check the integrity of the SoftwareDistribution database as follows:

C:\> cd WINDOWS\SoftwareDistribution\DataStore> C:\WINDOWS\SoftwareDistribution\DataStore>esentutl /g DataStore.edb

Initiating INTEGRITY mode... Database: DataStore.edb Temp. Database: TEMPINTEG2684.EDB Checking database integrity. The database is not up-to-date. This operation may find that this database is corrupt because data from the log files has yet to be placed in the database. In case of error you can try a Recovery and/or a Repair: C:\WINDOWS\SoftwareDistribution\DataStore>esentutl /r edb /lC:\WINDOWS\SoftwareDistribution\DataStore\Logs Initiating RECOVERY mode... Logfile base name: edb Log files: C:\WINDOWS\SoftwareDistribution\DataStore\Logs System files: <current directory> Performing soft recovery... Operation terminated with error -551 (JET_errConsistentTimeMismatch, Database la st consistent time unmatched) after 0.235 seconds. C:\WINDOWS\SoftwareDistribution\DataStore>esentutl /p DataStore.edb Initiating REPAIR mode... Database: DataStore.edb Temp. Database: TEMPREPAIR2948.EDB Checking database integrity. The database is not up-to-date. This operation may find that this database is corrupt because data from the log files has yet to be placed in the database.

In this particular case (on 210l-ICT-23), it was just the log file which was corrupt, so I : (a) stopped the AutomaticUpdates service (b) deleted everything in %systemroot%\ SoftwareDistribution\DataStore\Logs (c) restarted the AutomaticUpdates service A couple of Application event ID 489 are logged, complaining about the missing log files, but those are recreated automatically after a couple of minutes. In an extreme case you might need to stop the automatic update service, delete everything under %systemroot%\ SoftwareDistribution\ , restart the automatic update service then reboot.

You can try re-registering the Crypto service:

echo stopping crypto service net stop cryptsvc echo renaming CatRoot2 ren %systemroot%\System32\Catroot2 oldcatroot2 echo removing tmp files del %systemroot%\system32\CatRoot\{F750E6C3-38EE-11D1-85E500C04FC295EE}\tmp*.cat pause echo re-registering crypto dlls regsvr32 /u softpub.dll regsvr32 /u wintrust.dll regsvr32 /u initpki.dll regsvr32 /u dssenh.dll regsvr32 /u rsaenh.dll regsvr32 /u gpkcsp.dll regsvr32 /u sccbase.dll regsvr32 /u slbcsp.dll regsvr32 /u mssip32.dll regsvr32 /u cryptdlg.dll pause echo re-registering crypto dlls regsvr32 softpub.dll regsvr32 wintrust.dll regsvr32 initpki.dll regsvr32 dssenh.dll regsvr32 rsaenh.dll regsvr32 gpkcsp.dll regsvr32 sccbase.dll regsvr32 slbcsp.dll regsvr32 mssip32.dll regsvr32 cryptdlg.dll pause echo re-starting crypto service net start cryptsvc echo done

Batch file crypto-re-reg.bat can help you do this. It may generate a Sophos false positive, in which case open Sophos and authorise the registry mod which it calls suspicious behaviour.

C:\WINDOWS\WINDOWSUPDATE.log might help, e.g. This suggests it might be the database engine failing to start, rather than a corrupt database ? (Of course it might also be that the engine wont start because of a corrupt database ! )
2009-05-06 14:24:02:224 3076 960 Misc =========== Logging initialized (build: 7.2.6001.788, tz: +0100) =========== 2009-05-06 14:24:02:224 3076 960 Misc = Process: C:\WINDOWS\system32\wuauclt.exe 2009-05-06 14:24:02:224 3076 960 Misc = Module: C:\WINDOWS\system32\wuaueng.dll 2009-05-06 14:24:02:224 3076 960 DtaStor FATAL: Failed to initialize datastore, error = 0xC8000227 2009-05-06 14:24:02:224 3076 960 Misc =========== Logging initialized (build: 7.2.6001.788, tz: +0100) =========== 2009-05-06 14:24:02:224 3076 960 Misc = Process: C:\WINDOWS\system32\wuauclt.exe 2009-05-06 14:24:02:224 3076 960 AUClnt FATAL: Error: 0xc8000227. wuauclt datastore: failed to spawn COM server 2009-05-06 14:24:02:334 1056 c60 DtaStor FATAL: DS: Out of proc datastore process exited with error 0xc8000227 before signalling ready event.