TIF File makes XNView crash

[LauraSeabrook]

For a while now, XnView just crashes when it tries to display My Documents on my PC. I have no idea why and my workaround is to use subdirectories instead. Here's the latest printout for the crash:

Error Report Contents
=====================

Information scroll bar is a tab target
The following information about your process will be reported:
Exception Information
Code: 0xc0000005 Flags: 0x00000000
Record: 0x0000000000000000 Address: 0x00000000006a01a5

System Information
Windows NT 5.1 Build: 2600
CPU Vendor Code: 68747541 - 69746E65 - 444D4163
CPU Version: 00060FB1 CPU Feature Code: 178BFBFF
CPU AMD Feature Code: EBD3FBFF

Module 1
xnview.exe
Image Base: 0x00400000 Image Size: 0x00000000
Checksum: 0x00000000 Time Stamp: 0x4b0f9896
Version Information

[LauraSeabrook]

I did an experiment that narrowed down the cause of the crashes. I removed all the files from the root folder of My Documents (Win XP) to another drive, and XnView didn't crash when I chose the root folder. I reasoned that perhaps it was a particular file causing it to crash, so I then moved the files back one at a time until it crashed. It seems that in particular a certain TIF file is causing it to crash. It also causes XnView to crash if it's in a sub directory, which I guess would be because it is being read to create a thumbnail.

I don't understand how a TIF file makes XnView crash. I will be creating other TIF files to see if this is a general problem, or just that file (which was created using Paint Shop Pro).
. . .
I couldn't reproduce the error for any other file. However, here is a link to an uploaded copy of the file. It's actually a registration form that I extracted from a PDF file for a local Arts Fair. I can't imagine what's in it that would make XnView crash.

[oops66]

Hello,
Right, I have a crash too with this file with XnView v1.97 & XnViewMP Linux
(No problem with GIMP, but a problem too with the "Eye of GNOME 2.26.1" in Ubuntu 9.04 (blank but no crash))

[eL_PuSHeR]

Both Irfanview and Xnview refuse to load it. Both of them complain that it isn't a recognized TIFF file.

Looking inside the file in hexadecimal mode shows what it appears to be a TIFF header. How weird.

EDIT: Windows image viewer and Paint Shop Pro X can load and display it without problems.

[LauraSeabrook]

If I remember correctly, I created the file using Paint Shop Pro X2, from a downloaded PDF file. Very strange, though I found that if I loaded it into PSP X2 again and re-saved it as a new TIF file, there was no error with the new file!

[Ty]

Crash with TIF file confirmed: XnView tries very hard to open/display the file, but eventually crashes. My versions = XnView 1.96.5, Windows XP SP2.

[eL_PuSHeR]

How odd. Now I can open it properly with Irfanview. I think the main culprit is the creation filter from PSP X2.

[Ty]

This is probably not especially helpful info, but here are some more observations about that file. It opens fine with:
--Microsoft Office Document Imaging
--Microsoft Office Picture Manager
--Windows Picture and Fax Viewer
--Windows Paint
--Picasa (opens and is viewable, but is weird and messed up)

[Ty]

I would also like to suggest that this problem (crashing when trying to open a particular file) illustrates another, more subtle problem.

If the "open in" folder/directory contains a file that is going to crash XnView, then that means that XnView crashes every time the user tries to run the program. However, the user will have no idea *WHY* XnView is crashing, unless he suspects that one of the files is corrupted and/or causing the problem and then takes steps to remove or isolate it.

I suggest that the "on execute" behavior of XnView be changed so that successfully running of the program be separated from successful opening of the files. As it is now, the user can't tell the difference between (a) bad files in the "open in" folder, and (b) XnView itself being broken/damaged/dyfunctional. How about a message that says, "XnView has successfully loaded. It will now attempt to open files for display." which is then erased when the thumbnail images are displayed. If the thumbnails are NOT displayed--i.e., XnView crashes--then a message will be left on the screen pointing the user at the source of the problem.

[oops66]

+1, I suggest in this case, a new windows warning too like " One or more corrupted files (image or video files) have stopped the XnView Process" instead a " XnView crash" . ( And with if possible, the list of the suspected files)

[LauraSeabrook]

Or maybe a routine that generates "ERROR" as a thumbnail and moves on, without crashing?

[oops66]

Or maybe a routine that generates "ERROR" as a thumbnail and moves on, without crashing?

Yes, in this case it's a good idea if the related XnView process is the thumbnail creating process
+1

[XnTriq]

Conclusion - there is probably no way to find 'bad' pictures. Perhaps a feature request - to sort - or find incomplete pictures?

Count me in!

• Suggestion: Corrupt image indicator ?
• after thumbnail creation, jumps to beginning
• JPEG Image Verification
• Corrupted photos scanner
• Generating file signatures in Create_File_Listing

[Ty]

Although I'm not a programmer, I have helped design quite a few programs, and feel a little bit qualified to help on this.

The key, I think, is to assume that the loading process is going to FAIL, not that it is going to succeed. It involves a mental shift: "success" is a SPECIAL case, failure is the normal case. So the program should put as much info on the screen as possible as it is attempting to run <whatever> (in this case reading/opening files to display as thumbnails), assuming that the next file will cause XnView to crash. Therefore, if XnView DOES crash, then there's a nice message left on the screen about what it was doing. If it does NOT crash, then XnView erases the message, puts up a new message for the next file, and repeats the process.

This thinking can be applied to many aspects and operations of many programs. It makes the initial (or follow-up) programming slightly more complicated, but gives program users good information about the failure, which they relay to the programmer, who easily fixes the problem--since he knows what the problem is.

A perfectly written program, which as far as I know doesn't exist, would always leave a message about what it was doing when it failed.

Just a thought....

[JohnFredC]

Ty...

Exactly! Extremely well said. I've always called it "pessimistic" programming. If one designs (and implements) the software "pessimistically", then bugs/failures/UI oddities etc. will not crash the program (or, more importantly, the user ).

About that perfectly written program... if it has never crashed for the user and does exactly what the user requested, is it perfect? In an absolute sense perhaps no. In a practical sense, yes!

Rule 1: does what user requested. Rule 1: does not crash under any condition the user will encounter.

(Yes, that is "two" Rule No. 1's)