Windows Internal Consistency Check and Configuration Errors

Resources

Retrospect performs internal integrity checks during normal operation. Should one of these checks fail, Retrospect may report an "assert" or "chunk checksum" error, and halt operation. Similarly, if Retrospect crashes, you may receive an alert from the operating system saying that Retrospect caused an "exception" or "access violation." All of these errors indicate a problem. This note will help you figure out what to do if you encounter them.

Definitions

A few definitions will help clarify the terminology:

• Assert error – An "assert" error results in a dialog put up by Retrospect that halts operation. The dialog is the result of an internal consistency check in Retrospect that has failed. The only choice at this point is to quit Retrospect.
• Chunk checksum error (-641) – Retrospect stores information in its backup set catalogs in "chunks" of data, each stored with a checksum, a number that helps verify data integrity. When Retrospect reads a chunk of data (for example when opening its configuration file, or reading file information out of the backup set catalog during the Matching step of a backup), it quickly verifies the data read from its own file and verifies that it matches the checksum originally stored with the data. If the data no longer matches the original checksum, it has become corrupt, and Retrospect reports a "chunk checksum" error. Typically this type of error occurs only with a specific backup set, or on launch, if your main configuration file has become corrupt.
• Exception and Access violation errors – These are errors reported by the operating system when Retrospect crashes.

When experiencing one of these errors it is very important to restart the computer following each error message. Running Retrospect immediately following an error of this type without a system restart may leave Retrospect or even Windows in an unstable state.

Troubleshooting Tips

A few definitions will help clarify the terminology:

• Assert error – An "assert" error results in a dialog put up by Retrospect that halts operation. The dialog is the result of an internal consistency check in Retrospect that has failed. The only choice at this point is to quit Retrospect.
• Chunk checksum error (-641) – Retrospect stores information in its backup set catalogs in "chunks" of data, each stored with a checksum, a number that helps verify data integrity. When Retrospect reads a chunk of data (for example when opening its configuration file, or reading file information out of the backup set catalog during the Matching step of a backup), it quickly verifies the data read from its own file and verifies that it matches the checksum originally stored with the data. If the data no longer matches the original checksum, it has become corrupt, and Retrospect reports a "chunk checksum" error. Typically this type of error occurs only with a specific backup set, or on launch, if your main configuration file has become corrupt.
• Exception and Access violation errors – These are errors reported by the operating system when Retrospect crashes.

When experiencing one of these errors it is very important to restart the computer following each error message. Running Retrospect immediately following an error of this type without a system restart may leave Retrospect or even Windows in an unstable state.

Troubleshooting Tips

Search Online Retrospect Resources

First, search the Retrospect Knowledgebase for your error code.

For example, if Retrospect stopped with an assert error with the text "module.cpp-457", search the web database for this phrase. If the error you are experiencing is a known issue, you will find an entry, along with instructions for recovering from the error.

If the Knowledgebase does not have an entry for the problem you are experiencing, you may also want to try searching our Forum.

If you cannot find a posting regarding the specific error, the information below will help you troubleshoot further.

Further Troubleshooting

First, identify when the error occurs. The most important step in identifying the source of the problem is to identify what operation or action is happening when the error occurs. Below are general notes on the following operations:

• Launching Retrospect
• Scanning for devices, or opening the Configure>Devices window
• Scanning a source volume in a backup or duplicate operations
• Starting a backup/Updating Catalog
• Matching during a backup
• Matching during a restore

Launching Retrospect

If you get the error while launching, your configuration file may be corrupt. Fortunately, Retrospect makes a backup of your configuration file each time you quit. You may be able to simply swap the backup file for the corrupt file and continue normal operation. We recommend that you rename the possibly corrupt file, and not throw it away until you have resolved the problem.

Retrospect for Windows stores its configuration files in the following locations:

Retrospect 6.x and later for Windows: The ConfigXX.dat and ConfigXX.bak (substitute the XX for your version number) files are located at C:\Documents and Settings\All Users\Application Data\Retrospect or C:\Program data\Retrospect. Program data as well as Application Data are hidden folders that you must make visible.

Retrospect 10 and later: Try to remove the configxx.dat and configxx.bak files from the Retrospect Program Data folder. Then open Retrospect again. Your settings will automatically be imported from the configs.xml file.

Retrospect 9 and earlier: Try renaming the ".dat" version (try .old), and then renaming the ".bak" version to end in ".dat". Relaunch Retrospect. If the error is gone, your configuration was corrupt. If the error continues, your backup configuration file may also be corrupt. If this happens, try removing all versions of the config file to another folder, and then relaunch Retrospect. You will be forced to enter your license code. If Retrospect launches fine, then both your live and backup configuration files were likely corrupt. You may wish to restore a configuration file that you have in one of your backup sets from a point before the error started occurring. If the problem continues, even with a clean configuration file, please contact Technical Support for further assistance.

Scanning for devices, or opening the Configure>Devices window

If you get the error while scanning for Devices, or when opening the Configure>Devices window, the problem is likely device related. If this is the first time you have ever used Retrospect (in other words, if you just installed Retrospect and have never before scanned for devices successfully with Retrospect), please contact Technical Support for assistance.

