Skip to main content

ATI 2017 loop followed by .Net failure in Acronis Log Viewer

Thread needs solution

I probably shot myself in the foot here, and could use some direcetion in diagnosis and repair.

Shortly after running an "Entire PC" backup, something was killing performance on my PC, and Process Explorer showed ATI using about 14% of my cpu and doing a ton of I/O.  ATI was not scheduled to be doing anything and no backups were running.  This went on for about 5 minutes with on obvious change so I deciided I'd better restart my PC.  Shutdown hung.  After another 5 minutes or so I decided to do a forced power-off.  Everything seemed to comeback up with no problem, but when I ran the Acronis Log Viewer (v 2.2) to see what ATI had been doing it immediately presented a .NET failure popup: Arithmetic operation resulted in an overflow".  Hitting "Continue" results in the log display with no logs shown.

At least one other program that uses .Net seems to be fine, but that may mean nothing - they may not use the same .Net functions.  

As near as I can see, Acronis logs are still present and readable, but I'd never know if one important one was missing or corrupted.  I just tried running a short "Files and Folders" backup and it completed without error.  It also created "Service" log file showing a sucessful backup, but the Log Viewer still fails.

Any tips on how to find and correct the problem?  How do I determin if I have a >Net problem or if there is an ATI log error?

 

0 Users found this helpful

The log viewer was written using .NET so it would appear to me that given your description the Log Viewer has suffered corruption due to the forced shutdown.  I would recommend downloading the Log Viewer file again and use or install that to correct the issue.  If you installed the log viewer into Windows rather than running it stand alone then you wold need to uninstall it then reinstall.  If using it stand alone just delete the current file and use a fresh downloaded one.

I had been running the installed version.  Uninstalling and reinstalling resulted in the same error so, just to be sure, I downloaded the portable one.  Same error. 

Since I took a full backup shortly before this problem appeared, I should be able to do a restore if all else fails.  But maybe I'd better do a stand-alone verification first.

You should try to repair the .NET Framework installations in your Windows installs.  See the link below for a Microsoft Repair tool.

https://www.microsoft.com/en-us/download/details.aspx?id=30135

Thanks for the suggestion.  I downloaded the tool and gave that a try, but it said it couldn't resolve the problem and sent a report off to Microsoft.  I guess there really is something sercious going on.  I think I'll consider doing a restore.  I just got done doing a validation of the backup, but I need to build up courage before doing a full system restore.

If possible, try to restore to a different disk (just in case).  I know that not everyone has extra disks to spare, but if you do, then you can pull the original (even in it's current state, good to hold onto it until you've verified the restore on a different disk).  That way, if things go really bad, you're not overwriting the only live copy.  Backups are good, but it's just one extra precaution you can put to good use if you have a spare or old drive to test your recovery on before wiping out the main disk with the recovery data. 

Sorry to hear that.  Bobbo makes a very good point if you do restore.  While your getting up the courage you might run sfc /scannow (include the space) from an admin command prompt, it will scan all Windows system files and repair, if it can, any found corrupt.

I'm afraid I don't have a spare disk, and I'm running the scan right now.  DISM is next if the scan finds errors.

Thanks for the suggestions.

Update:  The scan found no errors.  I wasn't expecting that.

On the off chance that the problem is a log file, I'm going to kill all AAcronis tasks, rename my current Acronis ProgData folder, copy the one from yesterday's backup, and see if the log reader still chokes.  If that is unsuccessful (thus pointing back to .NET) I'll try a week old Restore Point.  Then the Acronis backup, and, as a last resort, a clean reinstall of Windows.  (Yuck!)

Ha!  I'm getting closer to a solution - probably half of the previously infinite distance.  My Loge_Reader no longer knows the default location of the Acronis logs.  I let the reader continue after reporting the .Net failure and click on the Open tab.  It was pointing at my Documents (and obviously could not find an Acronis log there).  I pointed to an actual Acronis log and it had no trouble reading it.  So I went to the https://forum.acronis.com/forum/115626 thread where the utility is described and see that the 5th tab should say "C:\ProgramData\Acronis\".  Mine says "Label2".  I assume there is either a registry entry or an ini file that has been corrupted, but I haven't been ablt to find it.  Is it appropriate to PM FtrPilot for assistance, or should I just live with this? 

At any rate, I can not read service logs plus some others.  (It dies trying to read Monitor logs, but maybe it has always done that.)

