Nope, none of that. Opens up in a dual horizontal view with both panes focused on a volume on the local hard drive.
I haven't made any changes in quite a while (years?). The issue started around the time of the v12.6 update. There were some Windows updates around that time too.
Are you using Dropbox or any cloud storage shell extensions like that? Disabling them using ShellExView and rebooting is worth a try, to rule them out.
We might be able to tell where the delay is coming from using a memory dump. Here's how to make one:
While it's happening, please go to Task Manager, then the Details tab, right-click dopus.exe and select Create Dump File.
Do that 4 or 5 times, and it should create something like:
Unfortunately, I can't see anything indicating what is blocking them from starting, but it would probably be something very low-level, or possibly something has suspended the threads and failed to resume them.
I found a thread on a similar problem with an unrelated program where some people found it was tied to antivirus. It's not definite that the same would apply here, but it might be worth a try with your antivirus software disabled to see if it is involved. It looks like Opus is displaying the Help file (for the new version's release notes), which involves a web browser component (to display the HTML page), so it's plausible that antivirus might be kicking in due to that, and then going wrong somehow. But that's just one possibility.
Here also is a list of non-system DLLs which are loaded at the time of the dumps. It would be worth disabling any related shell extensions in ShellExView and rebooting to see if that makes a difference. (The Opus ones can be ignored, of course.)
I fired up MS Process Monitor and filtered for dopus.exe. See attached zip files in PML format (ProcMon native) and CSV format.
Look at events around 3:09:00. You can see it gets slow from then until about 3:09:23. The dopus window appeared around 3:09:23.
Also, if you scroll down in the log it shows dopus looking at vlc.exe and photoshop.exe, as well as other files. At 3:09:24 it gets into some other files on a separate partition.
Any idea why is it accessing so many files that are not relevant?
[quote="FermentorDr, post:13, topic:26352"]
Also, if you scroll down in the log it shows dopus looking at vlc.exe and photoshop.exe, as well as other files. At 3:09:24 it gets into some other files on a separate partition.
Any idea why is it accessing so many files that are not relevant?[/quote]
It's just loading some filetype icons out of them, which is usually very quick. Doesn't look like that is the problem.
The log seems to show a 2.5 second period where Opus isn't doing anything at all with the filesystem or registry.
If we could see what else was going on in other processes during that delay, it might point to the cause. Some things hook Opus and then delegate work to other processes while it has to wait for them, so filtering on dopus.exe may remove some important information.
It's not certain but, based on what's in the log just after the delay, my suspicion is that Opus is waiting on the Windows cryptography functionality to become available, and something on the system is causing that to take a few seconds. If I'm right then a log showing all processes will probably reveal a lot of activity from the cryptography service or a dependency during that gap.
You have it - attached to previous response. The PML file is the native ProcessMonitor file and contains all information. Just modify the filter to display all events.
There are no events in the PML log file from other processes (except the Process Profiling events, for whatever reason; maybe how the filtering was set up when the recording was done).
It's unlikely/impossible that only dopus.exe would be accessing the filesystem and registry for a 2 minute period. So events from other processes must have been filtered out when the PML file was made.
During the 30 second delay, it looks like most of the activity on the machine is to do with network and firewall software, although it may or may not be directly involved.
After the delay is over, Opus is accessing a UNC path \\169.254.x.x\removable_SDCARD\camera which looks like it has been added to a Library.
If that machine/share is not accessible all the time then it may cause delays. The firewall software may also be delaying things by checking the destination/device/files in some way before it allows Opus to talk to it.
(If it's just after boot, the delay could also be from waiting for the network connection to become ready.)
I would try removing that path from the Library it is in to see if that fixes things.