Crash during exit when scrolling backwards through large images

[rransom2-dev]

JPEGview sometimes crashes after typing [Esc]. It only happens with large files (~30MB).

Double-click an arbitrary image to invoke JPEGview
Scroll forward with the mouse wheel through several images
Scroll backwards with the mouse wheel and hit [Esc] before the next image is displayed.

My guess is this is related to prefetch buffering.

The debugger exception trap below is probably useless, but does show the IP has vectored off into outer space.

The system is Windoze 10 64-bit, with JPEGview (1.3.46.0) writing to the secondary 4K monitor by "DisplayMonitor=-1".

[sylikc]

The size isn't so important as the pixels. What are the maximum image dimensions of those images?

(There's been a few fixes merged in recently with fixes for large pixels files)

[rransom2-dev]

The current images are 5392 x 3592, mixed NEF, 24-bit TIF and JPG. The crash has only occurred with TIFs because the JPGs are much smaller and JPEGView appears to be using the embedded JPGS inside the NEFs.

A previous project was using images with a size of 8256 x 5504. With these larger images, JPEGView sometimes will lock up for several seconds when reversing the direction of scrolling. Once again, the problems are exclusive to TIFs. I just scrolled around in a directory filled with 45MB NEFs and couldn't invoke the delay or the crash. TIFs associated with the larger NEFs are typically 70MB.

I still have a directory filled with 5392 x 3592 TIFs (22 - 30 MB eacg). As a test, I batch converted them to JPGs, without changing pixel count, and wrote them to another directory. Scrolling around in the JPG directory does not delay or crash. The JPGs are between 1 and 3 MB.

Based on my experiences, the crash is related to image size or TIF, not pixel count.

The machine is a Gen 10 Intel I9 with 32GB of RAM and fast SSDs.

[greenozon]

Idea aloud:
how about writing crash dump in case of some incidents inside the app, eg using WinAPI
MiniDumpWriteDump