@cjpostma Many thanks, but would it be possible to save the log in PML format? The XML log format is write-only and can't be loaded back into Process Monitor (+ also strips out a lot of the useful data).
I captured some logs with Process Monitor. Doing so, I shut down Dopus after starting windows, Started logging in process monitor. Doing so the problem didn't appear. Did the same thing again and now the error is gone. i don't know what happende. When I started the computer befor trying to log, the error was there.
For anyone seeing this issue, please follow these steps, using userdata.omd as the filename (where the example screenshots use prefs.oxc) and report your results:
From the logs we have seen so far, it looks like something is locking the config files open and preventing them being replaced, but it's happening before Opus even starts running, and before the logging begins.
A second thing that would be useful:
Go to C:\Users\<username>\AppData\Roaming\GPSoftware\Directory Opus (or type /dopusdata into the location field in Opus).
I was able to modify the userdata.omd and between restarts the contents were retained, but I was unable to delete the file even with dopus and dopus helper being terminated.
so I had to go to recovery command prompt and delete the file and continued windows 10 normal boot.
after login, WIN key+E did not open dopus, instead explorer was launched, then I had to manually open dopus application, which opened initial configuration wizard. after saving the settings I was able to get rid of the userdata.omd warning message.
Do any of you have F.Lux, ShareX, or any other Microsoft Store apps installed?
We just remembered this thread from last year where people seemed to find one of those apps was causing the problem. We still do not understand why, at all, as it makes no sense other than an OS-level bug (which is entirely possible, given the literal lack of QA on Windows these days).
I also just found this:
FWIW, I emailed the F.Lux developers a while ago to ask if they had any idea what was going on but we didn't get anywhere. I doubt they are doing this on purpose either, and the whole thing is very strange. They may be triggering a strange Windows bug.
I use f.lux (UWP) but turning it off doesn't solve the issue. I also run an AMD GPU, so the issue looks very similar. Also following src's tips I did find that "system" is holding the file hostage. Will investigate further.
A fix for this issue has been written and will be released shortly.
We finally managed to reproduce the problem today, which let us start analyzing exactly what was going on.
We can conclude that while installing f.lux and some other Windows Store apps can trigger the problem (in conjunction with Opus), they aren't to blame. The issue is a (rather serious and ridiculous) bug in the Windows 10 operating system which causes the System process to lock files if UWP applications open them in certain contexts.
We've found a way to work around the bug, and will release an update shortly.
(This will only fix the problem affecting Opus's config files. The underlying bug in Windows 10, which apparently causes other issues such as UWP f.lux causes SYSTEM to keep handles to process' exe files in AppData open, is something only Microsoft can truly fix. I'll drop the f.lux developers an email with our findings in case it helps other people, since theirs is one of the more popular Store apps and thus likely to appear to be the cause, even though it is really just an innocent bystander and the OS is the cause.)
Many thanks to everyone who helped track this down.