Dopusrt.exe /crashhandler, hang, delay and freeze, context menus not opening etc

Help & Support
1

Hi there! o)

I updated to a recent beta version a few days ago (13.13.4), since then I have problems opening images from Gajim (a chat client using Windows defaults to open images) or Explorer.

It can take a minute or so until the image will open in the DO internal viewer. Sometimes it is as quick as it has always been, multiple times in a row and then it will hang again.

I noticed a dopusrt.exe process in the task manager, with /crashhandler:xxxx parameters, has this something to do with the issue or is this crash handler "dopusrt.exe" normal?

I can kill this process, but it will come back instantly with another PID, as long as the regular "dopusrt.exe /dblclick" process is there. Once the "dblclick" is gone, the "crashhandler" one does not come back (it seems, did not do very scientific testing yet).

Restarting DO or killing any dopusrt.exe process does not help with the huge delay. The "crashhandler" dopusrt.exe will be there right after starting dopus.exe as well.

I had an unwanted reboot recently, some Windows updates and the mentioned update of DO as well. Regular context menus in the file display failed almost completely afterwards again, currently they work, but the overall "hang and freeze situation" is not getting better. I also get these dialogs again, my impression is, that they did not appear for quite some time?!

image
image284×209 3.61 KB

Any kind of feedback appreciated
Thank you in advance! o)

2025_02_26_180944_Task Manager
2025_02_26_180944_Task Manager1150×480 40.2 KB

PS: I also have these nervous columns if long file names exists (I guess) and tabs blanking out on activation and then refreshing content on it's own at times (even for local drive D:). It's like DO is under a spell of some kind for some time or from time to time..

I did not plan to list lots of different things, but maybe there is a relation between the things?
Thanks again!

2

Another perspective onto the nervous columns.. shaky shaky! o)

3

The crash handler process isn't involved. It's always there and exists to generate a crash report if something goes wrong (since the main process may be trashed at that point, it's best to do it from a separate process).

The screenshot shows ParseDisplayName is taking a long time on something below \\fs-game-etc. Is that server on the network and accessible?

4

Is the script error unrelated?

5

Ok, thank you, so we have 3 DO related processes these days (1x dopus.exe + 2x dopusrt.exe if desktop dblclick is enabled), I will remember that! o)

The UNC path in the dialog was probably offline. The screenshot is from my "gallery" of ParseDisplayName dialogs, which came in as a flood in earlier versions (10 within 2 minutes e.g.). The path shown in these dialogs is 99% not related to what I currently do in DO. I already cleared DOs *.xml config files by hand back then and removed lots of old, non existing UNC paths (in favourites, folder formats, labels etc.), for some reason it helped to turn these dialogs down. I still do not understand why a folder format on an offline UNC path would trigger this dialog while I am doing things on local drive D:\ (for instance, that's how I remember these situations at least).

image
image793×480 43 KB

BUT: The ParseDisplayName "dialog-situation" is not my most concern any more, it is the context menu not working on files and folders (sometimes works in top file display and not in bottom, sometimes works in both, sometimes in none of them) AND now it is the image viewer not opening in time.

@lxp
Mhh, I guess not. At least the long delay when opening an image in DOs viewer (from external application) does not seem to print any errors in the script log. I had this same problem many months ago, it cured itself or by updating something, now it's back.

Of course I can't tell if it's something on my machine causing all this, but turning off individual tools was not successful so far and I run the same tools for a decade I guess and I can't remember issues like this with v12. I probably repeat myself and I know it does not help and you probably don't wanna hear either, but.. yeah, this is my subjective impression. o)

I don't have issues in any other application either, all the things I use and always used work fine.

I see similar topics here and there in the forum though, but right now there is no official problem to be solved? No weird Windows update or problematic Explorer extension on your radar? A conspiracy theory at least to make people switch to Win11? Nothing? o)

Thank you! o)

6

If you make some process snapshots while any of the problem(s) are happening, they might reveal why it's happening.

7

In the next beta the "long operation" dialog will include information about the call site in some (hopefully most) cases, which should help us diagnose where the errant network reference is coming from.

2 Likes
8

Very good! o)

Maybe you can increase the width of that dialog as well? It feels too small, it will line-wrap even the shortest paths and the Details button is still not auto-expanded if I remember correctly. I honestly can't tell at the moment, I clicked on "Details" a thousand times already, because who does not want to know and see quickly what path the issue is? Does it make any sense to hide the path?

That "Details" button itself, I also question that. o) It's hiding an interesting path on a single row and uses a dedicated button on another row to do so. Just showing the path would do fine I guess.

Of course this is "just" about UI / UX.. which is not the primary goal here. o)

Thanks and..
have a nice day everyone! o)

9

Do you have any updated information for us relating to this?

10

