Create a Post
Showing results for 
Search instead for 
Did you mean: 

Integrity of the objects_5_0.C file

Just finished a brief troubleshooting session using sk:

Policy installation fails with "Policy installation failed on gateway 0-2000040" error 

While I am happy that there is an sk that was 100% on the mark, I'd like to ask Check Point a question as to why the "minor corruptions" or any other kinds of corruption are possible with no automatic correction?

Isn't it possible to maintain a "shadow" files with integrity verified by hashes and fall back on those if corruption is taking place for some reason (i.e. objects_5_0.C changing hash value is changing in the absence of publishing and installing a policy or installing a database?

This is a brand new installation of the Open Server VM with all the necessary prerequisites, including eager-zeroed, reserved highly-redundant storage and reserved memory and CPU resources.

4 Replies

I have to think this is part of why we've largely moved to a database-backed configuration system.

There is still some parts of the product that use the legacy configuration files like objects_5_0.C.

Pretty sure the ultimate "fix" to this problem is to remove the dependency on these files. Smiley Happy


check and then uncheck all the unchecked server options in their order.

If an option is checked, do not change it.

Important Note: Do not perform step 2 for more than one server at a time. In our example, you should not check "Web Server", then check "Mail Server", then proceed to uncheck them both, but rather check "Web Server", then uncheck it, and proceed to the next one.

Awaiting similar "fixes" for R80.20 . . .

Kind regards,
Jozko Mrkvicka


The solution provided by   is unsafe and has chances of causing additional side effects. I wouldn't recommend running it by a customer.

While we work on a better phrasing of the SK, I suggest that you always contact support if you run into this problem.

We will work on preventive solutions.

0 Kudos

Oops! It's done already and, for what its worth, it seem to solve the problem.

That being said, if this is a high risk scenario, perhaps it is better to update the SK before others run into it and suffer the consequences...

BTW, this is on R80.20.M1


Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events