The lead developer describes that as
That is unfortunately a “follow error” that happens when something else breaks.
so possibly you can find an early error in the log. In any case, I’m not surprised it’s stuck after whatever.
Retracing a bit, the line above it shows it maybe trying to process its own database (the name could be verified on the job’s Database tab). This can cause problems, but I see earlier you were trying to filter it.
How was that entered or verified? In addition to a possible GUI entry bug I just found, the final filter needs either a wildcard or regular expression to allow for it not being a full path. Folder also needs trailing slash. Documentation for filters seems to focus on the lower-level view, and GUI-level documentation says little about exactly how to add filters. Maybe the exact operation wasn’t clear, and it’s certainly not clear to me.
Ways to see what filters your GUI entry actually made (it seemingly tries to simplify by editing your entry) include using the three-dot menu on the Source Data screen under Filters. Another is job Commandline, then either look for –exclude values, or check Edit as text and go looking for the raw filter expression.
Another possible filter worry is variables like %APPDATA% and %MY_DOCUMENTS% that vary by user.
How was that determined? If this refers to what Task Manager → Run as Administrator calls SYSTEM then
C:\>whoami
nt authority\system
C:\>echo %APPDATA%
C:\WINDOWS\system32\config\systemprofile\AppData\Roaming
C:\>echo %MY DOCUMENTS%
%MY DOCUMENTS%
C:\>
however the System.UnauthorizedAccessException hit earlier with --snapshot-policy=Required hints that whatever the account is, it doesn’t have privilege to snapshot, thus almost certainly is not SYSTEM.
Figuring out the account problem may be the best path now, having tried the other some, and hit issues.