Does ATI constantly monitor folders that are in a configured file/folder backup?
Does ATI constantly monitor folders that are included in a configured incremental backup between backups? And if it does, is there any way it could be interfering with the file explorer?
The reason I'm asking is that I've suddenly developed a problem with a particular routine I've been carrying out many/most days for about 17 years, on WinXP desktops, then Win7 laptops, and for the last 7 months on a Win10 laptop without any problems before, I can't think of anything else that changed or updated coincident with the problem appearing, and it did start just after (indeed I'm pretty sure the day after) I configured a file/folder ATI 2019 incremental backup (first time I've used ATI) and the initial full backup finished (22 hours including verification).
The routine is as follows. I download some files, mostly .rar archives, into a particular folder (on an external USB HDD) which I have open in a file explorer window. For each .rar archive, I open it in 7zip, where it will show a .zip file inside. I drag and drop the .zip file from the 7zip window into the file explorer window, so the .zip file appears in the same directory as the original .rar. In the file explorer window, when the progress panel shows the operation has completed and closes, the zip file appears in the correct position in the list of contents (view is Details) as sorted by filename, and the display in the file explorer jumps so the extracted .zip is in the display area. I then open the zip file in the file explorer window, drag and drop the contents into a different directory which I already have open in another file explorer window. Then I delete the original .rar file, and move on to the next.
And I have never had any problems doing this for 17 years, most days, other than the odd corrupted or only partially downloaded archive file.
But now, ever since the first full file/folder backup in an ATI incremental backup scheme that includes this folder I download the rar files to and then extract the contained zip files to, I keep on getting a problem. Not on every instance of doing this, but usually on several per session. And when the problem strikes, what happens is: I download the .rar to this directory as normal, I open the .rar in 7zip as normal, I drag and drop the contained zip file to the file explorer as normal, the progress of the extraction/copy shows as normal, but just as it finishes the file explorer crashes. I get an error panel saying the 'remote procedure call failed', all open file explorer windows vanish, and the Taskbar goes blank. After a few seconds the taskbar repopulates (minus two Nvidia icons in the system tray), but of course the file explorer windows are still gone. On reopening file explorer and going back to the directory, I do find that the extracted zip has actually been extracted, though it can be a pain finding it to open it as there are a lot of files in that directory. And it keeps on happening - not every extraction from 7zip to the file explorer window, but ... maybe every other one. And it is REALLY annoying.
So - is ATI doing some file system monitoring in the background covering this folder that might be causing this?
Thanks.
Thanks for answering. Sorry my reply is delayed. I'm disabled, in constant pain, and the medications that keep it down to a bearable level fog my head. I'm only up to making sense of reading things, trying things and writing coherently very intermittently.
I don't have a non-stop backup configured, but I have two backups scheduled, both incremental: one is a whole PC backup for the SSD and HDD in the laptop, one a file and folder backup of the 3 main top level folders on a 4TB USB HDD, Those 3 folders contain over 3 000 000 files in over 300 000 folders, totalling around 2.6 TB (one folder videos, one folder pictures, but the biggest folder CGI resources). I suppose my wondering about ATI's possible involvement in the problem - apart from it appearing just after I started using ATI - is to do with not knowing quite how ATI actually works. For that file and folder backup, the incremental saves have been ... one around 7GB, one 18 GB. Now, I can imagine ATI comes up with what to put in the incremental backup by any out of 3 methods: (1) at backup time checking the entire 3 000 000 files against the files in the backup, or (2) at backup time checking the entire 3 000 000 files against a list it saved with the original full backup, plus lists saved with the other incremental backups, or (3) it actually has a process running all the time, watching those folders and noting all the changes I make to the files on the HDD as I make them, so at backup time it has a list of all the changes it needs to put in the incremental backup. And there appear to be 7 Acronis background processes running and 7 services, and I don't know exactly what they are all doing. If it is monitoring everything in between the actual backups to keep an updated list of changes (rather than the actual changes as in a non-stop backup), then I'm thinking that it might somehow be conflicting with the operation of file explorer in the circumstance of 7Zip passing it the zip file extracted from the rar.
Just to explain the rar/zip thing - these downloads are to do with my hobby of playing with 3D CGI scene creation and rendering. The files in question that I'm downloading are mostly .rar archives of 3D models. Inside the .rar, at the top level, is usually a text file and a few JPEG images showing renders of the model or other resource, and then also a .zip file. The zip file contains the actual model - geometry, rigging, texture files etc, all arranged in the right folder structure to drop into the resource libraries of one of the CGI scene making and rendering programs. So, I download the rar, open it in 7Zip, then drag-and-drop the zip - but not the txt and example render images - out into the file explorer window to extract it. Then I open the zip in the file explorer, and then drag and drop the contents - all the actual 3D model files - out and into the 3D program resource library directory, so they are extracted there. I keep the zip where it is as an archive against any future need, but delete the .rar that I originally downloaded. So, yes, I'm dealing with a .zip file INSIDE a .rar file, although it is not the only thing in the .rar, and I want to keep the .zip but not the .rar.
I had googled for the 'remote procedure call failed' problem before posting here, but almost everything Windows 10 related that came up was a problem people were getting when trying to use the Microsoft Photos App to view pictures (which I don't - I use Irfanview - although i did try just the once to see if that produced this error for me, but it didn't). And the only one of the repeated '5 steps to fix it' that I kept finding that seemed general, not specific to the Photos App, was doing a sfc /scannow, so I had tried that before posting here. First try, it said it found some corrupted files but had fixed them ... but I couldn't figure out from the .log files what the problems had been. Ran it again, and this time it said no problems. But when I next downloaded a .rar, opened it in 7Zip, and dragged the .zip inside out to the file explorer window - boom, the moment the extraction completed, got the remote procedure call failed and the file explorer shut down again. And although it restarts itself, it is a real pain, because I then have to open and find the right directories in 3 new file explorer windows, and then check what the name of the zip I just extracted from the rar was and find it again in a directory with a LOT of .zips (mixed with some .rars and .exes) in it to then extract the CGI files from the .zip to the CGI program resource libraries.
I have now also done a DISM /Online /Cleanup-Image /CheckHealth and a DISM /Online /Cleanup-Image /ScanHealth, and both said everything is fine.
Am now stuck. Although I've been using 7Zip for this job since 2001-ish I had a quick look at alternatives, and decided to try uninstalling 7Zip and installing PeaZip. Actually in features and UI it looks nicer than 7Zip, but I found two different problems. It extracts the .zip from the .rar with drag and drop to the file explorer window (the same one I'd just had trigger the problem with 7Zip) fine. But ... 7Zip, I gather, actually extracts to the system temp folder, then hands off to file explorer to move it into the destination folder - which is why, when it isn't crashing, the file explorer window jumps up or down the list of files to show the .zip I just extracted, all selected and ready for me to open it and extract the contents. PeaZip does the extraction and write of the file to the destination folder itself, so the file explorer view stays as it was and I'm back to having to check the name of the zip and find it in the filer window to extract it. Plus PeaZip takes an age - several MINUTES - to open the display of the directory I download the .rars to and keep the extracted .zips in (granted there are a lot of files in that directory, but file explorer and 7Zip manage to open their displays of the directory contents almost instantly).
I suppose I could try to get used to a new workflow of using a two-pane view in 7Zip (which I've never used in all these years) and doing all the drag and dropping extractions entirely within 7Zip - my one test, that worked with no file explorer crash ... but I'd really rather find and fix the problem.
But cannot think what to do further. The problem MIGHT be nothing to do with ATI - but it did start right after configuring the backup schemes and completing the first file and folder backup of the USB drive, and I cannot think of anything else that changed then. I was wondering about the Acronis Active protection, which is monitoring all the file activity, but it's not saying anything about involving itself with the activities of 7Zip or the file explorer. I suppose the obvious thing to do is turn of the file and folder back up and see if that makes a difference ... and then maybe try uninstalling ATI and checking. But ... with an incremental scheme, can one stop it, then pick it up again? I don't fancy doing the 22 hour initial full backup again just now. I suppose that goes back to how ATI actually handles the incrementals: if it checks all 3 000 000 files against the record of the last backup, then it could just pickup again; if it's noting changes in between then it can't.
Hi David,
Sorry to hear about your health issues. No worries here at all. People pop in and out as they have time (even those of us with MVP badges are just users like you and were not always responsive, but we try to be).
That was a lot to digest so I may miss some of it. However, to keep it fairly short and sweet...
We don't know 100% how Acronis determines the differences in files to backup in Incrementals and Differentials. However, based on some of their forum posts in the past, it is completely disk block changes that trigger new data to backup. Basically, anything that you change between the last incremental and the next incremental is read at the block level and then they are captured by Acronis. The reason incrementals can change drastically is things like adding new files, copying files (and extracting the contents), even things like Windows updates, etc. It all depends on exactly what you've selected to backup. In this case it sounds like looooooooooooottttttttttttttsssssssssssss of image files that are being added.
As for 7-zip, are you on the latest version? For some time now, it has had different options for extracting contents within .zip and .rar files. Are you using the "open archive" option to navigate and then double clicking the .rar and then copying the contents out of it using the Windows Explorer right-click copy / paste option? I often do this for simplicity too.
However, to avoid Windows Explorer getting involved, you could try the "extract files" option instead of "open archive".
Or, if you do use "open archive", instead of right-click and using Windows Explorer copy / paste once you're viewing inside the .RAR, use the copy icon (arrow pointing to the right) within 7-zip. I'm not 100% certain, but it seems to not use Windows Explorer to extract then.
When the problem started I was still on the version of 7ip I installed when I got this computer last June. On starting to look into this I did check and found there had been one 7Zip update since and updated accordingly but it made no difference. With these files I don't select any extract options or use any menus at all - I've always just double-clicked on the .rar download in the list of downloads in Firefox, which causes 7Zip to load and open showing the contents of the .rar, then dragged the .zip from inside the 7Zip window to the file manager window and dropped it. I didn't previously understand, but do now, that in this case 7Zip extracts the file to a temp directory (a 7Zip dialogue opens showing the extraction process) and 7Zip then tells file manager to move the file from the temp directory to the actual destination directory (after the 7Zip dialogue closes a file explorer one opens showing the move of the extracted file from the temp directory to the destination directory). The big advantage from my POV of this method is that because file explorer is actually doing the last phase of moving the extracted file to the destination directory, the file explorer window jumps which bit of the directory it is showing so that the .zip file that has just appeared is visible in the window so I can then easily open it to extract the contents. Methods getting 7Zip itself to de-archive and write the dearchived file to the directory mean that the file explorer display doesn't change, and I have to check the filename back in the 7Zip display of the rar, and scroll around trying to find it now in a directory that has a LOT of (mostly .zip) files in it. It was in the final phase - just as file explorer (not 7zip) had finished moving the dearchived file from the temp file 7Zip had extracted it to to the destination directory that the file explorer crash was happening (and the zip file extracted from the rar WAS there after file explorer restarted and I navigated back to the destination folder where I keep all the zips).
Was ... I've finally managed to fix the problem!
Unfortunately this is one of those cases where the solution does not mean the problem is fully understood. While I'm pretty sure the installation of ATI caused the problem to appear, I'm not at all sure whether it was to do with some kind of specific conflict between ATI and 7Zip, or whether it was just that ATI happened to be the straw that broke the camel's back, and it could have as easily been installing another program instead of ATI.
I'll explain what I can just in case someone else has a similar problem and tries searching this forum.
Originally I was Googling with the error message about remote procedure calls and either or both ATI and 7Zip in the search terms. Not getting anywhere, and seeing that it was actually the file explorer crashing, not ATI or 7Zip, I started doing searches just on Windows 10 file explorer crashes. While the results were about crashes in all sorts of different triggering circumstances, or just generally about it crashing without any consideration of the circumstances, they all gave much the same list of things to try - not on reasoning from the causes but on a 'some users found changing this setting fixed it, other uses found changing that setting fixed it' purely empirical basis. After looking in the Event Manager and finding that the errors logged were all 'faulting application name explorer.exe' and 'faulting module name SHELL32.dll' I contemplated the multiple versions of lists of things to try my searches had thrown up - all much the same, if different in suggested order - and decided to start with the list entry that file explorer crashes are sometimes down to 3rd party shell extensions adding to the file explorer right-click context menu - either conflicts, badly formed extensions or just ... no obvious reason, but it causes a problem anyway. Now, the suggestion was to disable them all, see if that removed the problem, and if it did then re-enable one program's extensions at a time until the problem came back. But initially I used a utility that shows all the 3rd party additions to context menus, and noticed that 7Zip adds a LOT of entries to the file explorer menu (in sub-menus), most of whch I have never used in 16 or 17 years of using 7Zip. So before trying the disable-everything-then-re-enable-one-at-a-time, I started 7Zip, went to the settings, and disabled all of the 7Zip File explorer context menu additions that I never use (which was at least 2/3 of them).
And Lo ... my problem went. Everything back to normal, no more file explorer crashes on my usual procedure dragging and dropping the zip files out of the rars. And it's still fine after multiple computer restarts. So - fixed!
However, although disabling many of the 7Zip shell extensions to the File Explorer solved the problem, it could not have been them alone that caused the problem. After all, those shell extensions were added back last June when i installed 7Zip on this then new laptop, and they've been there ever since. It was only when I installed ATI a couple of weeks ago that the problem started. So it's either some conflict between the shell extension File Explorer context menu additions specifically of 7Zip and ATI, or the ATI additions happened to take things over some limit that triggered the problem which installing other programs that added shell extensions instead of ATI would also have caused.
The inquisitive part of me wants to try putting the now disabled 7Zip shell extensions back and disabling the ATI ones to see if, as I now expect, the problem would still be gone. The part of me in pain and with a medication-muddled head says I shouldn't tempt fate now that things are working properly.