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.
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.
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.)
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.
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 ), but other internal HDD's (D: E: F:)
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.
With the new test version installed, and DebugView running in the background, please open the viewer until you get the problem again.
At that point, please save the DebugView output to a file:
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.