Every 2~3 times I run a backup job that has OneDrive (v2 personal) as destination, I get this error: “[Error-Duplicati.Library.Main.Operation.TestHandler-FailedToProcessFile]: Failed to process file duplicati-**********.dblock.zip.aes”
How can I fix this?
This has been around for years so I’m going to look at it fresh and ignore that as the actual reason might not have been found. Also, too much info to sort through.
The FailedToProcessFile error here is in a catch all Exception block and “Failed to process file” is a static pre-created message. It doesn’t appear to actually say what it actually had a problem on. To figure this out, one would have to know what that exact reason was, not the catch all pre-created message you have. It may or may not be logged as well. I can’t tell as it sends the error to the code involved but its definitely not in that entry you provided.
To do that, you’d have to see if any of the logs shows it, or be a programmer and build from source and debug the code, stopping there, and seeing what it shows in your case.
It does seem to be unexpected though as there’s no comments in the catch block. Could be the file has a problem in which case you might want to start a fresh backup.
Could be a number of other reasons. Difficult to say as the actual error can dictate various directions since it may not be the actual actual problem and some of those can be really difficult to figure out.
Oh I see, interesting. How do I view the logs?
Also, I’m indeed a programmer (although I haven’t ever programmed in C#) so maybe I could try to debug. The problem is that the error seems to happen randomly…
Random is no fun. That would make it… well, you could insert a log and when it shows up, it would definitely be in the logs then.
But definitely the easiest, in Duplicati they have further logs in the About section > logs > live. You can set that to verbose. There’s also advanced settings like saving to file. Those files can get really big so you’d need to make sure they’re not captured by the backup and also use eg notepad++ to view since its rare than an application can view large text files easily. Or otherwise poke at the file like can be done on Linux. Just maybe its there.
Debugging c# here isn’t much different than anything else though as you just need it to stop and see what the error is in this case (though if you wanted to debug more than that’s different sure). But, again since its random then just inserting a log there is easier. I usually just find another place in the code that’s logging and copy/paste that and then figure out how to get it to work in that location so I can have a log highly stand out - and it works well not knowing the language.
But, getting Duplicati working from source may be the greater challenge here as its not very straightforward in that it may conflict with the installed Duplicati’s ports, run another, etc lol. I will not walk you through that and I know of no full reference either. If one is out there I don’t know about it. It also might require a new backup and thus the problem might not show up. Just various little issues.
I don’t know if its possible to simply attach a debugger like WinDbg to the application here. If it will work or not. I’m used to that kind of thing more on Linux. If it worked then it could be better than building from source. I’m guessing it probably won’t work here though but just mentioning it. I think it was WinDbg on Windows if that’s what you’re on but its been too long since I last did that there. Might be something provided with Visual Studio otherwise. Yeah, might be this: Attach to running processes with the debugger - Visual Studio (Windows) | Microsoft Docs . And on Linux gdb can allow one to stop at running code in applications pre-built elsewhere and installed like Duplicati here when installing from the exe provided from the website. It just won’t work on everything and this may be one of those times.
You might figure something out I’m sure. Hopefully that helps 
You can probably use everything here in your other issue, which I guess got solved before debugging.
The error looks like TestHandler which is probably after the backup itself while Verifying backend files.
I’m hoping your bad files aren’t from the dates when OneDrive was internally corrupting uploaded files.
Microsoft fixed that in April 2022. Verification samples its backend files somewhat randomly, by design.
Once you get the failing files and their dates, that gives more to go on. You can also manually test files.
I’m hoping your bad files aren’t from the dates when OneDrive was internally corrupting uploaded files.
Microsoft fixed that in April 2022.
That’s not it, since I started backing up to OneDrive this month (June 2022).
Thanks for the instructions @Xavron and @ts678 , I’ll dig through the logs and see if I can find something useful!
I just looked into another issue the same with a catch all block. The following will easily allow you to get the code error:
Go to settings and enable advanced settings for log file and the setting that enables that for verbose. Run the backup. After the backup finishes where it happens then open the file in notepad++ and search for the file or whatever showing in the warning and poke around until you see the actual error.
Mind you the log size will increase fast so keep an eye on that. Its nicer to delete or rename it after every backup so its only logs of one backup.