This error is occurring on my Windows 10 box which I use as a NAS

What does it mean?

Log Name: Application
Source: ESENT
Date: 03/09/2020 13:28:50
Event ID: 642
Task Category: General
Level: Warning
Keywords: Classic
User: N/A
Computer: PC.domain.local
Description:
Catalog Database (3784,D,50) Catalog Database: The database format feature version 9180 (0x23dc) could not be used due to the current database format 1568.20.0, controlled by the parameter 0x410022D8 (8920 | JET_efvAllowHigherPersistedFormat).
Event Xml:



642
0
3
1
0
0x80000000000000

7007


Application
PC.domain.local



Catalog Database
3784,D,50
Catalog Database:
0x410022D8 (8920 | JET_efvAllowHigherPersistedFormat)
9180 (0x23dc)
1568.20.0

It is some kind of Jet Database error and will probably be replaced by a different error at next update |:

I have been receiving the errors for:

Catalog Database (13848,D,35) Catalog Database: The database format feature version 9180 (0x23dc) could not be used due to the current database format 1568.20.0, controlled by the parameter 0x410022D8 (8920 | JET_efvAllowHigherPersistedFormat).

Catalog Database (13848,D,35) Catalog Database: The database format feature version 9120 (0x23a0) could not be used due to the current database format 1568.20.0, controlled by the parameter 0x410022D8 (8920 | JET_efvAllowHigherPersistedFormat).

Catalog Database (13848,D,40) Catalog Database: The database format feature version 9080 (0x2378) could not be used due to the current database format 1568.20.0, controlled by the parameter 0x410022D8 (8920 | JET_efvAllowHigherPersistedFormat).

In that order

It appears that the databases here: C:\Windows\System32\catroot2 are the ones being referenced

I have two databases in there:



Containing:



An excerpt from my DB error log from there reads:

CatalogDB: 10:33:15 AM 10/23/2020: DONE Adding Catalog File (32ms): Microsoft-Windows-Internet-Browser-Package~31bf3856ad364e35~amd64~~10.0.19041.608.cat
CatalogDB: 10:33:15 AM 10/23/2020: DONE Adding Catalog File (15ms): Microsoft-Windows-SenseClient-Package~31bf3856ad364e35~amd64~~10.0.19041.608.cat
CatalogDB: 10:33:16 AM 10/23/2020: DONE Adding Catalog File (47ms): Microsoft-Windows-Client-Desktop-Required-Package~31bf3856ad364e35~amd64~~10.0.19041.608.cat
CatalogDB: 10:33:16 AM 10/23/2020: DONE Adding Catalog File (62ms): Microsoft-Windows-Client-Desktop-Required-

Stopping the Cryptographic Services and deleting the two folders has reduced the number of errors.

---

Following on from the above, after taking that action (I just stopped the Cryptographic Services and moved both DB folders into a new folder I had created called Old and restarted the service.)

After restarting the Cryptographic Services service, the proper EDB files appeared as can be seen here:



So presumably there was a serious problem compared to before as these files were not present.

---

They disappeared again!!

The log files disappear when you restart the Cryptographic service again - so they will presumably disappear at restart.



Stop the service, remove the DB folders and the log file, then restart and we see these files created:



What the heck?

Still get the errors when restarting the Cryptographic services:



Each reads:

Starting session 2 - ‎2020‎-‎11‎-‎09T13:06:19.695531100Z.

Ending session 2 started ‎2020‎-‎11‎-‎09T13:06:19.695531100Z.

Catalog Database (16064,D,35) Catalog Database: The database format feature version 9180 (0x23dc) could not be used due to the current database format 1568.20.0, controlled by the parameter 0x410022D8 (8920 | JET_efvAllowHigherPersistedFormat).

Catalog Database (16064,D,35) Catalog Database: The database format feature version 9120 (0x23a0) could not be used due to the current database format 1568.20.0, controlled by the parameter 0x410022D8 (8920 | JET_efvAllowHigherPersistedFormat).

Catalog Database (16064,D,40) Catalog Database: The database format feature version 9080 (0x2378) could not be used due to the current database format 1568.20.0, controlled by the parameter 0x410022D8 (8920 | JET_efvAllowHigherPersistedFormat).

Catalog Database (16064,D,35) Catalog Database: The database format feature version 9180 (0x23dc) could not be used due to the current database format 1568.20.0, controlled by the parameter 0x410022D8 (8920 | JET_efvAllowHigherPersistedFormat).

Catalog Database (16064,D,35) Catalog Database: The database format feature version 9120 (0x23a0) could not be used due to the current database format 1568.20.0, controlled by the parameter 0x410022D8 (8920 | JET_efvAllowHigherPersistedFormat).

Catalog Database (16064,D,40) Catalog Database: The database format feature version 9080 (0x2378) could not be used due to the current database format 1568.20.0, controlled by the parameter 0x410022D8 (8920 | JET_efvAllowHigherPersistedFormat).

---

How does Windows 10 reliably track the following?

Provides three management services: Catalog Database Service, which confirms the signatures of Windows files and allows new programs to be installed; Protected Root Service, which adds and removes Trusted Root Certification Authority certificates from this computer; and Automatic Root Certificate Update Service, which retrieves root certificates from Windows Update and enable scenarios such as SSL. If this service is stopped, these management services will not function properly. If this service is disabled, any services that explicitly depend on it will fail to start.

