As with the first version, the crash wasn't from the ThumbView code I've written but from the 3rd party image loading library failing to load an image. I don't have much power over that, and even if I did it would be too late since it's already crashed a users computer - that's not nice now is it?
Naturally, I have to run the image loading in some safe way. An own thread? An own DLL? Something! The answer came with structured exception handling (SEH). The __try and __except blocks lets me catch and handle both software and hardware exceptions. So dereferenced null-pointers and the like get catched! Right now I just log the error with OutputDebugString and read that with DebugView.
Completely superior! Holy banana! The faulty image is ref.xwd but I just didn't print that, since it would be too useful. ^^
So now I can detect that an image broke the image library. That's hawt if you're the image library writer. To fix that you'll need the actual image. For ThumbView though. What should happen?
* Display a default "broken image" icon?
* Tell the user with a MessageBox that a broken thumbnail was encountered and I'd like him to report the error?
* Just report the error anyway?
* Log the error?
* Allow error report on right-click?
* Erase all .sys files on the hard drive?
Because what I want from the user is: the ThumbView version, OS version, full image file path (to find Unicode problems), and of course the image. I'd like a system that asked the user if I could have the data, collected it, compressed it to a zip, and send it over! But I'll have to log the image so I don't report it more than once; since the user will get annoyed by the system asking to send a report every time he reloads a folder with a broken image...