Patrick, take a look in your My Documents folder for a TrueImageLogs folder and if there, delete the file inside which is where the default settings for the Log Viewer are held if I remember correctly.

Steve Smith wrote:

Patrick, take a look in your My Documents folder for a TrueImageLogs folder and if there, delete the file inside which is where the default settings for the Log Viewer are held if I remember correctly.

Thanks Steve.  That didn't work, but it gets me even closer.  The folder was there and contained a file named LogReaderDefaults6.txt.  I deleted it but got the same failure, and the LogReader had put it back with the same contents:

0,0,950,725,False,False,True
C:\Users\Patrick\Documents\TrueImageLogs\
C:\Users\Patrick\Documents\TrueImageLogs\
C:\ProgramData\Acronis\
C:\Users\Patrick\Documents\TrueImageLogs\

I tried changing all of the last 4 lines to C:\ProgramData\Acronis\ , but it did not help.  The LogReader change the data back, but it still still failed.

Now that I know the file exists I'll take a look at the contents on my other 2 computers.  Maybe I'll see an easy fix.

 

Patrick, my copy of the defaults file looks very similar to yours with the exception that I have entries pointing to a temporary folder that I use when downloading user logs from the forum to be read in the Log Viewer.  The first line is just the screen coordinates in the main.

The line for C:\ProgramData\Acronis\ is the main root for all the Acronis logs in each of the different Log Type categories, so would expect that to be always present.

If the issue is showing up as a .NET problem then perhaps try uninstalling .NET and doing a reinstall of this if the clean up tool that Enchantech pointed at couldn't do a repair.

I guess uninstalling and reinstalling .NET is the next step.   It is no longer an optional part of Windows in Windows 10 so doesn't appear in the list of installed programs.  I'll need to dig to find out how to do it.

Or just try downloading and installing the latest .NET installer over what you have?

Steve Smith wrote:

Or just try downloading and installing the latest .NET installer over what you have?

Hmm.  I thought the .NET repair tool did that, but it lookslike it just unregisters and reregisters  the installer.  I'll give that a try.

Patrick,

You may wish to review the link below:

https://www.raymond.cc/blog/uninstall-microsoft-net-framework-with-aaro…

With just the Log Viewer having issues it may be that it is that program itself that has issue and .NET Framework itself is not affected.

Enchantech wrote:

You may wish to review the link below:

https://www.raymond.cc/blog/uninstall-microsoft-net-framework-with-aaro…

With just the Log Viewer having issues it may be that it is that program itself that has issue and .NET Framework itself is not affected.

Thanks for the tip.  I downloaded that and it found no problems.  And I didn't really expect it to now that I know that the log reader works when pointed to the right place.  It's pretty puzzling, though, that Read Log can no longer find the logs when they have not moved.  Something has changed a pointer somewhere.

I would PM FtrPilot the apps author and see if he can help.

Enchantech wrote:

I would PM FtrPilot the apps author and see if he can help.

I may do that, but I've located the (or at least a) problem.  My afcdpsrv.log has been corrupted.  Some of the corruption is obvious - a bunch of blank lines in the middel of it.  But removing them did not eliminate the .NET failure there is more wrong.  I mounted a backup from a week ago, and the Read_Log utility read it with no problem so I may be able to identify and fix the problem ... but I won't count on it.

ATI is running fine with the corrupted log.  Will it still work if I clear out the log?  (I know I would have to do that when ATI is not running.)

The clearing of a log file should not adversely effect the TI application.

I was wrong about afcdpsrv.log being the problem.  It was a very large service log file rather than a corrupted file.  And a few days ago I created another one.  I've PMed FtrPilot but have heard nothing back yet. 

I doubt many people will run into this, but I thought I'd describe the problem.  I occassionally create backups on an FTP server.  And occassionally I create a disk backup of a disk with almost 2TB of data.  The AHTI FTP client adhears to an old limitation of limiting FTP files to 2GB so it divided the backup into nearly 1000 files - 948 files in my last backup.  The result was a very large service log file: 273KB, 1244 event records.  And one of those event records listed the names of all the 948 .tib files created.  I don't know if it was the number of event records or the size of the large event record, but something in that log file caused the Read_LogFile program to choke.

I hope that FTRPilot can help look into this.  He's been out taking care of some personal issues, but we did hear from recently in an MVP meeting.  He is planning on returning soon and updating the logviewer to make it compatible with an upcoming release of Acronis as well. I don't really have any other details though and hope he will be able to return to the MVP scene in the near future.