Assertion failure at "elem.cpp-845"

[cowart]

Running 5.6 Server on Windows NT 4.0

 

 

 

Got error message 'Assertion failure at "elem.cpp-845"', but I can't find it in the Knowledgebase

 

 

[nas]

I was doing a complete full backup of all files on my hard drive and had successfully put data on 2 Maxell 650MB CD RW discs. It asked for a third disc and I only had one that had previously been formatted. I decided to use a new package of TDK 650MB CD RW discs. I put one in and it looked like Retrospect was trying to erase data from it but then I got an error. It said something about "bad media" or "dirty heads". I thought that was unlikely so I decided to try putting in the formatted Maxell disc and it said it was "unrecognized". I told it to go ahead and erase anything on the CD and it was in the process of doing that when I saw the error "assertion failure at cdru_base.cpp-1835".

 

 

 

This looks like a similar error to the one cowart is seeing. I'm assuming the assertion error was due to the fact that the Maxell CD RW disc was formatted however I don't know why I got an error when I tried to use a TDK CD RW disc. Does anyone have any suggestions?

 

 

 

Thank you,

 

Nancy

[lv2ski]

Retrospect for Windows uses an internal integrity checking system which will

 

alert the user to problems encountered when performing tasks within

 

Retrospect. These "assert" and "chunk checksum" errors could be caused by

 

corruption to a vital Retrospect file, memory corruption or a system

 

compatibility problem. In addition to the above errors, Retrospect may also

 

report "Exception" and "Access Violation" errors.

 

 

 

When experiencing assert, access violation or exception error messages 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 in an unstable state.

 

 

 

When troubleshooting these errors it is important to identify what task

 

Retrospect was attempting to perform at the time the error is reported.

 

Knowing when the error happens will help identify the best course of action

 

for the resolution of the problem.

 

 

 

During Retrospect Launch

 

If Retrospect reports an assert error when launching, a likely cause for the

 

error would be corrupt Retrospect preferences. Try moving the config55.dat

 

and config55.bak files onto the Windows desktop. These files can be found in

 

the Retrospect folder located within the Program Files directory. The

 

config55.dat file contains all of your Retrospect scripts, options and the

 

database of logged in clients (if appropriate). The config55.bak is a backup

 

copy of the .dat file. Restart the computer and attempt to launch Retrospect

 

again. You will be asked to enter your license code before reaching the

 

Retrospect Directory.

 

 

 

If launching Retrospect was successful after removing the config files from

 

the Retrospect folder, then this indicates the previous config55.dat file

 

may have been damaged. Quit Retrospect and return to the Windows Desktop.

 

Rename the config55.bak file to config55.dat and move the file to the

 

Retrospect folder (replacing the config55.dat file currently found in the

 

Retrospect folder). Launch Retrospect again. If launching Retrospect is

 

successful then you have fixed the error.

 

 

 

If the error message has returned, then you will need to revert to default

 

Retrospect preferences or restore the config file from a backup performed

 

prior to the corruption. To do this, delete the config55.dat and

 

config55.bak from the Retrospect folder. Restart the computer if you have

 

not done so since the previous error message. Launch Retrospect and enter

 

your license code, Retrospect will automatically create a new set of

 

preferences. At this point you can recreate your scripts and login your

 

existing clients on the network or restore the config55.bak file from your

 

older backup. Once the config55.bak is restored, you should rename it to

 

config55.dat and place it in the Retrospect folder.

 

 

 

When Saving Snapshot, Updating Catalog or Trouble Matching

 

During a backup Retrospect may report that it can not save changes to the

 

Snapshot or the Snapshot could not be saved due to an error ­641 (chunk

 

checksum failed) or ­2241 (damaged catalog). Retrospect may also report

 

"trouble matching" errors when doing a backup or restore. These errors often

 

indicate corruption within a Retrospect backup set catalog file.

 

 

 

When troubleshooting these error messages it is important to identify which

 

catalog file is damaged. The operations log will often indicate which

 

catalog file was being accessed at the time this error occurred. If the

 

errors appear isolated to one specific catalog file you will need to either

 

rebuild the catalog from the media (chapter 9 of the Retrospect User's

 

Guide) or create a new backup set to replace the one reporting the error.

 

 

 

You can also try the following technique to identify which catalog file is

 

damaged. Set up a restore by searching on a blank file name so Retrospect

 

scans all files in the catalog. If the error occurs, you know this catalog

 

is corrupt.

 

 

 

During File Copy

 

If Retrospect reports an "Internal Consistency Check" or "Access Violation"

 

error during the copy phase of a backup or restore you may be experiencing

 

one of several possible problems. It is important to first restart the

 

computer following the error. For many users the error will not return

 

following a system restart. Try the previous operation again. Try to

 

reproduce the problem using a different backup set. If the problem is solved

 

by trying a different backup set, you may need to rebuild the catalog file

 

for the previous backup set.

[nas]

Thank you for the information Melissa. Per the instructions I received after the error, I copied the entire assert_log.utx file and sent it to the technical support email address. I received a note explaining the fact that tech support is now charging. Not much good the file does in my hands since I can't determine exactly what process it was working on when the error occurred.

 

 

 

The backup had been working beautifully and I had already filled 2 CD's with data. The first error occurred when I placed a new CD (TDK brand) into the CD RW drive. It stated "Device trouble: '3-June162002_BU1' error -206 (drive reported a failure: dirty heads, bad media, etc.)". I tried a second new CD but got the same error. Since I only had one Maxell disc left, I decided to try it but knew it was a formatted disc. When I put the CD in, it said it was "unrecognized". I thought that if there was something on it, erasing it would help. It began the erasing process and was working for about 10 minutes when the assert error appeared. It said "assertion failure at cdru_base.cpp-1835". At this point I gave up, shut off the PC. This morning I thought I would try again and start from scratch so I put in the TDK disc and got the same "device trouble error -206" message. I downloaded the latest driver this morning and rebooted the system but am still seeing errors.

 

 

 

To summarize, I'm not getting any errors when I launch Retrospect Express, nor am I seeing any errors about saving changes to the snapshot. It seems to me that it had something to do with the TDK CD.

 

 

 

Since the program doesn't allow me to use my new batch of TDK CD RW discs, can I overwrite the original full backup copy? Do I have to erase each CD first? If that won't work, I'll return the TDK CDs and purchase more Maxell's unless you think there's something else I can try.

 

 

 

Again, I appreciate your reply Melissa.

 

 

 

Thanks,

 

Nancy

[lv2ski]

At this point, create a new backupset and use new cds. See what happens. This is to try to get rid of the 206 error.

 

 

 

Asserts are interesting. They can come, and never come back again. You may never see that assert again. It's just the way they work. If you ever get one in the future, just reboot and see if it is reoccuring. If it is, then there is a problem that needs to be solved. If it doesn't come back, then you won't see it again.