eladouceur Posted January 14, 2003 Report Share Posted January 14, 2003 Good Morning! Something went bump in the night. -- assert_log.uxt OS: Windows 2000 version 5.0 (build 2195), Service Pack 3 Application: E:\Dantz\Retrospect.exe, version 6.0.206 Exception occurred on 1/14/2003 at 12:10:56 AM Error info: Assertion failure at "wind.cpp-6622" Exception code: E0000000 ASSERTION Fault address: 77E9E8BB 0001:0001D8BB KERNEL32.dll -- -- EventViewer Event Type: Information Event Source: Application Popup Event Category: None Event ID: 26 Date: 1/14/2003 Time: 12:10:57 AM User: N/A Computer: HST078 Description: Application popup: assert.exe - Application Error : The application failed to initialize properly (0xc0000142). Click on OK to terminate the application. -- -- operations_log.utx - 1/13/2003 11:35:15 PM: Copying SourceSafe$[3] on HST008 1/13/2003 11:35:15 PM: Connected to HST008 : URegisterClass failed: 87. : URegisterClass failed: 87. : URegisterClass failed: 87. : URegisterClass failed: 87. : URegisterClass failed: 87. : URegisterClass failed: 87. : URegisterClass failed: 87. : URegisterClass failed: 87. : URegisterClass failed: 87. : URegisterClass failed: 87. : URegisterClass failed: 87. : URegisterClass failed: 87. : URegisterClass failed: 87. : URegisterClass failed: 87. : URegisterClass failed: 87. : URegisterClass failed: 87. : URegisterClass failed: 87. : URegisterClass failed: 87. : URegisterClass failed: 87. : URegisterClass failed: 87. : URegisterClass failed: 87. : URegisterClass failed: 87. : URegisterClass failed: 87. : URegisterClass failed: 87. : URegisterClass failed: 87. : URegisterClass failed: 87. : URegisterClass failed: 87. : URegisterClass failed: 87. -- It seems that the crash was an aftershock of the strange job failure. The failure being what worries me. Fire away any questions you may have. Thanks! -=Erik Link to comment Share on other sites More sharing options...
AmyJ Posted January 14, 2003 Report Share Posted January 14, 2003 Tech Note NO. 307 WINDOWS INTERNAL CONSISTENCY CHECK AND CONFIGURATION ERRORS Windows assert, chunk checksum, exception, and access violation 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. Similarly, if Retrospect crashes, you may receive an alert from Windows 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: 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 Windows 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 Dantz Resources First, search the Dantz online Knowledgebase (found at www.dantz.com/support) for the error code reported. 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. 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 - Starting a backup/Updating Catalog... - Matching during a backup - Matching during a restore - Preparing for Disaster Recovery 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.0:The Config60.dat and Config60.bak files are located at C:\Documents and Settings\All Users\Application Data\Retrospect Retrospect 5.6/5.5:The Config55.dat and Config55.bak files are located by default at C\Program Files\Dantz\Retrospect. 5.15 and earlier: The Config5.dat and Config5.bak files are located by default at C:\Program Files\Dantz\Retrospect. Try renaming the ".dat" version (for example, put an "a" in front of the name), 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 Dantz 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 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 (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 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. 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. 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." Preparing for Disaster Recovery If you get the error during disaster recovery preparation, it may be worth trying to prepare using a different backup set. Whether or not this works, we recommend that you contact Dantz Technical Support for assistance. 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. 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. List of Known Errors and Workarounds The following is a partial list of assert errors and their resolutions: module.cpp-646, This error may occur when trying to use the erase all option in Retrospect 5.0. Upgrade to the latest version of Retrospect for Windows. droxy.cpp-1357, This error may occur when quitting Retrospect 5.0. Upgrade to the latest version of Retrospect. scsitools.cpp-2911, This error may be corrected by updating your SCSI card drivers and firmware to the latest version available from the card vendor. module.cpp-457, This error in Retrospect 5.5 is caused by using keyboard shortcuts for Add (alt-A) or Modify (alt-M) during Disaster Recovery. Use your mouse to click the necessary buttons. The problem is fixed in the latest version. statefile.cpp-150, This error in Retrospect 5.5 or earlier can usually be avoided by turning off backup of NTFS security information. This option can be found under Options for your script or backup operation. The problem is fixed in the latest version. tstring.cpp-550, This error occurs in Retrospect 5.5.144 if you attempt to duplicate from one source to a destination both on the same client computer. This is not supported in Retrospect. Choose a different volume for the source or destination. The latest version of Retrospect does not assert, but instead properly reports that this is an unsupported operation. tmemory.cpp-583, Upgrade to Retrospect 5.6 or later to avoid this error. memutil.cpp-198, Upgrade to Retrospect 5.6 or later to avoid this error. drwizard.cpp-1620, Upgrade to Retrospect 5.6 or later to avoid this error. scsitoolsNTPT.cpp-1016, Upgrade to Retrospect 5.6 or later to avoid this error. module.cpp-254, Upgrade to Retrospect 5.6 or later to avoid this error. isox.cpp-692, upgrade to Retrospect 5.6 or later to avoid this error. Link to comment Share on other sites More sharing options...
eladouceur Posted January 14, 2003 Author Report Share Posted January 14, 2003 Please address the failed backup errors. This is the root of the problem. : URegisterClass failed: 87. The Assert.exe Error occured more than half a day after this final entry in my operations_log.utx. Link to comment Share on other sites More sharing options...
eladouceur Posted January 15, 2003 Author Report Share Posted January 15, 2003 Knowledge Base: Your search for "wind.cpp-6622" returned 0 results Link to comment Share on other sites More sharing options...
eladouceur Posted January 16, 2003 Author Report Share Posted January 16, 2003 Knowledge Base: Your search for "URegisterClass failed: 87. " returned 1 result The one result it returned is this: 0% org.apache.lucene.queryParser.ParseException: Encountered "AND" at line 1, column 29. Was expecting one of: "(" ... ... ... ... ... ... ... ... at org.apache.lucene.queryParser.QueryParser.generateParseException(Unknown Source) at org.apache.lucene.queryParser.QueryParser.jj_consume_token(Unknown Source) at org.apache.lucene.queryParser.QueryParser.Clause(Unknown Source) at org.apache.lucene.queryParser.QueryParser.Query(Unknown Source) at org.apache.lucene.queryParser.QueryParser.parse(Unknown Source) at org.apache.lucene.queryParser.QueryParser.parse(Unknown Source) at com.dantz.search.Search.main(Search.java:42) Exception in thread "main".. Pretty much a FYI. Link to comment Share on other sites More sharing options...
AmyJ Posted January 16, 2003 Report Share Posted January 16, 2003 URegisterClass failed: 87 -- This is debug logging that is being erroneously reported in the Operations Log. It is cosmetic in nature only, and does not affect functionality. It will be removed from a future release. Link to comment Share on other sites More sharing options...
AmyJ Posted January 17, 2003 Report Share Posted January 17, 2003 wind.cpp-6622 : We're going to do some further research on this assert error. Information will be posted to the Knowledgebase when it becomes available. Thanks for your patience! Link to comment Share on other sites More sharing options...
eladouceur Posted January 17, 2003 Author Report Share Posted January 17, 2003 Thanks for your time. I'll check back in a couple weeks barring a reoccurance. Link to comment Share on other sites More sharing options...
eladouceur Posted February 11, 2003 Author Report Share Posted February 11, 2003 Your search for "wind.cpp-6622" returned 0 results No progress? Link to comment Share on other sites More sharing options...
Mayoff Posted February 11, 2003 Report Share Posted February 11, 2003 Hi, This issue was investigated by our engineers as a bug which they believe should be fixed in our next product release. A release date is not yet available. If you have a script with a large number of sources, you might be able to workaround the problem by splitting the large list of sources into multiple scripts. This workaround has not been tested, but might make things work smoother. I also suspect quitting and relaunching Retrospect more frequently could also help out. Link to comment Share on other sites More sharing options...
eladouceur Posted February 11, 2003 Author Report Share Posted February 11, 2003 I do have one proactive server session running 15+ scripts each with their own source. No single script has more than one subvolume which it backs up. I will schedule a bounce of Retro for once a week, just to keep it on its toes, and hope this issue doesn't resurface. Thanks for the info! -=Erik Link to comment Share on other sites More sharing options...
Mayoff Posted February 11, 2003 Report Share Posted February 11, 2003 You may want to try and put all the sources into a single script if you can (the destination usually is the deciding factor). Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.