Hello. Using: XnViewMP Version 0.83 x64 (Oct 3 2016) Libformat version 6.92
Although this looks as one bug, it's actually two, the crash shouldn't happen but an error should be shown, besides the bad detection.
It took me a bit to get why and how XMP kept crashing in a certain folder, it all started when I opened a file and suddenly the Windows alert of 'XnViewMP stopped working' popped out. After much testing and misunderstanding, I finally found the culprit. XMP detects wrongly the first file of a split 7z compressed file (.7z.001, .7z.002, .7z.003, etc.) and tries to load it as an image. This only happens with the first file, the one with 001 extension, and detects it as 'Hayes JTFax', always as black & white, compression CCITT Group 3 and width 2544 pixels; the height depends on the size of the actual file. The crash happens if the file is too large. The one causing my crashes was 2 GiB large, so I guess something went wrong when trying to get the memory or calculate the height, shouldn't have crashed but launched an error.
I'm using 7Zip 15.12 64bit (http://www.7-zip.org/
) for making the files, although the specific structure of the 7z files hasn't changed in many versions. Normal, non-split 7z files work ok, only split 7z files give the problem, and only the first file. What I found curious is that if you create a split file and the size of splitting is larger than the actual size of the file, the only file created is also wrongly detected as Hayes JTFax. There's a simple explanation for this, but it's part of 7Zip's technical approach of making split files, and is of no use for the current bug report.
So, to reproduce the format detection bug, create a split 7z file using any split size, and open the folder. You'll see the first file treated as an image.
And to reproduce the crash bug, make a large split 7z file using a large split size, mine was 2 GiB but much smaller files also make XMP crash, such as 37M.