Jump to content
gahleniu

Assertion Failure at "elem.cpp-1000"

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×