Are you or @michael9dk C# or Windows developers? I’m not, so this needs some developer help.
Ordinarily I’d have said isolate it to reliable steps that anybody can do, and open an Issue with that.
Nobody has time to search the entire code base, so reproducible issues are more likely to be fixed.
Currently volunteers are needed in all areas of this community effort. Lack of those slows progress.
I’ve made a little myself, and am thinking that the WriteCore was from here in the Microsoft source.
which seems to match the stack showing FlushWrite calling WriteCore which then gets the IOError:
STACK_TEXT:
000000e1bc87b770 00007fffa2743a03 mscorlib_ni!System.IO.__Error.WinIOError+0x443
000000e1bc87b7c0 00007fffa357e19e mscorlib_ni!System.IO.FileStream.WriteCore+0xe02aae
000000e1bc87b830 00007fffa277b6d8 mscorlib_ni!System.IO.FileStream.FlushWrite+0x28
meaning the Core is just an internal name, and has nothing to do with what might be a “core” dump.
I also used an old test program (probably based on Microsoft’s example) with no exception catching.
I can get stack trace output to the console (wouldn’t apply to a Duplicati background server I guess):
C:\VirtualBox shared folder\backup\Linux Mint 19.3>.\GetDirectories.exe \\127.0.0.1\missing
Unhandled Exception: System.IO.IOException: The network name cannot be found.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileSystemEnumerableIterator`1.CommonInit()
at System.IO.FileSystemEnumerableIterator`1..ctor(String path, String originalUserPath, String searchPattern, SearchOption searchOption, SearchResultHandler`1 resultHandler, Boolean checkHost)
at System.IO.Directory.GetDirectories(String path)
at RecursiveFileProcessor.ProcessDirectory(String targetDirectory)
at RecursiveFileProcessor.Main(String[] args)
C:\VirtualBox shared folder\backup\Linux Mint 19.3>
I got two Application event log entries, Source .NET Runtime and then Source Application Error.
Are you getting both? Reporting differences might account for the seemingly different issue reporting.
Application: GetDirectories.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.IO.IOException
at System.IO.__Error.WinIOError(Int32, System.String)
at System.IO.FileSystemEnumerableIterator`1[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].CommonInit()
at System.IO.FileSystemEnumerableIterator`1[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]..ctor(System.String, System.String, System.String, System.IO.SearchOption, System.IO.SearchResultHandler`1<System.__Canon>, Boolean)
at System.IO.Directory.GetDirectories(System.String)
at RecursiveFileProcessor.ProcessDirectory(System.String)
at RecursiveFileProcessor.Main(System.String[])
then
Faulting application name: GetDirectories.exe, version: 0.0.0.0, time stamp: 0x600cd8b1
Faulting module name: KERNELBASE.dll, version: 10.0.19041.1706, time stamp: 0x458acb5b
Exception code: 0xe0434352
Fault offset: 0x0000000000034fd9
Faulting process id: 0x7a94
Faulting application start time: 0x01d8705050f37e0b
Faulting application path: C:\VirtualBox shared folder\backup\Linux Mint 19.3\GetDirectories.exe
Faulting module path: C:\Windows\System32\KERNELBASE.dll
Report Id: 38732e4d-5c55-4e65-b276-988620091489
Faulting package full name:
Faulting package-relative application ID:
Do you use a log-file Advanced option? I see Duplicati.Library.Logging.dll on your dump stack.
Trying to search through all of the source code files, I’m not finding that debug mode does a whole lot.
The uses I saw seemed to Output.WriteLine an Exception.ToString instead of the Exception.Message.
Generally though, exceptions act caught, handled, and logged if one sets a log file at the level for that.
If event log is truly a useful supplement (was it in this case, after a look?), that would be good to know.
Default Duplicati logging goes to the overly-summarized-for-good-debugging ordinary backup job logs,
less organized server logs at About → Show log → Stored for major fails (annoying split – open issue).
For manual analysis of an easily repeatable issue, there’s also the server live log. For harder-to-catch problems, setting up a log file is best, but these can get huge over time at detailed levels, e.g. profiling.
I tried looking for an unhandled exception catcher. Found a possible, but maybe just for command line.
Seeming handler is here (do you agree that’s the unhandled exception catcher?), and setup for it here.
I don’t think debug-output gets much use, but we’re always moving the regular log levels up and down.
Warning level (which it seems is default for a log file anyway) “might” catch something during the crash assuming there’s something spotted before it all goes down. Information level is a bit more but not bad.
--log-file-log-level (Enumeration): Log file information level
Log file information level
* values: ExplicitOnly, Profiling, Verbose, Retry, Information, DryRun,
Warning, Error
* default value: Warning
