If the guides do not help, please email the crash dumps and descriptions of what was happening when the crashes occurred to leo@gpsoft.com.au and I will see if the dumps reveal any clues.
Almost all crashes will say that. Things like the stack trace are the more useful details, since they may indicate which DLLs were involved in the crash.
I see, I tried to get to the stack trace but obviously this isn't that easy as opening the dmp files
I didn't have any high CPU usage or realised memory leaks. It also happens out of the blue and I can't remember that I did other things than normal. One time it even happend when I was working in another application (DOpus was in the background).
Currently it happens about once a week on my machine which makes it difficult to test certain things quickly.
Side note: A colleague of mine which is using DOpus as well is encountering more crashes (once a day). Maybe interesting as he is working in the same environment.
All three crash dumps are for memory/heap corruption, probably due to a component loaded into the dopus.exe address space freeing the same address twice or something similar.
One of the crashes happened while right-clicking a file (although the other two did not). With this type of crash, the crash itself may come immediately after, or a few minutes (or even longer) after the involved component made the mistake.
Since shell extensions are the main (but not only) source of 3rd party components being loaded into dopus.exe and are heavily involved with right-clicking, I would start with them. Use ShellExView to disable all the non-Microsoft shell extensions on your system(s) and see if the problem still happens. If it does not, re-enable half of them and see which half the problem component is in, then repeat until it is narrowed down to a particular one. Be sure to fully exit Opus (via File / Exit Directory Opus) after making changes with ShellExView, as shell extensions cannot always be unloaded once loaded into a process. (The guides I linked earlier have more detail on how to do this.)
It might also make sense to initially focus on components that are on both your machines, assuming there is a common cause behind both problems.