I did a lot more testing on this now and finally figured out that having the "Unmount partitions after removal" option enabled in the "LUN Defaults of the massstorage.class of the usb stack was causing issues. I tried it with both the Deneb and a RapidRoad USB cards and both were doing the hang when that option was set. Without this, it no longer hangs. As a matter of fact, I actually started to see the issue in 3.9 as well when the option set.
"Removing" mouted drives is not an obvious thing to do - in fact, this is not possible under AmigaDOS. Removable media should *always* be mounted with a mount list, and never over an RDB. As you observe, multiple bad things can happen if you just attempt to kill a running handler. Once FFS is running, it cannot be killed anymore - unfortunately, it does not support ACTION_DIE.
In regards, to 3.1.4 multiview (v45.22) and the warp BMP datatype, I was trying to see if I could do some captures with MuForce and so attaching some of the dumps from the serial port. What doesn't make sense is that this log shows input.device having issue...don't really understand that.
This is probably a side-effect of something else, i.e. the datatype probably stumps on memory that belongs to the input.device and by that kills it. There are two possible options: 1) There is an option to reduce the interface of the picture datatype to that of V40. This has the impact that true-color pictures are only rendered by dithering, but the interface remains then at the V40 level the datatype may expect. There is an ENV: varaiable to change that which is mentioned in the FAQ, but unfortunately I'm currently away so I cannot check right now. 2) Try to run MuGuardianAngel on top of MuForce. This may detect additional problems MuForce alone is not able to pick up.
With the 3.9 Multiview (v45.9) program in 3.1.4 env. I don't see graphic corruption issue -- when i did this comparison with v45.22 and v45.9, everything is exactly the same except for the multiview version.
There isn't really a substantial change between the versions. One thing you can try is to give multiview more stack. There is a stack check included, but maybe the stack is not sufficient for the datatype.
And for the RAM issue that I had, I haven't been able to reproduce exact same issue. However, I have experienced 800 0004 GURU while deleting the files from the RAM disk. I'm attaching a MuForce output for this crash.
This can be almost anything and is probably due to some other bad effect that happened earlier. I would need a long stack traceback to see anyhting there.