Jump to content

6.0: "assert.exe" internal consistency check failure


Recommended Posts

I'm fairly annoyed after some 6 hours of troubleshooting. Every time I include the perfectly innocuous folder "C:\Documents & Settings\[user=my standard account]\Local Settings\Application Data\Microsoft" in the source for backup, I get the following error:



An internal consistency check failed."


Retrospect writes detailed info to the assert_log.utx file, and quits. The error text (4K) can be found in plaintext here. It occurs after files are scanned, after a few seconds of "preparing to execute...".


I've seen Technote 307, but that's about all there is in the Dantz KB for this one. I've tried:

1) renaming my config files (main and .bak), allowing Retrospect to recreate them (a corrupted Retrospect prefs file once resulted in an assert error with a Mac backup server I administer; unfortunately, no dice here);

2) creating new backup sets;

3) defining all top-level folders as volumes, as per technote 307--this is how I ultimately narrowed the problem folder down to the one noted above;

4) running Norton Windoctor and running CHKDSK with fix errors on a restart (drive is NTFS);

5) disabling hibernation to delete the hiberfil.sys file on a lark (I'm reaching!);

6) uninstalling Retrospect and renaming my catalogs folder (which, incidentally, I do not allow to default to MyDocs because I see no point in storing large catalogs in my regular backup set; I set the catalgs folder to "C:\Retrospect Catalogs");

7) purging any remaining refs to Retrospect and its files from the registry;

8) disabling ani-virus software and closing all non-essential processes;

9) reinstalling Retrospect, and starting from scratch.


Still, I get the error.


Following on item #3, above: The problem folder is "C:\Documents & Settings\[user]\Local Settings\Application Data\Microsoft". When I defined its subfolder "Outlook" as a subvolume, the error occurred. So I moved the Outlook subfolder to another drive and selecting it as a source did NOT cause the error, but I still got the error on the parent Microsoft folder. I tested every other subfolder separately, with no error, but still the Microsoft folder produces the error. Its subfolders can be seen in this screenshot.


I moved the Outlook subfolder back to the Microsoft parent folder, and tried again after logging out as my username (Admin group) and logging back in as Administrator. Guess what? No error on trying to back up the Microsoft folder, or any other for that matter.


What on earth is going on here? This seems almost certainly to be a bug in Retrospect 6.0: why should a particular pathname string result in an assertion error when a particular user is logged in, but not when another user is logged in? I'd very much appreciate a Retrospect engineer's comments on this.





Link to comment
Share on other sites



This is indeed strange but I'm not yet convinced it is a bug. If it were I think we would see a lot of this.


Are you using the open file backup option? How about the "force backup of outlook data" option? Does this happen for every user on the machine or just certain users? Does the backup run if you create a selector to backup that folder rather than define it as a subvolume?




Link to comment
Share on other sites

  • 1 month later...

Hi, Nate. Nope, not using OFB, nor the "force" option. I just close all open files and most apps (including Outlook, which I don't use all that much in the first place).


As for the user: this seems to be the clincher. My notes seem to have been buried in the avalanche of papers here, but as I recall the last thing I discovered was that I did not get the error when logged in as Admin.


I'm not averse to logging in as another user to run my backups if it's the only option (I'm the only user on this box), but since this is more hassle than I like I'd prefer to get to the bottom of why one user would be a problem but not another.



Link to comment
Share on other sites


This topic is now archived and is closed to further replies.

  • Create New...