I made a button to call DOpusRT /Restart. My expectation was that this would be the same as totally exiting Opus and launching it again.
When I click that button, I see all listers close and reopen, but the Opus process stays the same: same PID, same parent, same start time. I also see the memory usage of that process increase by 200MB.
Are you able to reproduce that? Is it a bug?
After some tests on a fresh install inside a VM, as the leak apparently did no occur there, I am starting to suspect that the memory leak is caused by something else, maybe a shell extension. I will have to try to discover which one later.
Also, the PID stayed the same on these test, so I guess that command does some kind of soft restart of the process.
Correct, it only does a soft restart. The FAQ on restarting Opus provides a script that will do a full restart if you need to automate that.
For the memory leak, the guide on how to find components causing memory leaks may help, if the leak is large enough to stand out against all the other allocations happening when everything is shut down and restarted in the process.
When I try here, memory usage does not change a great deal, maybe 1MB or so, which could just be noise and caching. Nothing like 200MB. (But nothing close to 200MB is being used before the restart either, so my Opus setup + shell extensions are probably very different to yours.)
I had no luck trying to locate a memory leak with VMMap. Every .dll seems to belong to either Windows or Opus.
That was after using the restart command some four times.
Any suggestion for an alternative test?
The system where this problem is occurring has not received Windows Updates for a while (because of a previous botched update that prevents any new update from installing - thanks Microsoft).
I am going to install the next big update as soon as it is available (hopefully it will install successfully, they usually do), then I will evaluate again if this problem still occurs - as it could be a Windows' bug. If it still persist, then I will try to disable other programs and make tests again.
Dang, the Creators update did not solve the issue. Now I guess my only option is to play a wack-a-mole game with the installed shell extensions.
@Leo I tried a bunch of things: disabling shell extensions, plugins, scripts. None solved the issue.
Today I started that system and Explorer and Opus were crashing. After restarting, both were good. I went into the Event Viewer and saw that "windows.storage.dll" was causing the issue for Explorer. There was a dump for Opus, so I used a dump analyzer and the log also blamed that DLL for the Opus crash.
That same DLL appears on the VMMap trace, so I suspect it is the one that is causing the leak.
Is the Opus dump of any interest to you? As the problem seems to be caused by Microsoft's code, I guess I should complain to them.
We can have a quick look if you send it to us, just in case it reveals anything else, but that does sound like a Windows issue, I agree, especially if it's affecting both programs.
