Standalone image viewer crashes

Thanks. Any chance this could be caused by my security software? (a2guard.exe, a2service.exe, a2.start.exe). It wouldn't surprise me.

I just did a very quick test (probably unreliable). I added d8viewer.exe to the 'monitor exclusions' and it didn't crash. I removed it and it crashed fairly quickly afterwards. I will test some more with a permanent exclusion.

Memory/long paths are not an issue. Antivirus also seems irrelevant, d8viewer.exe exclusion still enabled (but I haven't excluded dopus.exe or anything else).

It just crashed on the first image I tried to open (no log). I tried again with that image and it crashed again on the 5-6th attempt. No log. I just sent you this image on the same email.

You'd need to exclude dopus.exe to determine if A/V is involved. dopus.exe is always what displays the files. d8viewer.exe only exists to make it more convenient to send a filename to the Opus viewer from another program.

Same image crashed again (dopus.exe excluded). I haven't yet killed the process, so the current status is: Image Viewer is not responding. Task Manager shows dopus.exe as "Not responding" and high CPU usage (the usual 25% when a process becomes unresponsive).

However, the Lister still works and I can open new ones.

This time, I did open a few other images but in the previous two crashes it was only this one.

If it isn't crashing this time, and is freezing or in a CPU loop instead, you can make some process snapshots and send them to us, which may reveal what's happening:

That needs to be done while the freeze or CPU usage is happening, of course.


I had a look at the image you sent me via email, but don't have any issues opening it, even in a folder with lots of copies of the same image, moving the viewer through all of them.

Do you have any script add-ins installed? (Preferences / Toolbars / Scripts) Those can hook viewer events and might be part of the trigger. (Either something the script itself is doing, or just the fact a script is being by the viewer may be key to reproducing the issue.) Most scripts don't get involved in the viewer but there are a few which do.

My only script is Viewer Taskbar Group 1.0.

Ok, I'll send the files next time it hangs.

Do you still get the crash if you disable that script?

I will have to test and post back. Some times, it just doesn't crash even if I try many times (with the usual setup and the script enabled, that is).

Ok it crashed, but note the script was still enabled. I will now disable it. Files sent.

I did get a crash after disabling the script, although it seemed more difficult to trigger. Have to test more.

I did notice however after having disabled/enabled the script 2-3 times, that it does quickly hang right after enabling the script and opening an image (the type of crash with the Program Error prompt and the auto-log).

The process snapshots all point to the same place, which is promising. Thanks for sending them in!

We're not sure exactly what's going wrong yet, but we're looking through the code for places where the situation might be triggered, and will add some checks which we hope will avoid it, and make a test version available in the next day or so to see if it solves the problem.

Thanks for your time helping track this down so far. It's definitely a strange bug, possibly caused by a combination of files in the folder, which may explain why it hasn't been found before.

A couple of questions:

  • When you open the viewer, are you double-clicking a file within Opus, or something else? (e.g. The Show command from a toolbar/hotkey, or double-clicking the file from outside Opus.)

  • Assuming it's a double-click in Opus, are you in a normal folder containing the files, or is it something more exotic? (e.g. a Library or file collection, or a folder in flat-view mode.)

1 Like
  1. Double-click within Opus. As mentioned, it's actually a single wheel-click acting as double-click. Haven't tried disabling this, but it was never an issue (same mouse/driver). Some times I might open images on the Desktop (not within Opus) but it's usually Opus - also Opus in these tests here.

  2. Normal folders. I can't think of anything usual, folder-wise. Most of the images I open are not on the C: drive (I doubt this qualifies as exotic :slightly_smiling_face:), but other internal HDD's (D: E: F:)

Thanks!

Don't worry about disabling the wheel-click, that shouldn't be a factor (unless maybe the wheel is moving accidentally while the window opens, maybe).

2 Likes

Here's the test version (12.20.1 plus some changes):
(obsolete link removed)

Please try that and let us know if it makes a difference.

If the problem still happens, we can add some additional checks to try and track down the point where things go wrong.

Thanks. Nothing changed, unfortunately. I collected new .dmp files, let me know if you want them.

Thanks for trying that version.


Here's a new test version which outputs diagnostics which we hope will help tack down the problem:

Please also download DebugView from Microsoft and extract it to somewhere:

DebugView doesn't need to be installed, and you can simply delete it when finished.


If you have DebugView running when you open the Opus viewer, you should see a lot of extra information coming from Opus (other programs may print things there as well).

You might need to resize the columns to see things properly, as they're quite narrow by default.

  1. With the new test version installed, and DebugView running in the background, please open the viewer until you get the problem again.

  2. At that point, please save the DebugView output to a file:

  3. You should also find a large dopusdump.dmp file on your desktop.

    (It's only created if the problem has been detected. And it'll only make the file if it doesn't already exist, to avoid filling up your C:\ drive.)

Please zip up the DebugView output file, and the dmp file (if one is created) and send them to us privately (crashdumps@gpsoft.com.au as before).

Many thanks for your time and patience!

Ok. Should I do this when I get the type of crash that produces the "Program Error..." prompt, or the other, prompt-less type? Or it doesn't matter?

I just got the first type (with the prompt) and I have a 284 MB dopusdump on the Desktop.

Ok, I sent it anyway.

Many thanks!

I think I can see what's going wrong now.

Do you have Preferences / Viewer / Behavior / Reuse existing viewer window turned on?

If so, I think sometimes your mouse is double-clicking twice in a row very quickly (which often happens as the microswitches age), causing the viewer to start opening for the file and then, before that has finished, immediately sending a request to the viewer to open the same file again, which it's handling before it's ready.

I can't double-click fast enough to make it happen by hand, but if I set up a batch file to run the Show command twice in parallel, with that Preferences option on as well, then I can reproduce something which looks like the same crash you've been seeing.

I think now we should be able to fix this.

As a workaround for now, please try turning off that Preferences option and see if that solves things for you. That should also confirm that the problem is what I think it is.

1 Like