1C Infobase Won't Open? What to Check First

A 1C Enterprise infobase can fail to open for reasons that range from trivial to serious: a locked session left behind, a configuration mismatch, genuine file corruption, or a storage fault underneath. The message shown on screen rarely distinguishes between them, so the first job is working out which one you have before running anything that modifies the data.

This determines everything that follows. A file-based infobase keeps its data in a single .1CD file, and recovery means working with that file directly. A client-server infobase keeps its data in SQL Server (or PostgreSQL), and recovery is fundamentally database recovery on that engine, with 1C's metadata layer on top. Check which you have before looking for solutions, since advice for one can be actively wrong for the other.

Before assuming corruption, check whether sessions are still held open from a previous crash, whether the infobase list entry still points at the right path, and whether the user has access to that path at the operating-system level. A surprising share of infobases that will not open are not damaged at all, and restarting the server service or clearing stale sessions resolves it.

1C's Test and Repair utility, chdbfl.exe, is the usual first instinct, and for minor structural problems it does the job. The risk is what it does when the damage is beyond minor: it can remove the objects it cannot repair, so the infobase opens afterwards but with documents or catalog entries gone. Once that has happened, recovering them means going back to the file as it was before the repair. Copy the .1CD file somewhere safe first, and run the tool on a copy.

If chdbfl.exe has already been run and data is now missing, the original file may still be recoverable, but only if it exists somewhere: a backup, a shadow copy, or the untouched original if the repair was done on a copy. Stop using the affected drive for anything else while you look, since a deleted original may still be recoverable from free space until it is overwritten.

A .dt export is useful, but it is a snapshot taken at a point in time, and a damaged .dt can itself fail to load. If your only copy is a .dt file that will not import, that is not automatically the end, since a damaged export can often be analysed for the portion that is structurally intact. It is still worth keeping proper file-level backups of the infobase alongside any DT exports.

An infobase that will not open because of a configuration mismatch, a failed update or a lost .cf file is a different problem from damaged data, and a much better one to have. The accounting data can usually be recovered independently of the configuration and reattached to a working one. Establish which layer is actually broken before treating it as data loss.

Ask a specialist when Test and Repair has removed data, when the .1CD file reports an unsupported format, when the SQL Server database behind a client-server infobase will not attach, or when ransomware has encrypted the infobase. A .1CD file or SQL Server data file is a large file, and large files are often only partially encrypted, so a total loss should not be assumed before an assessment. We work from an image and say what looks realistic once we have seen it.