Explorer.exe Freezing (Win10 2004 Sep update)

Hi everyone,
First of all I've been using Dopus for long time and now feeling like can't survive without it.
So,
I just upgraded my SSD drive with NVME & performed clean install to NVME. Also Dopus gives realy fast response according to before time. I am using latest version of Dopus. Windows installed on NVME but personal folders (Desktop, Images, Videos etc) moved to D drive (SSD)

But my problem with Dopus now & it happens only on desktop, I mean if I click any folder on desktop Dopus opens immediately but if I go back to desktop, explorer hangs up and not responding around 5 Seconds. I have never faced with this before.

I disabled explorer replacement of Dopus to see result and I saw that there is something wrong with Dopus or maybe not. Cause without explorer replacement Desktop works very well. But it happens only on the desktop not anywhere.

Kindly need your help.

Which versions of Opus and Windows are you seeing this with?

Is it a Windows Insider build?

12.21 (x64) version of Dopus. Windows version is 2004.19041.508 & not its not a insider build. Same operating system what I used before.

There is one thing more,
After I disable Explorer replacement, I tried to open any folder on desktop by right clicking (Open With Dopus) gives no problem or freezing

We don't have any similar reports so it's probably something unusual and specific to your system/setup.

If you're running the whole dopus.exe process elevated as admin, that could cause problems like that, since the desktop (not elevated) wouldn't be able to communicate fully with Opus. There's a FAQ which goes into more detail on that if it is what's happening.

Hi!
I have exactly the same problem.

Explorer.exe hangs for 5-15 seconds after clicking any folder on desktop in 'explorer replacement' mode (but only folder, archive opens as usual).
And strange, but if I disable replacement and click "Open in Directory Opus" context menu on a same desktop folders - all seems ok, Dopus starts fine and explorer not hanging.

This behavior started recently (days ago), I think after some kind of Windows update.

Viewing the logs in the Process Monitor and disabling shell extensions in ShExView did not give any leads.

Hi,
I've made pretty deep research and applied every potential way but non of them solved my problem. I am agree with u that I think a Windows update May cause it. After Last Windows update it looks like fixed. We Will see

I had somewhat same issue. not with explorer.exe but with StartisBack++/OpenShell.
Issue was that after opening folders from these application. folder will open fine on Directory opus. but on again accessing app(StartisBack or Openshell). They will freeze(become unresponsive) for around 5 seconds.

I did some checking on what was causing this. and the issue was cause by last windows update. MS has changed/broken something, that is used by opus in replacing explorer.
After uninstalling last windows update, this issue was gone.

I had this issue on Windows 10 Enterprise 2016 LTSB, Version 1607 [14393.3930]

Just now checked the same with opening folder on desktop by double clicking, folder opens fine. but causes whole desktop to freeze for 5-10 seconds.

Just now checked the same with opening folder on desktop by double clicking, folder opens fine. but causes whole desktop to freeze for 5-10 seconds.

This happens here as well!.

Window 10 Pro 2004 OS build 19041.508 Experience Pack: 120.2212.31.0

-Dopus 12.21 Beta 4

I am not too bothered by it as I do not work much on the desktop so I am still enjoying my trial but its there for those that do.

Sounds like it is definitely a recent Windows Update, from what you're saying.

FWIW, I found Windows 10 2004 such an unmitigated disaster (not with Opus but with Chrome and Edge constantly losing accounts and network drive credentials being lost the similarly) I had to roll it back to 1909.

I'm not sure what Microsoft are doing these days, but their updates recently have introduced so many major issues that it's a joke.

1 Like

Leo, even its not related with Opus, hope you can find a solution as soon as possible. Trying to use opus in this way is torture.

It is very likely it is one of these two, but I could be wrong.

I had the same problem with freezing and blue circle running/freezing after closing any DO window.
I deinstalled KB4571756 update, restarted and it was gone. I don't know if it was improtant W10 update, but would be nice if it is fixed somehow in the future.

There are reports of widespread issues with the Windows shell in this month's updates, on top of the disastrous Windows 10 2004 update from June:

We're looking at whether we can do anything on our side, but I'd also say it's probably best to avoid updating Windows 10 at the moment if you can, especially if you're still on 1909 and have the option of staying on it.

3 Likes

We've investigated this and found that it's a general Windows problem introduced in the recent updates to Windows 10 2004, not anything specific to Opus.

It appears to affect any file type action which is launched via DDE from the desktop or a File Explorer window. The window which launches the action will be frozen for a few seconds, and in some cases the desktop window is closed and restarted.

The stack trace when explorer.exe is temporarily frozen:

While there is no Opus code involved there, it would still be possible for this to be our fault if something on our side of the DDE conversation was handled incorrectly. I do not think that is the case, though:

I've reproduced the issue with Opus, but also with TextPad (which doesn't use DDE by default but can be configured to). Opus and TextPad don't share any code, and both work fine via DDE on a Windows 10 1909 system.

From searching the registry on my main machine, I suspect the problem will also happen with several of the Microsoft Office apps (including Excel and Access*), as well as Microsoft Visual Studio, but I don't have those installed on a Windows 10 2004 machine to test that theory. (I can't install 2004 on my main machine as it breaks Chrome and network drive credentials, but I have it installed on a secondary machine.)

(* Edit: We've confirmed the same issue affects double-clicking Microsoft Access files on the desktop. Excel turns out not to be affected, as while it has a ddeexec key in the registry, it's blank. Also, the problem only happens if the target program is already running, not the first time it is launched.)

Using DDE is fairly uncommon these days, but is still done, including by some major applications. If you search your registry for ddeexec keys, you may find other actions which you can test to confirm for yourself that it's a general Windows issue and not an Opus one.

We're still discussing what (if anything) to do on our side. Since this is a bug in Windows that affects other software as well as Opus, we expect Microsoft will eventually notice/care and fix it, but we'll see what happens.


If you're lucky enough to still be on Windows 10 1909, you can delay feature updates and avoid the awful Windows 10 2004 update entirely by going to Windows Update, then Advanced Options, and choosing 365 from the drop-down list near the bottom:

5 Likes

Some additional information:

  • We've confirmed the same issue affects double-clicking Microsoft Access files on the desktop.

  • Excel turns out not to be affected, as while it has a ddeexec key in the registry, it's blank.

  • Also, the problem only happens if the target program is already running, not the first time it is launched.

    (Remember that Opus may stay running in the background, depending on config. But if you use File > Exit Directory Opus, or shut down Microsoft Access, and then double-click something that opens either program, you won't see the delay the first time, but will see it the second time.)

Since this affects Microsoft Access as well as Opus, we think the ball is in Microsoft's court for this one.

1 Like

Thanks for the thorough explanation Leo. Too bad for some of use that wants to run Hyper-V and VMware on the same host, 2004 is mandatory. Hopefully Microsoft sorts this out soon enough.

1 Like

Update on this:

We're doing an experiment to see if we can move away from using DDE in the next beta. If it works then that should solve the issue for Opus (but not Access or any other affected software, of course).

2 Likes

We've implemented a workaround in the new beta:

1 Like