Article ID: 176239 - View products that this article applies to.
This article was previously published under Q176239
This article has been archived. It is offered "as is" and will no longer be updated.
With circular logging enabled, the database may not restart after an abnormal stop, and a JET_errFileNotFound error may be displayed numerically in any of the following forms:
NOTE: Events 1120 and 5000 are generic database start errors; you must interpret the code in their descriptions to understand the exact reason that the database stopped responding.
This may be caused by a problem in the checkpoint file. If this is the case, and you delete the Edb.chk file, the database starts. However, pay close attention to the cautions listed in the "Resolution" section of this article before you delete the checkpoint file.
If circular logging is enabled, Exchange Server deletes transaction log files as soon as all of the data in them has been written out to the main database files. This process is tracked by the checkpoint. The actual checkpoint that the database uses is held in memory, but it is frequently written out to the Edb.chk file.
Another process may hold open the Edb.chk file, which prevents Exchange Server from updating the checkpoint file when the checkpoint advances. Applications such as virus scanners and backup programs may "steal" the checkpoint file temporarily. Exchange Server continues to function normally, and to update the checkpoint in memory, while it waits for the other process to release the Edb.chk file.
If the Edb.chk file is locked against Exchange Server for more than a short period of time, the log file listed in it may be deleted before the Edb.chk file is updated. If the database stops suddenly, the checkpoint in memory is lost. When the database is restarted, it must rely on the checkpoint recorded in the Edb.chk file. Because the Edb.chk file points to a nonexistent transaction log file, the database does not start, and a JET_errFileNotFound error is displayed.
Remove the Edb.chk file, and then restart the database service.
If the Edb.chk file is gone, Exchange Server scans through all the available log files, and then begins recovery using the first log file that it finds.
CautionsDo not remove the Edb.chk file unless you know exactly why you need to remove it, and unless you know that you can safely remove it in your current circumstances. Removing the Edb.chk file in certain circumstances may irreparably damage the database. For more information about the checkpoint, click the following article number to view the article in the Microsoft Knowledge Base:
240145If you are experiencing the conditions described here, and if all of the following statements are true, you can safely delete the Edb.chk file:
(http://support.microsoft.com/kb/240145/ )How to remove Exchange Server transaction log files