Logfile.zip (586.8 KB)
Same issue here. Attached procmon log.
Logfile.zip (586.8 KB)
Same issue here. Attached procmon log.
@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).
Step-by-step instructions on how to make the logs are here if needed: Process Monitor instructions
Ah, I wasn't aware. In PML, this time: Logfile.zip (458.8 KB). BTW, I run into this issue on all my PCs.
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:
C:\Users\<username>\AppData\Roaming\GPSoftware\Directory Opus (or type
/dopusdata into the location field in Opus).
userdata.omd and choose Properties.
Select the Security tab and click Advanced
Paste a screenshot of what you see there.
I'm also having the same issue.
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!
Many thanks for the screenshots and details!
"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:
compmgmt.msc(e.g. by typing into the Start menu)
prefs.oxcfiles 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've tried your solutions
So I did dig deeper into it. I found a weird condition that triggers it, as well as a workaround.
This is what I did:
userdata.omdfile and it's data like a normal file.
userdata.omdand saved. (using a text editor)
userdata.omdis now owed by the SYSTEM process and can't be deleted/renamed. Editing still works.
I've attached a video showing steps 5-13
This was the content of my
<?xml version="1.0" ?> <opus_meta_data lastfeed_high="30618548" lastfeed_low="-5973504" last_version_low="0" last_version_high="786439" config_type="private" forcelite="yes" lite="yes" jump_list="1536" />
Comparing to the newly generated one, the only differences are the
lastfeed_low & the lack of the
Overall I think it's weird condition that changing data in a file triggers the condition that it becomes owned by the SYSTEM process.
The workaround is to delete
userdata.omd and let Opus create a new one
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.
thanks to @src for the workaround.
I began a thread with this problem, here, but Leo directed me to post in this thread. Here is the security setting on my userdata.omd:
And here is my most recent (today) process log: Logfile2.zip (10.6 MB)
And here is the Advanced Security settings on the Directory Opus folder in Roaming:
I don't mind if this is something for which we must await an update for the program, but it would be nice to know that it was being worked on.
Or perhaps we still need to find what is locking the prefs and files. I have no antivirus running.
PS I was able to open and save userdata.omd with an extra line at the end.
Are you able to rename userdata.omd or prefs.oxc, or is renaming them blocked?
Please check if any processes are holding locks on either file. This earlier post has info on how to check:
Not even the default Windows Defender?
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.
Hmmmm. I also run Enpass as UWP. Turning that off resolved the issue. Even stranger, after restarting the app, the error didn't return.
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.
Please try the fix in this beta version, and let us know if it works for you:
n.b. For the fix to work, you must reboot if requested to at the end of the install.
Does anyone have any feedback about the beta version?