Must be a month or two that DOpus crashes when I try to open an image. It does not happen often. I can usually reproduce it if I try opening many images (not all at once) but I can't pinpoint the cause. Automatic crash logs are not created. My usual workflow: (long before these crashes started to occur)
D8Viewer set as default image viewer. Using Details mode and click on images with the mouse-wheel, which is set by the Logitech driver/program to act as double-click. Using this Windows 10 Dark Theme. By the way, I'm not sure if it's supposed to appear in Settings/Lister Themes. It is installed and working, but no Themes are listed there.
For example, I was opening images in a Thumbnails-mode Lister. No problems. I switched to Details mode and it crashed on the first image. Can't say if it's related.
On the face of it, the dump makes it appear that the crash happened while pre-loading the next image, where there was an out of memory error. But it's strange, since it seems to be running out of memory when creating a copy of the file path, and it looks like the file path is over 4096 characters long, which seems unlikely. (I can't see how much it's actually trying to allocate.)
Unless you're low on memory or dealing with really unusually long paths, it's more likely the dump is misleading and the real issue is something is corrupting memory. That could be due to a particular image or images that you're double-clicking, or which are just before or after the one you've double-clicked (due to pre-loading) triggering a bug somewhere.
If you can get it to happen on a folder with just, say, three images from the set that seem to trigger the problem, you could zip those and send them to us and we can see if we can reproduce the problem. (It can be more than three if you want, and don't mind uploading a larger file, of course.)
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:)
), but other internal HDD's (D: E: F:)