---

Yes it is definitely a jet db looking at those log files, but why it is never happy with the files it creates I am not sure. As for deleting the files but not recreating them, it seems as though the log file versions never match the edb files or something like that. I’m wondering if the cryptographic service works at all or if I should just disable it.

It could always be restarted when an update containing root certificates is required.

Just as an aside, when I look at my own Windows 10 Ent addition, I can see that this folder is populated with EDB files indicating that the Jet database is running correctly, but I have not had to restart the cryptographic services today to achieve this.



The PC has been powered up for some time though.

I see the 642 ESENT errors on the same minutes past the hour, but the number of hours seems to vary??? 😰

---

This is a troubling error - my catroot2 folder is populated by those files today also???

Here is a happy picture to help:

---

Can everyone please report exact edition and build numbers please? This should be resolved simply enough.

---

My version that appears to work well, but does seem to switch between populating the catroot2 folder and not (and which currently looks so)



Is this version:

---

Unfortunately I am seeing the same in the Catroot2 folder:



And my version is as thus:

Well they seem to be under the same condition as mine, which has a third different version number.

How often are you seeing the event IDs?



I seem to get a spate of them and then they subside for 90 mins when I see:

---

I think we need to admit it comes and goes with the lack of jet database files.

Looking at me dberr file in there - which doesn't give a lot of activity recently and in no way seems to account for the presence or absence of files here:

CatalogDB: 4:20:39 AM 12/9/2020: DONE Adding Catalog File (0ms): Microsoft-Media-Foundation-Package~31bf3856ad364e35~amd64~~10.0.19041.685.cat
CatalogDB: 4:20:39 AM 12/9/2020: DONE Adding Catalog File (0ms): Microsoft-Windows-Multimedia-MF-Package~31bf3856ad364e35~amd64~~10.0.19041.685.cat
CatalogDB: 4:20:39 AM 12/9/2020: DONE Adding Catalog File (15ms): Multimedia-MFCore-Package~31bf3856ad364e35~amd64~~10.0.19041.685.cat
CatalogDB: 4:20:39 AM 12/9/2020: DONE Adding Catalog File (16ms): Multimedia-MFCore-WCOSHeadless-Package~31bf3856ad364e35~amd64~~10.0.19041.685.cat
CatalogDB: 4:20:39 AM 12/9/2020: DONE Adding Catalog File (0ms): Multimedia-MFCore-WCOSMinusHeadless-Package~31bf3856ad364e35~amd64~~10.0.19041.685.cat
CatalogDB: 4:20:39 AM 12/9/2020: DONE Adding Catalog File (0ms): Microsoft-Windows-Media-Streaming-Package~31bf3856ad364e35~amd64~~10.0.19041.685.cat
CatalogDB: 4:20:39 AM 12/9/2020: DONE Adding Catalog File (0ms): Microsoft-OneCore-Multimedia-CastingReceiver-Media-Package~31bf3856ad364e35~amd64~~10.0.19041.685.cat
CatalogDB: 4:20:39 AM 12/9/2020: DONE Adding Catalog File (0ms): Microsoft-Windows-Holographic-Desktop-Merged-Package~31bf3856ad364e35~amd64~~10.0.19041.685.cat
CatalogDB: 4:20:39 AM 12/9/2020: DONE Adding Catalog File (16ms): Microsoft-Windows-Holographic-Desktop-Analog-Package~31bf3856ad364e35~amd64~~10.0.19041.685.cat
CatalogDB: 6:08:11 AM 12/16/2020: DONE Adding Catalog File (125ms): Microsoft-Office-ClickToRun-0DF537F297D220C26FD19F95D58BDF4E-i640.cab.cat
CatalogDB: 6:08:13 AM 12/16/2020: DONE Adding Catalog File (63ms): Microsoft-Office-ClickToRun-6D7811AD-A68C-4956-B0F5-A9DB0E1B5D0D-stream.x86.en-us.dat.cat
CatalogDB: 6:08:13 AM 12/16/2020: DONE Adding Catalog File (219ms): Microsoft-Office-ClickToRun-6D7811AD-A68C-4956-B0F5-A9DB0E1B5D0D-stream.x86.x-none.dat.cat

It does have an entire week without any activity at all and then shows that MS Office made a few changes yesterday.

Currently the folder is empty of files though:

---

So what happens if you restart the cryptogrphic services now?

This:



and this:



](*,) 😣 😣

---

😰

Most enlighteining.

So does this mean that the cryptographic services really cannot create the database anymore?

Catalog Database (18160,D,12) Catalog Database: The database format feature version 9080 (0x2378) could not be used due to the current database format 1568.20.0, controlled by the parameter 0x410022D8 (8920 | JET_efvAllowHigherPersistedFormat).

There is no database now, so surely it could create one?

You would think so |:

---

on build 19042.764 Of Win X I am only seeing these at restart now - or unless I restart cryptographic services - but no EDB files anywhere in CatRoot2 now...

---

Same here - Windows 10 version 20H2

Now when ~I restart the cryptographic services I get the Event ID: 642 error for when it checks the database version on startup of the service, but it does not create any files or do anything as far as I can see.

It just decides the DB is wrong and then it stops processing altogether.