Well there definitely seem to have been some changes made to the functionality of the CryptoGraphic services of late.

You cannot disable the service any longer - it just goes back to manual and starts up again.

You can change the file name if you disable and stop the service but it does just create a replacement file and all of the EDB files appear again in the catroot2 folder..

You still see:

Log Name: Application
Source: ESENT
Date: 20/01/2021 19:11:30
Event ID: 642
Task Category: General
Level: Warning
Keywords: Classic
User: N/A
Computer: PC.domain.local
Description:
Catalog Database (4652,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).
Event Xml:



642
0
3
1
0
0x80000000000000

15660


Application
PC.domain.local



Catalog Database
4652,D,12
Catalog Database:
0x410022D8 (8920 | JET_efvAllowHigherPersistedFormat)
9080 (0x2378)
1568.20.0

Oh and by the way, the files disappear again if you restart the services again.

I like the files being there - I like it like this:



So presumably the service does not work after it uses the database the first time as the service then, although the files are in use by the service, are deemed to be unsuitable at service start-up.

But it still gives the 642 error even when it creates the files!!!!

So I may just start believing that the error in the event log is the error, rather than any issue with the crypto service.

But how could the event ID be the error when it starts out making an EDB jet database, and then stops - the system appears to function briefly but then fails.

I think that the error concerning the first file mismatch is the root of the problem - the system either creates the wrong file version, or detects as a wrong file version when it isn't.

After that it deletes all the files because they are the wrong version.

Whether they are or not is another question.

Is there a way we can adjust the expected version in the Registry or check the file versions before they are deleted?

When it says:

Catalog Database (4652,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).

Can we adjust the Crypto services to expect the version that it creates?

I cannot find anything under Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CryptSvc\Parameters that might account for this, so perhaps it is an issue with the DLL???

I suppose that the DLL could have an issue, but you would have thought that the engine Jet engine creating the file would be the same one then processing them, so this shouldn't really be possible.

The error, I think, is a true error as you say as it fits with behaviour, it assumes the database is wrong as soon as it creates it...??

](*,)
:-k

MS says ✋

It could be a way of keeping us occupied 😰

---

Some people are saying that:

esentutl /p %systemroot%\System32\catroot2\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\catdb

helps and that the 20H2 version resolves it, but I see no evidence either are true.

Firstly, you would have to run the above in Safe Mode or similar to stop the service just restarting, and then why would the verson suddenly be determined as correct?

I think it will just delete it again.

I will try the above but I must return to the office to use Safe Mode as it is a physical machine.

---