V12.6 update - delayed launch

Since the last update to v12.6 there is a delay of approximately 30 seconds when launching Opus.

Win 10 Creators, x64, 32G RAM, 1T SSD

Once it launches everything is fine. As long as one lister is open subsequent lister requests are fine.

Any ideas?

Something on your toolbars or one of the open folders is probably pointing to a network share on a computer which is not reachable.

Good guess but not the case. I noticed that problme several years ago so now the default layout only starts with local drives to avoid that issue.

Have you modified your toolbars at all, with anything such as Go command, drive buttons, or an icon stored on a network drive?

Do you have any drives mapped to a server that cannot be reached?

30 seconds is the Windows network request timeout, so it's very likely to involve an unreachable machine if 30 seconds is the length of the delay.

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:

C:\Users\<username>\AppData\Local\Temp\dopus.DMP
C:\Users\<username>\AppData\Local\Temp\dopus (2).DMP
C:\Users\<username>\AppData\Local\Temp\dopus (3).DMP
C:\Users\<username>\AppData\Local\Temp\dopus (4).DMP
C:\Users\<username>\AppData\Local\Temp\dopus (5).DMP

The files will be large, but compress well.

If sending more than one file, using the 7z format instead of zip will give a much reduced size. You can do this via the Archive Files button in Opus.

Please zip or 7z the files and email them to crashdumps@gpsoft.com.au (it's best not to post full dumps publicly to the forum).

Leo,

One compressed dmp is 76MB, too big for email. Alternatives?

Jeff

GMail will accept attachments of that size.

If your email system can't cope with them, you could use a file sharing service like Dropbox, OneDrive, Google Drive, and so on and email us a link.

Please also try the first part of my previous reply, if it is relevant.

Forgot to mention, no cloud services in use.

Uploaded to Google Drive, link sent to crashdumps email.

The dumps all show several threads that a Windows shell component is trying to start, but which are not starting (for a long time):

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.)

Leo,

I did a backup of preferences, uninstalled, reinstalled. Worked fine. Then I did a recovery of preferences and the problem came back.

To fully resolve I uninstalled again, reinstalled, and built the preferences manually. All is good now.

Thanks again,
Jeff

Could it be a script you've installed?

No scripts in use.

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?

ProcessMonitorLogfileCSV.zip (2.4 MB)
ProcessMonitorLogfilePML.zip (8.8 MB)

[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.

Leo,

I removed all filters and looked at that time period.Took some screen shots. It starts out looking normal:

dopus's next events are at 3:09:23.9709476 where it appears to resume normal operation. This is also approximately when the gui appears:

Any ideas? This is all new to me so learning a lot.

Thnx,
Jeff

I'd need to see the full log.

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.

ProcessMonitorLogfile.zip (10.9 MB)
Leo,

I repeated the test with no filters. Process Monitor log file is attached.

Thanks,
Jeff

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.