Nope, not yet, thank you. Context menus in DO work currently, but the opening of an image from an external application in DO is still delayed.

The delay will happen for 4-8 "image opens" by double click from Explorer e.g., the next 12 double clicks will show the image in DO as expected without a delay and then it will hang and delay again for the next images, I don't see any pattern here yet.

All images are on a local disk and no disconnected / offline network shares or UNC paths are present when checking with "net use". I ran net use /delete * at some point as well, since there were some disconnected locations present before, but that did not make a difference.

So, I try to uninstall and toggle other tools and things here and there to see if things start to behave differently, but no results so far.

11

So the idea of us adding more information to the "long operation" dialog was that you would tell us what it said and that might give us a clue as to what's causing it :slight_smile:

12

Yes, it is a good idea! I like it and I surely like the additional information! o)

I opened this topic because of the image viewer "hanging" and mentioned twice, that the long operation dialog problem is not the #1 problem right now, it popped up recently again, after not showing for weeks. Maybe you got me wrong a little, because I put all the mysterious details here happening recently in my DO, but again, the dialog is not getting in the way right now, which is a good thing, since I struggle with the "image open delay" more than enough! o)

Let's be patient and wait a little until my problems start to shift again. The work you did with the additional information in the dialog, it was not for the bin, I am quite sure about it. o)

Thank you! o)

13

There! There it is! o)

This path shown in the dialog is linked to an UNC path (network share), which represents a HDD on a another computer, which spins down from time to time and needs some seconds to get responsive again. This is expected in some way, but..

The actual aspect here is: Why is DO trying things in that path, when I simply open the "This PC" folder? It is the "seemingly unrelated" nature of these dialogs and paths, which made me wonder in the past already. Will we ever find out? o)

image
image284×191 3.57 KB

So, what is in there in path.cpp at line 1536? o)
I am actually surprised you have line information in there!? Is this a manual addition to the code or some automatic debugging symbols / information?

To help the investigation, I recently added some weird / non-existing UNC paths to my configuration (again), maybe this helps to "tickle" the dialog and trigger these situations more often.

btw: Let me try one more time.. o)
Please expand the "Details" by default or introduce an "advanced" setting for this. If I get this dialog randomly, it takes time to recognise it is there, things are freezing, then expanding the "Details" section to see what is in there. Finally taking a screenshot of all this, to save the valuable information. It really would help if I don't need to go and aim for that button "veeeeery quickly".. o)

Thank you! o)

14

The folder tree, toolbars buttons (e.g. favorites), aliases, and anything else that may display or use the path may mean Opus requests information about it, or has to convert the path into the Windows Shell's format (which is what ParseDisplayName does) so it can be compared with another path that's already in the same shell format (and may not have a text version) or passed to a shell API that requires it in that format.

Parts of Windows sadly require any path passed to them to first go through an API which normally completes instantly but can also take 30 seconds, with no way to predict or avoid it in general. That's what the dialog appearing tells you about, with the option to cancel the API call instead of waiting.

15

Appreciate your explanation, but honestly, I don't get it! o)

Where is the exact relation between opening "This PC" and the path in the dialog?

Why would DO iterate over all the DO favourites I have or over all the aliases I may have in use when opening "This PC"? I also don't have the tree open and in the "This PC" view, there is nothing special either. Mhh.. o)

image
image422×269 3.49 KB

Thank you! o)

16

Ok, the right mouse button / context menu problem is back for some days now and it is a real pain.. o) The left / right buttons work flawlessly in every other application, but the DO context menus on items don't work reliably at all now.

I created a process dump, after clicking "right" and waiting for the context menu to appear, but it is a 2.2GB dump file, compressed to 400mb. Is this something you can even look at at this size?

To help and demonstrate what I experience, I recorded two little videos and I used a little tool to visualize the left / right mouse button presses. Left click is BLUE, right click is RED. Unfortunately, the visual presentation of the clicks is not very precise with the help of that tool, that's why I recorded a second video, where mouse buttons work fine (in Taskmanager), so you can see the what visual appearance is normal mouse click behaviour.

It seems in DO, as if the right mouse button click event is not getting "through" or maybe like it's "up" event is not registered correctly, it is strange. I need to click RIGHT, then LEFT to open the context menu. That can't be right, hu? o)

If you or anybody else has an idea, thank you! o)

EDIT: Important addition: The problem is currently only in the LOWER pane of the DUAL horizontal. The UPPER works fine, which makes this even more strange.. arrg! o)

DOpus_right-mouse_context-menu-problem:

2025-04-29_TaskManager_mousebuttons_work_fine (reupload, with visible mouse clicks now):

17

Yes. Send it via the way suggested in the FAQ about process snapshots.

But only if you've removed any references to offline network drives in your aliases, favorites, etc. Else that should be done first to rule them out as being involved.