Retrospect's assert_log.utx

[kaikow]

Retrospect asserts tat there was an error.

Error occurred AFTER backup was completed.

 

How do I verify validity of config file?

 

I do not recall even seeing te 14 Jan 2004 report, but I did notice today's message..

 

Could not find the links to the list of technical reports.

Where goeth the list

What does the following mean?

 

There are two errors reported.

The one from 14 Jan 2004 is not relevant anymore, so I;ve deleted that error from the report.

----------------------------------------------------------------------

OS: Windows 2000 version 5.0 (build 2195), Service Pack 4

Application: J:\Program Files\Dantz\Retrospect\Retrospect.exe, version 6.5.350

Exception occurred on 6/13/2004 at 18:32:04

Exception code: C0000005 ACCESS_VIOLATION

Fault address: 00170EC3 7C57833C:00000000 gƒW|·

 

 

Thread ID: 0000055C, Name: Main thread

 

EAX:00130608 CS:001B EIP:00170EC3 EFlags:00010206

EBX:00000001 SS:0023 ESP:0012FD78 EBP: 0012FDB8

ECX:11026D48 DS:0023 ESI:00000000 FS: 003B

EDX:1095F5B8 ES:0023 EDI:0019DDF0 GS: 0000

 

 

Module Fn (symbol or seg:offset in DLL) Args

=============== ================================= =======================================================================

0000:00000000 00C00000 0 1 7FFDF000 0014E4E8 001537F0 0012FE40 77F8EE02

ntdll.dll 0001:000020E7 00C01F5E 00C00000 0 1 0 77F8EE04 7FFDF000 002F0168

ntdll.dll 0001:0000DE02 0065002E 1 7FFDF000 7FFDF000 108553C8 0012FDAC 10940E20 0012FEE4

KERNEL32.dll 0001:0000FED2 0 001339BB 78007C60 0 0 0 6111480E 0

MSVCRT.dll 0001:00006CD8 0065002E 00650078 7FFDF000 0 0012FFC8 0 -1 7C57E597

KERNEL32.dll 0001:00010AF6 611146B0 0 000000C8 00000100 EEFFEEFF 2 0 0000FE00

[natew]

Hi

 

Every time you launch Retrospect there is some checksumming that happens to make sure the config file is functional on a basic level. If it is really corrupt you will get a "chunk checksum" error.

 

If you are concerned you can remove the config65.dat file and use the config65.bak file instead. This will create a new .dat file based on the .bak next time you start Retrospect.

 

A lot of times asserts are caused by memory management problems. A reboot of the machine will usually sort them out for good. I don't know exactly why you got that assert error - they aren't of much use for day to day troubleshooting.

 

Thanks

Nate

[kaikow]

My gut feeling, and I do have a big gut, is that the error may have been due to the following:

 

1. Most of the time, I disable Norton Auntie Virus' AutoProtect either just before running Retrospect or just after entering Retrospect, sometimes during the execution phase. In the case in which I got the error, I do not recall exactly when I disabled NAV.

 

2. After the backup script runs, I usually look at the History, and then use the X to close Retrospect.

 

3. I usually wait until after I close Retrospect to enable NAV's AutoProtect. However, in the case in question, I enabled NAV very shortly before I hit the X. So there might have been a timing issue with NAV and Retrospect.

 

I am using NAV 2003.

 

I did a verify of the backup set and compressed the catalog, as well as using Retrospect several times since. So I guess the files are OK.

 

Perhaps, there could be an option to explicitly verify the validity of the config file?

Cryptic "assert" messages are not useful.

[natew]

Hi Howard,

 

That makes sense. There are a lot of things that can cause an assert. Your theory sounds plausible for sure.

 

Agreed the assert logs are not helpful. Basically the things that cause an assert are things that the user can't do much about. They are however very valuable information for our devellopers when investigating possible bugs.

 

Thanks

Nate