Ericfoos Posted April 24, 2003 Report Share Posted April 24, 2003 Windows XP Pro Dell Optiplex 1.7GHz 512 MB Ram Multi Server Edition 6.0.206 Backup media is 4 USB2.0 Drives I am trying to restore selected files. I chose the session I want and a destination for it. While it is matching, I get.. Retrospect Failure Notification "assert.exe" An internal consistency check failed. Detailed technical information on this problem is being written to the file "assert_log.utx". Retrospect will exit after this completes. That's all fine and good except THERE IS NO ASSERT_LOG.UTX!!! I let it rebuild it's catalog for 3 days to try again and have the same thing fail. Has anyone else seen this? Link to comment Share on other sites More sharing options...
IDSHelpdesk Posted April 25, 2003 Report Share Posted April 25, 2003 I see similar problem on the following configuration :- Athlon XP 1600+ 256MB RAM Windows ME Multi Server Edition 6.0.206 backing up to HP SureStore 5000 DAT tape. Retrospect seems to recover on restart though like you I have had to recatalogue if the failure happens at the "wrong time" Link to comment Share on other sites More sharing options...
AmyJ Posted April 25, 2003 Report Share Posted April 25, 2003 The assert log should be located in the following (hidden) directory: C:\Documents and Settings\All Users\Application Data\Retrospect Link to comment Share on other sites More sharing options...
Ericfoos Posted April 25, 2003 Author Report Share Posted April 25, 2003 OK, so there's the file. Should I send it in? Would that be helpful? Not being able to restore from snapshot, selected files, even after a lengthy rebuild has reduced the confidence my employers have in the system. Link to comment Share on other sites More sharing options...
RedPower Posted April 28, 2003 Report Share Posted April 28, 2003 Hi there, does anybody have a clue how to fix this problem? as unlike some of you my system will not sort it self out on a restart... Dantz list this a "MAJOR ERROR" and all they say is to restart and if the error occurs again, contact them. They sent me here. Link to comment Share on other sites More sharing options...
AmyJ Posted April 28, 2003 Report Share Posted April 28, 2003 What's the exact assert error? Please see the following KB article on assert troubleshooting: http://www.dantz.com/index.php3?SCREEN=kbase&ACTION=KBASE&id=26642 Link to comment Share on other sites More sharing options...
Ericfoos Posted April 28, 2003 Author Report Share Posted April 28, 2003 The error I got is what I put in my initial post: "Retrospect Failure Notification "assert.exe" An internal consistency check failed. Detailed technical information on this problem is being written to the file "assert_log.utx". Retrospect will exit after this completes." I followed the troubleshooting technique which suggested I rebuild the catalog. "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."" "Matching during a backup: ...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...." The rebuild took 3 days(My set is 500GB). It failed again when I attempted to restore. Now what? Link to comment Share on other sites More sharing options...
FSIWEBS Posted May 2, 2003 Report Share Posted May 2, 2003 We are getting these errors now everytime our EZ17(autoloader) starts to look for a tape. As we were instructed, I did a search on my particular error "task.cpp-328" and found nothing in the knowledgeBase. Has anyone heard of a fix for this nighmarish situation? Mayoff???? Link to comment Share on other sites More sharing options...
Ericfoos Posted May 5, 2003 Author Report Share Posted May 5, 2003 Bump Link to comment Share on other sites More sharing options...
AmyJ Posted May 5, 2003 Report Share Posted May 5, 2003 What's the exact assert error? It's listed in the assert log. First, determine if the errors are occurring with many catalog files, or only with one. 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 have a copy of the catalog backed up to another backup set, you can restore an older version and use Tools > Repair > Update existing catalog file to bring it up to date and save some time. Keep a second copy of the catalog file safe, should the original continue to become corrupt. Link to comment Share on other sites More sharing options...
Ericfoos Posted June 25, 2003 Author Report Share Posted June 25, 2003 All seemed well until I needed to restore a file from a Linux client. During both a Selected Files and a Find Files restore, I got Assertion failure at "elem.cpp-861". The last entry from assert_log.utx is as follows. Any hints as to what is going wrong? Thread ID: 00000A34, Name: Main thread EAX:00000000 CS:001B EIP:7FFE0304 EFlags:00000202 EBX:00000000 SS:0023 ESP:0012DF20 EBP: 0012DF78 ECX:001767FC DS:0023 ESI:00000000 FS: 003B EDX:00000000 ES:0023 EDI:0012DF60 GS: 0000 Module Fn (symbol or seg:offset in DLL) Args =============== ================================= ======================================================================= 0000:00000000 0 0 60044D24 0 0012DF9C 6060CAE7 0 0012DFE0 kernel32.dll 0001:00000BF1 0 0012DFE0 6060EF0C 0 0012E274 0 0 6060CB40 meson.dll ModKernelEnter +4C 0 0012E274 0 0 6060CB40 1 0 1 meson.dll msgHelper +37D 001767FC 1 0012E548 0012EA30 0 0 0 001767FC meson.dll doTask +21E 'Msg ' 6060EB8F 0 0 0012E4D0 0012E4D0 1 0012E50C meson.dll TThread::TaskCall +21 001767FC 'Msg ' 6060EB8F 001767FC 1 0012E548 0012EA30 0 meson.dll TThread::MsgBlock +96 'Msg ' 0012E9D0 6062B461 0012EEC0 6062B461 'LopT' 001767FC 011F35B8 meson.dll msgInTask +1F 0012EEC0 6062B461 'LopT' 001767FC 011F35B8 0 0012F3D8 0012F3D8 meson.dll doTask +21E 'MsgT' 6060FAFD 0 0 0012EA08 0012EA08 001767FC 0012EA08 meson.dll TThread::TaskCall +21 001767FC 'MsgT' 6060FAFD 0012EEC0 6062B461 'LopT' 001767FC 011F35B8 meson.dll loopInTask +27 'LopT' 001767FC 011F35B8 0 0012F3D8 0012F3D8 606323DF 0 meson.dll doTask +21E 'LopT' 6060FAD1 0 0 0012EEF8 0012EEF8 0 0012EF18 meson.dll TThread::TaskCall +21 001767FC 'LopT' 6060FAD1 'LopT' 001767FC 011F35B8 0 0012F3D8 meson.dll TThread::MsgLoop +45 'LopT' 0 0000000B 0012F3E4 6062B461 0 0012FF1C 61110C9F meson.dll mesonGo +122 0 0012FF1C 61110C9F 0 0 0 0 01000000 meson.dll doTask +21E 'Prog' 606084E3 0 0 0012F41C 0012F41C 00000A38 0012F420 meson.dll TThread::TaskCall +21 001767FC 'Prog' 606084E3 0 0012FF1C 61110C9F 0 0 meson.dll Meson +2C 0 0 0 0 01000000 00000009 0 0 Retrospect.exe _WinMain +2AF 61100000 0 001523BB 1 0 1 7FFDF000 F2623C5C Retrospect.exe _WinMainCRTStartup +191 0 1 7FFDF000 F2623CF4 0012FFC8 8052F104 -1 77E9BB86 kernel32.dll 0001:0001DB69 Link to comment Share on other sites More sharing options...
Ericfoos Posted June 25, 2003 Author Report Share Posted June 25, 2003 Although I now see that what I posted is an incomplete entry in assert_log.utx. After a reboot I got elem.cpp-855. I read that that error was related to certian NICS. The client in this case is a Dell PowerEdge 2650 with gigabit NIC's. I pray that's not the problem as all of our servers have those same built in NIC's. Link to comment Share on other sites More sharing options...
AmyJ Posted June 25, 2003 Report Share Posted June 25, 2003 elem.cpp-861 - Retrospect 6.0/6.5 for Windows users may experience this assert when doing an Immediate>Restore>Search if the backup set contains linux files. Try doing a restore via the Snapshot to avoid this problem. Dantz is investigating the cause and hopes to resolve the problem with our next release. elem.cpp-855 -- What is Retrospect doing when the assert error occurs? Is it reproducible? Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.