If Retrospect was working fine previously, and you just recently added a device or changed your configuration, this may be the cause of the problem. If you added a device, try removing it, to see if this makes the error go away. (Remember to restart the computer between tests.) If this solves the problem, look up your new device in the Retrospect hardware database (http://www.Retrospect.com/hardware) to see if there are any special notes about using that device with Retrospect. If you recently changed your configuration, verify that the changes you made were made correctly, and/or consider reversing the changes as a test, to see if that clears up the problem.

Check for loose cables, and/or incorrectly configured hardware. Specifically, if you have changed an ATAPI device configuration, verify that you have the device DIP switches set properly for master and slave devices. If you are using a SCSI device, make sure you have each device set to a unique ID, with proper termination on the entire bus. Refer to the Retrospect User’s Guide for detailed information regarding SCSI termination. Make sure you have the latest recommended drivers installed for your SCSI card by checking the manufacturer’s web site. If you are using USB or IEEE 1394/FireWire devices, try removing one or more devices to simplify your bus, to see if this resolves the problem.

Scanning a source volume in a backup or duplicate operations

While very rare, Retrospect can report one of these errors during scanning of a source volume. If this occurs, check the disk for corruption using the built in Windows disk checking utility, or another disk utility program. If the problem is repeatable, it may be caused by file or folder names or structures on the hard disk. You may be able to narrow down the problem by defining a Subvolume in Retrospect for each top level folder on the hard disk, and then scanning each one at a time, to determine the folder that causes the problem. Then you may be able to rename files or folders to avoid the problem.

Try going to C:\ProgramData\Retrospect. Delete the rtrsec.dir folder and try to access the source volume again. If you are able to successfully backup a disk after removing the folder, this indicates the old rtrsec.dir folder contained a corrupted volume scan file.

If you continue to see errors when scanning a volume, try to disable instant scan for the source you are backing up.

Matching during a backup

After scanning a source for backup, Retrospect matches the files found on that source with the contents of the backup set you are backing up to. If a backup set catalog file (typically stored on your hard disk) is corrupt, you may get an error during matching. If you do, verify that the error occurs at the same place by repeating the operation. If it does, likely the catalog file is corrupt.

A quick way to test if a catalog file is corrupt is to perform a searching restore, entering any file name in the space when prompted, to force Retrospect to load and search every single session in the backup set. If the backup set catalog is corrupt, you may get an error similar to -641 (chunk checksum didn’t match) or -2241 (catalog invalid/damaged). If this happens, your backup set catalog is corrupt. This does not affect the data stored in your backup set media.

The best way to recover from this is to rebuild the backup set catalog from the media, using Tools>Repair in Retrospect. Retrospect 8 for Mac users should go to Media Sets and click Rebuild. Start with the last member of the backup set that you were using at the time of the error. The rebuild may take a while. If you have the backup set catalog backed up in another set, you may restore the file, and then do an "update existing" operation in Tools>Repair, which is quicker than a complete rebuild.

If this happens once, you may never know how the catalog became corrupt. If this happens chronically, review the notes below under Chronic Problems for tips.

Starting a backup/Updating catalog

Right after scanning and matching during a backup, Retrospect writes the source "Snapshot" to the backup set catalog. You may get an error at that time that includes "can’t save Snapshot". If you do, follow the tips in the note above for "Matching During a Backup."

Matching during a restore

If you get the error during restore preparation during the Matching phase, you likely have a corrupt catalog. Follow the tips in the note above for "Matching During a Backup."

Chronic Chunk or Catalog Problems

If you encounter chronic chunk or catalog related problems, you will need to determine and eliminate the cause. The errors may include but are not limited to:

• -641 chunk checksum didn’t match
• -642 chunk file map missing/damaged
• -643 not a chunk file or badly damaged
• -644 chunk file damaged during access
• -645 chunk file damaged during save
• -646 add resource failed
• -2241 catalog invalid/damaged
• -2243 catalog version incorrect

First, determine if the errors are occurring with many catalog files, or only with one. If only with one, rebuild the catalog as noted above in "Matching During a Backup", or simply start a new backup set. If the problems affect more than one backup set, you may have a hardware or system configuration problem that is causing repeated corruption of the backup set catalogs stored on your hard disk. We have seen these problems caused by specific failing hard disk.

Try running a surface disk check using Window’s Scan Disk utility or another third party disk checking utility to verify that there are no bad blocks on the hard disk.

Try storing your catalog files on a different hard disk. We have seen these errors caused by an unspecified hardware problem.

Verify that you are using the latest or the recommended version of disk or interface driver for the hard disk you are using. For many systems, you should simply be using the hard disk and interface drivers supplied by Windows, but with SCSI, USB, high end ATAPI, and IEEE 1394/FireWire disks you may want to check for updated drivers on the drive or interface vendors' web sites.

Try installing and using Retrospect on a different computer. If the problems go away, something was set up incorrectly in the original computer’s hardware or system software that caused regular corruption of data. Regardless of whether or not you are seeing problems with other applications or even with Windows on the original computer, if moving Retrospect solves the problem, then something was not working properly on the original computer.

Last Update: July 22, 2016