Changed the flag to FALSE, restarted machine -> crash is no longer reproducable.
Changed the flag back to TRUE, restarted machine -> crash is no longer reproducable.
sigh:)
Never had a problem with any other "open width ..." option, only with PhotoPaint and only if it was already open. Does this help in any way? Any other recommended test if this happen again?
From the info so far, I'd guess that something (probably a shell extension; possibly but not definitely involved with Photo-Paint) is corrupting the stack within the dopus.exe process. That can then cause some later operation, sometimes by code that is completely innocent, to crash.
It could be something else in the same right-click menu, and maybe something which is only shown for the file type you are right-clicking?
Just kind of curious but doesn't usually Opus creates some kind of memory dump file after every crash? Isn't it usually created on the Desktop or something?
The crash dump probably would not help much (other than revealing which shell extensions are loaded) in this case, since it's a stack corruption.
Stack corruptions often mean some code which runs after the guilty code/component is crashing, and that's where the crash dumps take their snapshots, when the guilty party has already left the room.
Sometimes dumps can still be useful here, and we can look if you find some, but don't worry or spend time searching if there don't seem to be any. Some types of crash can also take out the code which writes the crash dumps if they corrupt memory in the process well enough.
Windows protects processes from each other (unless they go out of their way), but there is zero protection of different components from each other within each process. So the shell extension DLLs from all the things adding items to the context menus can write random data all over the process's memory if they go haywire, and nothing can stop them until the process crashes and is ended.
Just wondering why the windows explorer didn't crash when I tried exactly the same action there. Also, after restarting Dopus after the crash again, I could reproduce the same issue over and over. So each time the same memory corruption happened?
After restarting my machine (and changing the flag you've mentioned and then changing it back) I couldn't reproduce the issue any longer. (Until today). Well, that's not too bad:)
If something is corrupting memory, the results can appear quite random.
It's not unusual for different things to happen in different processes (where memory is laid out differently) or across reboots (where components might be loaded in a different order, causing different things to be in different memory locations).
The bug may also only be triggered by something Opus does (or doesn't do) slightly differently to Explorer. e.g. The order it asks for things or how quickly it asks for two things.
I guess you're right. When remembering back, it might be related to what I've done before:
I had a raw texture dump in a binary file and to make the content visible, I just added a .tga header in HexWorkshop. But I made some mistakes, so the tga file was corrupt for some time. But I still tried to view it in this state. While most of the tools (viewer pane, viewer, irfan view) just show an error message or a black background in that case, the wrong data is still processed and if there is a weakness i.e. in the .tga plugin, maybe this could have caused the memory corruption. That would also explain why this happens again after a restart of Dopus, because I'm working in tile mode, so the corrupt .tga files have been parsed again, when changing back to the directory.
It's still just a guess. Haven't had the time for more accurate testing, but sounds plausible to me when I think it over.
If you still have the file we can look at it and see if our own TGA code handles it OK. It could also be a shell extension going wrong, but it'd be good to check our own code either way.
I attached 2 tga files in a zip. Both are corrupt. It's not the exactly the file that caused the problem but I made exactly these kind of mistakes: The image body didn't correspond to the data specified in the header:
1.) ImageDataIs9000x9000x32bit:
ImageData is 9000x9000 pixel, including alpha (32 bit) but the header defines a 9000x2000 pixel pic, without alpha (24 bit) Image data is larger than specified in header in that case.
2.) ImageDataIs32x32x24bit
ImageData is 32x32 pixel, without alpha (24 bit), but in the header there is a size of 8000x8000 specified, including alpha (32 bit) Image data is smaller than specified in header in that case.
I also have to mention that I no longer can reproduce the crash with these files, so you shouldn't invest too much time in this case. But it might be worth doing a quick test to see if the wrong data in the header can cause any serious issues.
