Frequently Asked Questions

Chances are, others have the same questions that you do. Therefore, we have taken the common questions for Diskeeper, Sitekeeper and Undelete and provided the answers (and the questions) below in our Frequently Asked Questions section. Simply select the product below that you have questions about. If you can’t find the answer you’re looking for, you can submit a tech support question here.

Diskeeper | Sitekeeper | Undelete

Question
Diskeeper reports the following Event ID 29 in the Application Log of the Event Viewer: File System Inconsistency detected: The file records that GetInUseFRS requested and received are (one number), (different number).
Answer
If a file on an NTFS volume is extremely fragmented or compressed, it will take more than one MFT (Master File Table) record to fully record the data about this file. Therefore, in order to get the full information about the file, Diskeeper has to read more than one MFT record off the disk. It can happen that the operating system supplied API cannot return the MFT record that was requested, but instead returns an MFT record belonging to another file. When Diskeeper notices that the MFT record requested is different from the MFT record that was returned then the Event ID 29 is logged. This can happen if a file is deleted during a defragmentation run, so if you see this Event Viewer entry only once or perhaps twice with different numbers, it's most likely a deleted file situation and not a cause for concern. If it happens every time Diskeeper is run with the same numbers, it means Diskeeper can't get the file information that might be in a separate file record (MFT record), so the file most likely isn't going to get defragmented nor reported on the post-defragmentation report. In the latter case, it is unclear what should be returned by the operating system API. If the circumstances requiring Diskeeper to log an Event ID 29 occur during the startup of a Diskeeper defragmentation job, it means that we cannot get full data about the Master File Table and its contents. In that case, the defragmentation operation will stop, as it cannot proceed safely. We have most often seen this situation occur after a large number of files have been written to the volume and then deleted. In order to remedy the situation, you may need to write a large number of files back to the volume (10,000 or more). Another option is to backup, reformat and restore the volume.

Question

Diskeeper reports the following Event ID 29 in the Application Log of the Event Viewer: File System Inconsistency detected: The file records that GetInUseFRS requested and received are (one number), (different number).

Answer

If a file on an NTFS volume is extremely fragmented or compressed, it will take more than one MFT (Master File Table) record to fully record the data about this file. Therefore, in order to get the full information about the file, Diskeeper has to read more than one MFT record off the disk. It can happen that the operating system supplied API cannot return the MFT record that was requested, but instead returns an MFT record belonging to another file. When Diskeeper notices that the MFT record requested is different from the MFT record that was returned then the Event ID 29 is logged.

This can happen if a file is deleted during a defragmentation run, so if you see this Event Viewer entry only once or perhaps twice with different numbers, it's most likely a deleted file situation and not a cause for concern.

If it happens every time Diskeeper is run with the same numbers, it means Diskeeper can't get the file information that might be in a separate file record (MFT record), so the file most likely isn't going to get defragmented nor reported on the post-defragmentation report.

In the latter case, it is unclear what should be returned by the operating system API. If the circumstances requiring Diskeeper to log an Event ID 29 occur during the startup of a Diskeeper defragmentation job, it means that we cannot get full data about the Master File Table and its contents. In that case, the defragmentation operation will stop, as it cannot proceed safely.

We have most often seen this situation occur after a large number of files have been written to the volume and then deleted. In order to remedy the situation, you may need to write a large number of files back to the volume (10,000 or more). Another option is to backup, reformat and restore the volume.

<<Back