GP SoftwareTwitter
Opus FAQsManualCommandsObjects

Failing to access ext drive & "open with"

Since the last update for 12.2 I am having continuous problems in accessing external hard disks. When I right click a file on an external drive in order to select an "open with", then it takes minutes before the menu appears (As if DO is looking for the drive or trying to access it, although it shows the directory). When the menu is finally there and I select the exe, then the program stops responding every few minutes, again as if there is an issue in accessing the external drive.
If I do the same in the windows 10 File Explorer, then there is no problem at all. How can I please get this resolved?

All help is greatly appreciated.

Just an idea. What is your setting in -> preferences -> folders -> auto-load? Maybe you can workaround the issue by setting the drives to "normal", in case there is a problem waking them up.

With ShellMenuView (nirsoft.net/utils/shell_menu_view.html) you can disable or enable part of menus. I fixed long time ago similar problem. Just disable half of list then check if problem exists. Then half of rest etc. And finally you'll check where is your problem.

If you turn on Preferences / Miscellaneous / Advanced: context_menu_debug, then run DebugView and right-click the file that's triggering the problem, it may be a quick way to reveal the cause.

(DebugView is a small Microsoft tool; no install required, just unzip and run.)

The debug output will list each part of the menu as it is built, and will also list each shell extension individually. If there is a long delay between two parts or extensions, the one just before the delay is probably involved in what's going wrong. (Sometimes it ends up more complicated than that, but it's a good place to start.)

There's a bit more detail on this approach in the Crash, exit or high CPU when right-clicking certain files guide's Finding the Culprit section. (The guide is about crashes but the technique can help with slowness as well.)

Thank you all for the suggestions. Will try them all. But why the heck did this change with the latest version, and ... the great culprit I think, windows 10 anniversary gift.

Looking through the 12.2 changes to refresh my memory, I can't see any that look likely to have affected this.

Sometimes it's just a coincidence, and another component's change or a Windows update was waiting, pending the reboot done for Opus, so two different things get updated at the same time. Sometimes rebooting again fixes things if the problem was caused by the timing of different components starting up in parallel during the previous boot.

Occasionally just moving our code around in memory slightly, due to small changes to the code, can trigger or cure issues where another component has a bug which is harmless if a particular memory address is not being used but causes problems if it is. (That kind of thing is unlikely to make things slow down rather than not work at all, though.)

Not always, but a lot of the time when a problem seems to come from a particular update, it turns out to still be there if the previous version is reinstalled. I can upload the 12.1 installer if needed, but it's best to check for a slow shell extension first.

It may also be worth looking at what is in the Open With menu. Perhaps something in there is pointing to a program that has its icon or exe file pointing at a network drive that no longer exists? That could slow things down considerably when displaying the menu. The debugging steps can tell you if that is worth investigating. You'll see something like this in the output:


If there's a large amount of time between "Open-With Menu: Building" and "Open-With Menu: Done" then the problem may be in there. But the delay could come from one of the other parts, too. The debug output will hopefully point in a good direction to look.

Hi,

I ran the debugview, and this indeed shows the issue. I don't however have enough knowledge to explain what's happening. Am I correct in saying that there is an issue in communicating with the shell?
Attached the zip.
Looking forward at hearing what the cause may be, and more important, how to correct it.

Thank you very much
REINDEER8_debugview.zip (3.86 KB)

If you disable this one with ShellExView, does the delay decrease?

CLSID: {7AD84985-87B4-4a16-BE58-8B72A5B390F7} (Play To menu) (C:\Windows\System32\playtomenu.dll)

Hi,

The situation is getting worse. I made the change, rebooted, and the DO windows that I keep open, they didn't show up. I tried to launch DO, but, nothing happens. DO is not reacting. I tried the file explorer, and as before, no problem at all. But, what is new is that after changing the setting, also the file explorer needs time to build the menu after right clicking. I restored the setting, rebooted, but same result, and no DO.
There must be an issue with windows 10 I think, but what is going on, and how correct it. I ran the sfc /scannow, but no problems were found. I'm lost.

Try disabling your antivirus software and see if that makes a difference.

Amazing. I use Bitdefender and I added DOpux.exe to the on-access virus scan exceptions, and it now works. I'm going to reboot a couple of times and check for a day to see if the issue is completely resolved.

Amazing? Not really :slight_smile: Most problems we come across are caused by AV programs.

I'm back into the same situation. One change though. When I right click a file, the DO windows shows a "not responding", even with AV completely turned off. And a few minutes later, the menu does show up. It is indeed as if DO is blocked by something. But what?
Is there anyway that I can find out?

If you use Process Monitor to create a log covering when it happens, then save it in PML format (File > Save in procmon) and zip that, I can see if it reveals what's happening. Email the zip to leo@gpsoft.com.au and let me know the file that was right-clicked so I can find the right part of the log.