Altair Posted September 13, 2002 Report Share Posted September 13, 2002 I recieved an error when backing up to a set about 5 cd-r's in to a set. a box appeared with: Trouble in Retrospect; interna consistency check failed; assertion check at "Elem.C-811. Any insight as to the error would be appreciated. Thanks John Link to comment Share on other sites More sharing options...
AmyJ Posted September 16, 2002 Report Share Posted September 16, 2002 From the Knowledgebasecolor=blue>: http://63.95.223.84/index.php3?SCREEN=kbase&ACTION=KBASE&preview=y&id=26641 Tech Note NO. 307 MACINTOSH INTERNAL CONSISTENCY CHECK AND CONFIGURATION ERRORS Macintosh assert and chunk checksum errors 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. 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: 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. 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 Dantz Resources First, search the Dantz online Knowledgebase (found at http://www.dantz.com/support ) for the error code reported. For example, if Retrospect stopped with an assert error with the text "elem.c-696", 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. This note also contains a list of known assert errors. Search the list at the end of this document to see if the error you are experiencing is in our known list. If the Knowledgebase does not have an entry for the problem you are experiencing, you may also want to try searching our Forum, also accessed via the web site. 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 - Scanning Icons - Starting a backup/Updating Catalog... - Matching during a backup - Matching during a restore - Third-Party Software Conflicts - Operating System Launching Retrospect If you get the error while launching, your configuration file may be corrupt. Retrospect for Macintosh stores its configuration files in the following locations: OS 9.x: In a folder named "Retrospect" inside your System Folder's Preferences folder. (:System Folder:Preferences:Retrospect:). OSX: In the folder /Library/ Preferences/Retrospect/. Try moving the retro.config (4.2), (5.0) or Retro.Express Config (4.2), (5.0) file onto the trash (don't empty the trash). This file can be found in the Retrospect folder listed above. The retro.config (4.2), (5.0) or Retro.Express Config (4.2), (5.0) file contains all of your Retrospect scripts, options and the database of logged in clients (if appropriate). Restart the computer and attempt to launch Retrospect again. You will need to re-enter your license code. If launching Retrospect was successful after removing the config file from the Retrospect folder, then this indicates the previous configuration file may have been damaged. At this point you will need to recreate your scripts and login your existing clients. Rather than rebuild your scripts, some users may be able to restore an older version of the config file from a backup. 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 Dantz 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 Dantz hardware database ( http://www.dantz.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. If you are unable to determine the cause of the error, please contact Dantz Technical Support for assistance. 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 Disk First Aid (OS 9) or Disk Utility (OSX) 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. Scanning Icons If Retrospect reports an error when scanning "Icons" then you may have a corrupt Retro.Icon (4), (5) file. Try removing this file from the Retrospect Preferences folder. The file will be automatically recreated by Retrospect. 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 -24201 (chunk checksum didn't match) or -25040 (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. 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." Third-Party Software Conflicts Try disabling all non-Apple extensions and control panels. If that helps, enable extensions one by one, or by halves, restart, and test until the problem re-occurs, to narrow down which extension is causing the problem. Permanently disable the problem-causing extension, contact that vendor for possible updates, or check with Dantz to see if a workaround is known. Operating System Macintosh OS 9 users can try to reproduce the error message while booted from the Retrospect CD-ROM. If the error is not reproducible while booted from the Retrospect CD, then this may indicate a corrupt Mac OS system folder. A clean install of the Mac OS may be required to eliminate the error message. 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: -24205 chunk file damaged during save -24204 chunk file damaged during access -24203 not a chunk file or badly damaged -24202 chunk file map missing/damaged -24201 chunk checksum didn't match -24160 catalog is invalid/damaged -25040 catalog invalid/damaged -25045 file is not a catalog -25043 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 Disk First Aid or 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 the Mac OS on the original computer, if moving Retrospect solves the problem, then something was not working properly on the original computer. You may not be able to determine the cause, given how complex computers are. If you are unable to resolve the problems, please contact Dantz Technical Support for further assistance. Getting Help from Dantz Technical Support Should you be unable to solve an internal consistency error problem on your own, Dantz Technical Support will be glad to help you after a support incident is opened. http://www.dantz.com/support/support_options.html Partial List of Known Errors and Workarounds The following is a list of assert errors and their resolutions: elem.c-812 When closing a "get info" window in Retrospect 5.0 while the configure>Volumes browser is minimized, you may get an elem.c-812 assert error. To avoid this problem, do not minimize the Volumes browser. or Dantz released an update to Retrospect 5.0 for Macintosh that resolves this assert error when it occurs while backing up an AppleShare IP Server or other client running file sharing. Update to 5.0.205 or later (available at http://www.dantz.com/upgrades/ ). or Dantz released RDU 2.6 and found that some users were experiencing an elem.c-812 error when using file backup sets. This problem was fixed with RDU 2.6a or later available at: ftp.dantz.com/updates pcv_rem.c-1640 This may occur with Retrospect 3.0A when using the Retrospect Client for Windows to backup a PC with a damaged hard drive. Run ScanDisk on the Windows computer, to check for damage. Upgrade to the latest version of Retrospect. task.c-402 When the Retrospect Event Handler for Outlook Express or Entourage is present in the Retrospect Preference folder, Retrospect will assert with "task.c-402" if Retrospect attempts to shut down or restart after scripts. To work around this problem, manually launch Retrospect and set your Retrospect preferences to "don't quit". This will be fixed in a future update to Retrospect. dev.c-1027 This error occurs only in Retrospect 3.0. Upgrade to the latest version of Retrospect. elem.c-696 This error can occur when a run document is placed in the Shutdown Items folder on a Macintosh running under System 7.5 with Retrospect versions before 3.0. Update to the latest version of Retrospect. elem.c-897 There are three main reasons for this error: 1. The configuration file is damaged. (This is almost always the case and is especially likely if the error occurred while Retrospect or Retrospect Express was launching.) 2. A catalog file may be corrupt. 3. Retrospect 2.0A or an earlier version attempted to erase a removable cartridge while file sharing was turned on. Turn off file sharing or upgrade Retrospect to the latest version. malloc.c-97 This is usually a one-time error which does not re-occur after restarting your Macintosh. If it happens when going to Configure>Backup Sets, then you should upgrade Retrospect or Retrospect Express. tyce.c-2524 This error may occur if your Backup Server scripts are corrupted. Duplicate your scripts from the Automate>Scripts window and delete the original scripts. vhand.c-427 This is almost always a one-time error which does not re-occur after restarting your Macintosh. If it does re-occur, try the troubleshooting tips offered above. If you cannot resolve the problems, contact Dantz Technical Support. xscav.c-128 This error may occur when using an OnStream tape drive with Retrospect 4.2. Update to the latest version of Retrospect for the Macintosh . Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.