gahleniu Posted September 2, 2008 Report Share Posted September 2, 2008 I have seen a number of assertion failures listed on this forum but not this specific one [color:red]"elem.cpp-1000"[/color]. This occurred after this weekend after almost all of the end of month backups had been completed (Retrospect was upgraded to 7.6 last week). At the time the system failed, a transfer to tape was running and another backup (missing a source location) tried to start. Both operations failed and there was no record of either failure in the log files. Any insight on this error would be welcome. Quote Link to comment Share on other sites More sharing options...
emulator Posted September 6, 2008 Report Share Posted September 6, 2008 I'm not sure if this helps or not, but ever since upgrading to Retrospect 7.6.111, we have seen a very large number of Assertion failure at "elem.cpp-1000" errors. I posted a message on this very topic here: http://forums.dantz.com/showtopic.php?tid/28094/ Quote Link to comment Share on other sites More sharing options...
Mayoff Posted September 6, 2008 Report Share Posted September 6, 2008 This error is usually caused by a corrupt config75.dat file. Try to restore it from a backup created before you started getting the error. Quote Link to comment Share on other sites More sharing options...
emulator Posted September 7, 2008 Report Share Posted September 7, 2008 Hi Robin... Thanks for the hint. I do have a suggestion on future versions of Retrospect. It seems to me that putting the entire content of the Retrospect configuration into ONE file is a bit like putting all the eggs in one basket. Is there a way that maybe we could look at a modular approach? For example, if only one backup was corrupted and was causing the crash, we could just delete the config file for that one backup instead of slashing and burning everything. I will say that I have done the following: 1. I created a disk backup set called "Retrospect_DAT_Files". 2. I created a script to back up the "Retrospect" folder located at C:\Documents and Settings\All Users\Application Data\ every TWO hours. 3. I created another script to transfer this data to our tapes for offsite storage. Quote Link to comment Share on other sites More sharing options...
emulator Posted September 7, 2008 Report Share Posted September 7, 2008 Hmmmm..now this is interesting. We have a malfunctioning Server 2008 cluster, where drives drop offline and come back online randomly. When Retrospect goes to back up one of these drives that drops offline, BOOM!...that's where we get the crash. I'm removing the cluster computers completely and we'll see what happens tomorrow. Quote Link to comment Share on other sites More sharing options...
emulator Posted September 7, 2008 Report Share Posted September 7, 2008 Since removing the suspect Server 2008 cluster from the backups, Retrospect is running just fine. Robin, should a rogue client be able to crash Retrospect? Is this a bug? Quote Link to comment Share on other sites More sharing options...
Mayoff Posted September 7, 2008 Report Share Posted September 7, 2008 I have seen bad data being sent over the network cause a crash before. Retrospect requested some data from the client and the response was illegal and caused a crash. Quote Link to comment Share on other sites More sharing options...
emulator Posted September 18, 2008 Report Share Posted September 18, 2008 I have verified that this definitely IS something to do with the Server 2008 client. We have done the following: 1. Reset up the 2008 client (three times). 2. took the 2008 client out of the backup rotation (for two weeks); during this time, there were no crashes 3. put the 2008 client back into the backup rotation; two days later, the crashes started up again I have reported this to EMC. They requested by assertion logs. Quote Link to comment Share on other sites More sharing options...
tomoy Posted September 24, 2008 Report Share Posted September 24, 2008 Adding to Mayhoff's suggestion, I found a solution to my errors was to track down which Proactive script was running when the error occurred, deleted it, and rebuilt it. I think something about that script went bad during an upgrade form 7.0 to 7.6 for us. Quote Link to comment Share on other sites More sharing options...
snorkel Posted October 28, 2008 Report Share Posted October 28, 2008 I'd like to second this... When Retrospect is working it is absolutely awesome.. Easily the best backup system I've dealt with. However, when something breaks the *entire* thing breaks, and it almost always is the result of a dead config75.dat file. It is a poor to start off the morning when you realize that all of your backup jobs failed because of one problem. Quote Link to comment Share on other sites More sharing options...
stammbt Posted October 28, 2008 Report Share Posted October 28, 2008 Our client got hit with this today: "Assertion failure at "elem.cpp-1000". They are running 7.6.111.0. I've renamed the DAT file. But Retrospect won't launch. Keeps throwing the same error. A new DAT file is created but with the same date as the previous (10/20/2008). What can I do to get Retrospect to launch? Will I need to reinstall? or wipe out the config and start over? Quote Link to comment Share on other sites More sharing options...
jcapslock Posted May 28, 2009 Report Share Posted May 28, 2009 Thanks to tomoy. He had the answer in our case. I noticed that the error was always occurring during the day before lunch and there were two scripts that are running during the day. I jotted down their settings, deleted them and recreated them. It was a pain but better than nuking the config and rebuilding. It has been running without fault for two weeks now, so I feel pretty safe in saying it saved the day. I don't understand why store the whole config in one binary file if it is so easily corruptible? I mean sure, blowing away the config would have solved my problems after creating a lot of headaches but its like solving a leaky roof by bulldozing your house and rebuilding. Quote Link to comment Share on other sites More sharing options...
Sistemas Posted May 13, 2010 Report Share Posted May 13, 2010 I've the same problem with Retrospect Multiserver 7.7.325 / Driver Update 7.7.3.102. I don't understand why show the error this Retrospect Multiserver version?: [color:red]I read your post and I rename config77.dat to config77.datold and when the software start it generates a new config77.dat. Is this method correct?[/color] OS: Windows Server 2003 version 5.2 (build 3790), Service Pack 2, (64 bit) Application: C:\Program Files (x86)\Retrospect\Retrospect 7.6\Retrospect.exe, version 7.6.123 Driver Update and Hot Fix version 7.6.2.101 Exception occurred on 01/03/2010 at 13:46:26 Error info: Assertion failure at "elem.cpp-1000" Exception code: e0000000 ASSERTION Fault address: 7d4e237e 0001:0001237e (null) ERROR: Error while initializing dbghelp.dll, GetLastError: 0 (Address: 00000000) Thread ID: 3ac, Name: Execution thread EAX:06b96a9c CS:4030023 EIP:7d4e237e EFlags:00000206 EBX:021d5402 SS:002b ESP:06b96a98 EBP: 06b96aec ECX:00000000 DS:6064002b ESI:06b96b2c FS: 0053 EDX:00000001 ES:6b9002b EDI:06b96b2c GS: 68002b Module Fn (symbol or seg:offset in DLL) Args =============== ================================= ======================================================================= kernel32.dll 0001:0001237e e06d7363 1 3 6b96b20 6b96d34 313f65c e06d7363 1 bdrock20.dll __CxxThrowException +34 0 0 6b96d34 313f65c 21d5402 1 6b96b3c 6b966d8 bdrock20.dll DebugHandler::Throw +7C e0000000 1 1 6b96b90 6b96c90 600552f3 e0000000 1 bdrock20.dll assertLog +16 e0000000 1 6b96b90 'essA' 'oitr' 'af n' 'ruli' 'ta e' bdrock20.dll Debug +63 6007be6c 3e8 6b97aac 21d54a8 61429caf 10ee3 31395b0 61429caf bdrock20.dll ElementSpace::LmGet +D5 313953c 10ee3 '_psp' 31395b0 61429e00 9199 31395b0 6b96d00 TYCE.DLL tyceKGetItem +41 313953c 10ee3 '_psp' 31395b0 9199 6b97a74 6060c35c 313953c TYCE.DLL tyceKThreadGet +4A 313953c 10ee3 '_psp' 6b97a9c 10ee3 33c330 101b7590 6b9883c meson.dll ModuleData::send +79C 313953c 'TSHG' 10ee3 '_psp' 6b97a9c 10ee3 33c330 101b7590 TYCE.DLL proGetProv +6B 33c29c 10ee3 '_ppa' 6b97abc 33c330 33c330 6b97ad4 6141e341 TYCE.DLL proGetParent +5B 33c29c 10ee3 0 6b98848 6060c35c 33c29c 10ee3 200 TYCE.DLL proMatchParent +11 33c29c 10ee3 200 200 6b9ce28 3a0033 2e0000 3ed7008 meson.dll ModuleData::send +79C 33c29c 'PoMP' 10ee3 200 200 6b9ce28 3a0033 2e0000 ENGINEHI.DLL extoStartSource +4EA 5bd3c54 6b9b4e8 6b9b4e8 0 0 0 2 0 ENGINEHI.DLL extoBegin +85D 5bd3c54 0 5bd3c6c 0 27 0 0 0 meson.dll ModuleData::send +79C 5bd3c54 'ExBg' 0 5bd3c6c 0 27 0 0 meson.dll doTask +299 'ExOp' 0 5bd3c54 'ExBg' 6b9d2ec 6b9d2ec 6b9fcd0 6b9d534 meson.dll TThread::TaskSend +23 40318dc 'ExOp' 5bd3c54 'ExBg' 0 5bd3c6c 0 27 ENGINEHI.DLL execDoRun +237 5bd3c54 5bd3c6c -1 6b9e7a4 6060c35c 5bd3c54 31c0884 5bd3c54 meson.dll doTask +21E 'EScr' 2f8fc40 0 0 6b9da24 6b9da24 '@EXC' 6b9da30 meson.dll TThread::TaskCall +21 40318dc 'EScr' 2f8fc40 5bd3c54 5bd3c6c -1 6b9e7a4 6060c35c ENGINEHI.DLL execRun +4B 5bd3c54 31c0884 5bd3c54 324bbfc 0 41b82c4 8a3 4fdcc64 meson.dll ModuleData::send +79C 5bd3c54 'ExRu' 31c0884 5bd3c54 324bbfc 0 41b82c4 8a3 meson.dll TMesonMsg::Do +92 0 0 40318dc 0 2 0 6b9ebec 600428ca meson.dll TThread::mesonDoOne +155 40318dc 6b9eae4 6061163d 0 6b9ed8c 0 0 6b9ec40 meson.dll TThread::mesonQFlush +3E 0 6b9ed8c 0 0 6b9ec40 1 139 0 meson.dll msgHelper +2D 40318dc 1 6b9f048 6b9f530 21d54a8 2e01a8 40318dc 22f0000 meson.dll doTask +21E 'Msg ' 60611610 0 0 6b9efd4 6b9efd4 1 6b9f00c meson.dll TThread::TaskCall +21 40318dc 'Msg ' 60611610 40318dc 1 6b9f048 6b9f530 21d54a8 meson.dll TThread::MsgBlock +96 'Msg ' 6b9f4d0 606390ee 6b9f9c0 606390ee 'LopT' 40318dc 60045fef meson.dll msgInTask +1F 6b9f9c0 606390ee 'LopT' 40318dc 60045fef 0 4fdadfc 6b9fed4 meson.dll doTask +21E 'MsgT' 606128b0 0 0 6b9f508 6b9f508 40318dc 6b9f508 meson.dll TThread::TaskCall +21 40318dc 'MsgT' 606128b0 6b9f9c0 606390ee 'LopT' 40318dc 60045fef meson.dll loopInTask +27 'LopT' 40318dc 60045fef 0 4fdadfc 6b9fed4 60641d52 0 meson.dll doTask +21E 'LopT' 60612880 0 0 6b9f9f8 6b9f9f8 4fdae00 6b9fa18 meson.dll TThread::TaskCall +21 40318dc 'LopT' 60612880 'LopT' 40318dc 60045fef 0 4fdadfc meson.dll TThread::MsgLoop +45 'LopT' 0 6b9fee0 606390ee 2e81a7c 4fdbedc 313953c 112a7 ENGINEHI.DLL execMakeThreadProc +93 2e81a7c 4fdbedc 313953c 112a7 1105b 1 11064 4 meson.dll doTask +21E 'Task' 2f8c840 0 0 6b9ff18 6b9ff18 '``EF' 6b9ff84 meson.dll TThread::TaskCall +21 40318dc 'Task' 2f8c840 2e81a7c 4fdbedc 313953c 112a7 1105b meson.dll modThreadRoot +15B 4fdae28 0 0 21d54a8 0 6b9ff90 0 6b9ffdc MSVCR71.dll 0001:00008565 21d54a8 0 0 21d54a8 0 6b9ffc4 0 -1 kernel32.dll 0001:0000fe37 Quote Link to comment Share on other sites More sharing options...
draesmith Posted June 16, 2010 Report Share Posted June 16, 2010 I am getting this same assertion error elem.cpp-1000 with Retrospect Express HD 2.5 and it is refusing to carry our any 'restore' operation, and hangs at the scanning stage. Any advice? Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted June 17, 2010 Report Share Posted June 17, 2010 I am getting this same assertion error elem.cpp-1000 with Retrospect Express HD 2.5 and it is refusing to carry our any 'restore' operation, and hangs at the scanning stage.Any advice? Try the Retrospect Express forum.  http://forums.dantz.com/showforum.php?fid/14/ Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.