@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).
Hello
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.
The new log has a lot of filtering pre-applied, so we can't see the information we need.
It's only showing what dopus.exe does to userdata.omd, but we need to see what all processes do to userdata.omd*, or preferably just without any filtering.
We can apply filtering at our end to narrow or widen the view, but if it's applied before saving the PML file then the information is lost completely.
What we can see suggests that something else is locking the file, but we cannot see which process is doing that.
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).
With the window you want active, push Alt+PrintScrn to put a screenshot of it into the clipboard, then go to the post editor here at the forum and use Ctrl-V to paste the screenshot into your post.
However what I find weird is that when trying to see what process is opening the file, (I used Nirsoft OpenFilesView) it shows as it's opened by the System process.
Note: Even though I only use Directory Opus Lite once in a while (once or twice in a couple of months), the file dates could shed some light on the issue too!
"System" holding a file open often means something is accessing it via a network share. Could you check if that is the case? Here's how:
Run compmgmt.msc (e.g. by typing into the Start menu)
In the window that appears, select System Tools / Shared Folders / Open Files in the tree on the left.
Are the userdata.omd or prefs.oxc files in the list that appears on the right?
A second possibility is antivirus leaving the file locked under the System context. There are some reports of Windows Defender doing that.
A third possibility which I've read affects some people is that random System locks on files can apparently happen if the Application Experience service has been disabled in Windows.
I don't fully understand why or what that service does, but it has been confirmed by several people to cause locks like this with other people's data files, if it has been disabled.
If it's disabled for you, try re-enabling it.
Can be checked and enabled by typing services into the Start menu. Then find the service in the list, right click and choose Properties.
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.