1.4.5: Crash when updating thumbnail catalog AND viewing a video

[proglamer]

XnView: MP 1.4.5 - 64 bit
OS: Windows 10 Pro 20H2 64bit
RAM: 64GB

After opening a large folder, thumbnail generation is started in a background thread. Clicking any non-trivial video in the browser (to be displayed in the preview window or in view mode) causes a hard crash after several seconds. It seems to be memory related: before opening the video, the working set is ~500 MB; just after opening the video it starts rapidly climbing up to 1-1.3 GB and immediately crashes.

The crash happens with AVI, MKV & MP4 video files (VLC plays the same files w/o problems; no errors in debug log)
It does not matter whether the video being played already has a thumbnail in the catalog or not
The crash never happens when the same video files are played AFTER thumbnail creation for that folder is complete
The crash does not seem to happen when the video files are small (in size or duration)
The crash never happened on the previous used version of the application (v0.98) - thus, not a hardware issue
The settings were changed to create video thumbnails with 4 tiny images inside
debug=2 mode massively spams console with individual thumbnail generation lines and does not seem to write to any file (thus, no log attached)



Effect: Program crashes

To reproduce:
1. Open a large folder (gigabytes) with images and/or videos (the thumbnails for the folder must not yet be in the catalog)
2. Wait for the progress bar to appear in the status bar
3. Click any video (more than several seconds long) before the progress bar disappears
Actual behaviour (bug): the application crashes after several seconds of playback

Expected behaviour: the application plays the video AND continues to create the thumbnails in the background

[proglamer]

Details from the Event viewer:

Faulting application name: xnviewmp.exe, version: 1.4.5.0, time stamp: 0x645b6416
Faulting module name: ntdll.dll, version: 10.0.19041.610, time stamp: 0xe5d7ed5c
Exception code: 0xc0000374
Fault offset: 0x00000000000fed29
Faulting process id: 0x16f54
Faulting application start time: 0x01d9ab8584154cf9
Faulting application path: C:\Program Files\Multimedia\XnViewMP\xnviewmp.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: 6b3e77fe-fb4a-4997-94ed-244c449af820
Faulting package full name:
Faulting package-relative application ID:


Fault bucket 2045919886689193133, type 4
Event Name: APPCRASH
Response: Not available
Cab Id: 0

Problem signature:
P1: xnviewmp.exe
P2: 1.4.5.0
P3: 645b6416
P4: StackHash_8bf8
P5: 10.0.19041.610
P6: e5d7ed5c
P7: c0000374
P8: PCH_19_FROM_ntdll+0x000000000009C8F4
P9:
P10:

[xnview]

clicking on the video once thumbnails finished is ok?

[proglamer]

Yes. Once the thumbnail generation progress bar is no longer visible in the status bar, everything video-related works as expected (i.e. as in v0.98). Re-visiting the 'fully-generated' folder in the future also works w/o problems.

[proglamer]

Just now, I have managed to crash the application by 1) copying a 12MB composite moon image JPG into a folder with videos & images 2) opening the folder so that thumbnail generation can start, 3) clicking the 12MB JPG (resulting in 1.2 GB working set, no crash) and... 4) clicking a random small JPG next to it. The small JPG apparently 'took it over the edge' and caused a crash. So, it is not strictly a video that can cause a crash; opening large images followed by small ones works as well.

The moon image URL: https://i.redd.it/two-years-ago-i-teame ... 52e066f143

[xnview]

Just now, I have managed to crash the application by 1) copying a 12MB composite moon image JPG into a folder with videos & images 2) opening the folder so that thumbnail generation can start, 3) clicking the 12MB JPG (resulting in 1.2 GB working set, no crash) and... 4) clicking a random small JPG next to it. The small JPG apparently 'took it over the edge' and caused a crash. So, it is not strictly a video that can cause a crash; opening large images followed by small ones works as well.

When you click on small jpeg, do you have the preview of moon file?

[proglamer]

Yes, the 12 MB JPG gets its preview almost instantly (upon scrolling to it in the viewport). I tried replicating the JPG crash, and it appears that at least one video must be played *prior* to clicking the moon JPG + small JPG for the crash to occur. Thus, it seems to still be somehow video-related.

[proglamer]

BTW, with versions 1.4.0 & 1.3.1 it is hard to reproduce this regression - it takes a full minute of frantic clicking on video files (as fast as the hand allows) in order to trigger the freeze-and-crash combo.

[xnview]

could you send the crash report with crash dialog?

[proglamer]

There is no exception dialog box at all - the application simply freezes for a second and the main window 'silently' disappears. The crash details from Event Viewer were already posted in this thread (exception code 0xc0000374, indicating heap corruption).

I looked deeper into the situation (with the new 1.5.0 release). A fresh Win10 install in VMware VM does NOT cause the crash, indicating a problem with either configuration or HW acceleration.

I tried:
* Checking system files for corruption via SFC
* Re-installing the NVIDIA driver
* Altering DirectShow filters and their merits to match the VM
* Disabling DXVA HW accel via the CodecTweakTool
* Playing all the MP4 files in the test folder (a hundred episodes of The Daily Show) individually (several dozen seconds each) via WindowsMediaPlayer (no crashes).

Nothing helps. The PC never had those problems with video/game playback typical of the 'my apps are suddenly crashing' posts endemic on support websites. What's interesting, is that Faststone Image Viewer displays the test folder and plays the video files (while the thumbnail generation is in progress) with NO crashes, suggesting different behavior / API usage for the same PC config / HW accel combo.

Is there a way to generate a memory dump?

[xnview]

you can only reproduce this crash when clicking on moon file and a video file? Not another jpeg file?

[proglamer]

I mentioned the moon JPG only to point out that the problem is not totally isolated to the video stack.

The fastest way to crash is still a folder full of vanilla TV MP4s. Previewing several files (for several seconds each) while thumbnails are being generated reliably kills the process. Since VLC, MPC-HC and the standard Windows video player have exactly 0 problems on this machine, it's XnView's peculiarity - especially because, as mentioned before, another image viewer w/ thumbnail generation works properly on the same TV MP4s.

Is there a way to redirect the debug log to a file?

[xnview]

I mentioned the moon JPG only to point out that the problem is not totally isolated to the video stack.

The fastest way to crash is still a folder full of vanilla TV MP4s. Previewing several files (for several seconds each) while thumbnails are being generated reliably kills the process. Since VLC, MPC-HC and the standard Windows video player have exactly 0 problems on this machine, it's XnView's peculiarity - especially because, as mentioned before, another image viewer w/ thumbnail generation works properly on the same TV MP4s.

If you wait thumbnails generation, previewing has same problem??

Is there a way to redirect the debug log to a file?

No, but you have logs when changing debug=2

[proglamer]

After a while I have tried v1.6.4 x64 and the crashes have stopped. Since no HW/SW changes were made to the machine during that time period (not even Windows updates), the issue was apparently solved in code. Thanks!