Sophos failed to connect to database, error code 0xe0080837 4294966264

Hello Dee Wood,

as most errors in this section (except for some results of Protect Computers) are errors reported from the endpoints their OS and Sophos versions are the interesting ones. But anyway, the Endpoint component reporting such an error should be SCF (Sophos Client Firewall), is this the case? 4294966264 (or 0xfffffbf8 or -1032) could be Jet_errFileAccessDenied. Are there corresponding errors in the Windows Application Event Log? These should name the file for which the access fails.

Christian

Yes it is the client firewall status error. and reads exactly as below:

Failed to connect to database, error 4294966264

When i checked the logs on the PC and the only error is Event 2103, Sophos Client Firewall,  Failed to connect to database, error 4294966264 and nothing else. all logs after are information ones saying that the firewall is starting.

Hello Dee Wood,

so the errors occur after boot and then SCF is working as it should? Are the older firewall log entries there? If so, it's annoying but not alarming.
There are AFAIK only three files involved - op_data (for SCF 2.x) or scf_data.mdb and .ldb under %ProgramData% and a JETxxxx.tmp in the system %TEMP% directory. Don't think it's a permissions issue, perhaps a lock? Process Monitor might reveal which file (must run at boot time, Event Class file system, include the three Paths, and Result is unknown - i.e. all other than SUCCESS).

Christian

Hi Christian

Yes after boot and SCF is working as it should, even upgraded to 5.4.0.

I have tried stopping the services for the firewall and renaming the op_data.mdb to op_data.mdb.old and restarting the service.

I have also tried protecting and reinstalling the firewall component on the users pc's but no go.

It is random users (monitored for several weeks) with no common thread.

Hello Dee Wood,

as said, the console version doesn't matter.
Could it be that SCF swamps the onboard database engine (although you'd probably need a rather large network with unrestricted traffic to induce excessive logging activity)?

Could you catch the random failures with Process Monitor? On second thoughts - if there is some process other than SCFService.exe accessing the database and the Process Monitor filter drops SUCCESS events you wouldn't notice. Monitoring the mentioned paths for all I/O events but excluding SCFService.exe should catch a potential "alien" access.

Christian

Hello Dee Wood,

as said, the console version doesn't matter.
Could it be that SCF swamps the onboard database engine (although you'd probably need a rather large network with unrestricted traffic to induce excessive logging activity)?

Could you catch the random failures with Process Monitor? On second thoughts - if there is some process other than SCFService.exe accessing the database and the Process Monitor filter drops SUCCESS events you wouldn't notice. Monitoring the mentioned paths for all I/O events but excluding SCFService.exe should catch a potential "alien" access.

Christian

I have the same problem, I will check the messages to see if I give with the solution.

Thanks for the help.

Anthony Morand

Kelvingear - Gear motors