D+ screws up Windows Update, CryptSvc

I’m running Vista SP2, CIS 3.10.102363.531, 32-bit.

When I attempted to upgrade (using Windows Update) to SP2 back when I was running SP1, the upgrade failed and my catdb (catalog database in C:\Windows\system32\catroot2, used by Cryptographic Services) was corrupt. I waited around 10 hours for the database to be rebuilt, and tried again. The upgrade failed again and catdb was corrupt again. I tried again, this time disabling D+ and the firewall. The database was rebuilt in around 2 minutes and the upgrade succeeded!

I’ve just had a problem with installing updates again. This time the entire system froze. When I restarted Windows, catdb was corrupt. I waited a few hours for the database to be rebuilt. Here are some messages from dberr.txt (in C:\Windows\system32\catroot2) over a few hours:

CatalogDB: 11:10:18 AM 15/08/2009: Adding Catalog File:  Package_for_KB956744_client_0~31bf3856ad364e35~x86~~6.0.1.8.cat
CatalogDB: 11:10:20 AM 15/08/2009: catdbcli.cpp at line #391 encountered error 0x000006bb
CatalogDB: 11:10:20 AM 15/08/2009: catadnew.cpp at line #577 encountered error 0x000006bb
CatalogDB: 11:10:20 AM 15/08/2009: DONE Adding Catalog File:  Package_for_KB956744_client_0~31bf3856ad364e35~x86~~6.0.1.8.cat
CatalogDB: 11:10:20 AM 15/08/2009: Adding Catalog File:  Package_5_for_KB956744~31bf3856ad364e35~x86~~6.0.1.8.cat
CatalogDB: 11:10:22 AM 15/08/2009: catdbcli.cpp at line #391 encountered error 0x000006bb
CatalogDB: 11:10:22 AM 15/08/2009: catadnew.cpp at line #577 encountered error 0x000006bb
CatalogDB: 11:10:22 AM 15/08/2009: DONE Adding Catalog File:  Package_5_for_KB956744~31bf3856ad364e35~x86~~6.0.1.8.cat

But then I thought of disabling D+. I did, and the entire database finished rebuilding in 1 minute:

CatalogDB: 11:28:38 AM 15/08/2009: SyncDB:: AddCatalog:  ntexe.cat
CatalogDB: 11:28:40 AM 15/08/2009: SyncDB:: AddCatalog:  ntpe.cat
CatalogDB: 11:28:40 AM 15/08/2009: SyncDB:: AddCatalog:  ntph.cat
CatalogDB: 11:28:40 AM 15/08/2009: SyncDB:: AddCatalog:  ntprint.cat
CatalogDB: 11:28:40 AM 15/08/2009: SyncDB:: AddCatalog:  oem10.CAT
CatalogDB: 11:28:40 AM 15/08/2009: SyncDB:: AddCatalog:  oem12.CAT
CatalogDB: 11:28:40 AM 15/08/2009: SyncDB:: AddCatalog:  oem2.CAT
CatalogDB: 11:28:40 AM 15/08/2009: SyncDB:: AddCatalog:  oem3.CAT
CatalogDB: 11:28:41 AM 15/08/2009: SyncDB:: AddCatalog:  oem4.CAT
CatalogDB: 11:28:41 AM 15/08/2009: SyncDB:: AddCatalog:  oem5.CAT
CatalogDB: 11:28:41 AM 15/08/2009: SyncDB:: AddCatalog:  oem6.CAT
CatalogDB: 11:28:41 AM 15/08/2009: SyncDB:: AddCatalog:  oem7.CAT
CatalogDB: 11:28:41 AM 15/08/2009: SyncDB:: AddCatalog:  oem8.CAT
CatalogDB: 11:28:41 AM 15/08/2009: SyncDB:: AddCatalog:  Package_10_for_KB935509~31bf3856ad364e35~x86~~6.0.1.9.cat
CatalogDB: 11:28:41 AM 15/08/2009: SyncDB:: AddCatalog:  Package_10_for_KB938371~31bf3856ad364e35~x86~~6.0.2.27.cat
CatalogDB: 11:28:41 AM 15/08/2009: SyncDB:: AddCatalog:  Package_10_for_KB948465~31bf3856ad364e35~x86~en-US~6.0.1.18005.cat
CatalogDB: 11:28:41 AM 15/08/2009: SyncDB:: AddCatalog:  Package_10_for_KB948465~31bf3856ad364e35~x86~~6.0.1.18005.cat
CatalogDB: 11:28:41 AM 15/08/2009: SyncDB:: AddCatalog:  Package_10_for_KB961371~31bf3856ad364e35~x86~~6.0.1.4.cat
...

Is this a bug in CIS?

PS: For those of you who don’t know what the catalog database does - if it’s corrupt and you attempt to start Microsoft programs using “Run as Administrator”, instead of the usual grey prompt you will get an orange prompt telling you the program is “unidentified” even though it comes from Microsoft. This is because the database is corrupt and file signature verification using the catalogs won’t work. I’m guessing this is also why Windows Update fails when the database is corrupt.

Any time I do a windows update. I switch to installation mode before dl. Never had a issue. After it is done. I switch back. If it requires a restart. I will let every thing load up and do its thing. And also switch back to the previous mode.

That may be a workaround, but it is not acceptable for D+ to ■■■■■ up the catalog database in Safe Mode.

Hi wj32.

I must admit, this is the first time I have come across this issue so I’ll ask the other Mods if they have any ideas.

Hey Quill,

I’d point Egemen at this topic directly, particularly if D+ is munting the DB in safe mode. I’ve never seen this before (and hope I never do ;)).

Cheers,
Ewen :slight_smile:

Thanks Ewen, I’ve dropped egemen a line. :slight_smile:

In case you didn’t know wj32, egemen is lead dev.

Maybe it’s something weird with my machine. I know that other people have had problems with Windows Update and CIS, though.

To try to reproduce this you can:

  • net stop cryptsvc
  • cd C:\Windows\system32\
  • move or rename catroot2
  • net start cryptsvc

See how long it takes for catroot2 to be regenerated. Test with CIS on and then test with CIS off.

I just started testing this, it’s taking a while. I’ll report back when it’s rebuilt.

Edit:

I’m not sure about this, a search or two shows me that problems with Windows update and the catroot2 folder are prevalent.

As far as I remember, the edb files contained in catroot2 are transient files, created after roll-overs and accumulated, same goes for other services that use this database format, DHCP springs to mind.

I have tried rebuilding the catroot2 folder with D+ on and off and regardless of which method I choose, it’s not recreated.

Bottom line, is this a real problem, or will catroot2 be recreated when it needs to be?

Have you tried restarting the computer? What happens when you try to Run as Administrator on Notepad, for instance?