That stack suggests that something has corrupted the shared memory heap used by the shell (among other things).
Unfortunately, what usually happens it that something corrupts the heap but doesn't cause a crash, and then a moment later some other innocent code tries to use the heap and crashes because it is corrupt. So the stack trace probably isn't showing the guilty code/component.
If something is corrupting the heap, or corrupting memory in general, it could also explain the other strange behaviours. (All bets are off at that stage, basically.)
The problem is most likely to be caused by a shell extension, and the Crash, exit or high CPU when viewing certain directories guide has suggestions on how to track it down.
I'm assuming that you're happy with fairly technical tools, since you were able to get the stacktrace. If so, you may also want to try using PageHeap. PageHeap will often catch the corruption the moment it happens, causing a crash as soon as the mess is made rather than when something else trips over the mess, and thus generating a stacktrace which points to the likely culprit. Details on enabling PageHeap can be found here: Re: Dopus Rename/Copy Crash.
(If you use PageHeap, remember to turn it off and restart Opus afterwards, since it can significantly slow down the process due to all the extra checks it performs.)