You mean dopus.queuedfunction, right? There were some typos in your post which I've corrected to help people searching. Please shout if my correction is wrong and it's really meant to be a different thread name.
You've specified Opus 9 in your profile which was just created, but Opus 9 did not have any threads called dopus.queuedfunction (or anything similar that I can find).
What's the exact version of Opus are you using? (You can use the Copy button in the About dialog to put the full version details into the clipboard.)
Please zip up that .dmp file (and any other recent ones, if you can and assuming they are not too large) and email it to jon@gpsoft.com.au -- We'll then see if it points to a likely cause of the crash.
If you can think of anything else that might be relevant, please let us know as well. e.g. Does it only happen when copying between certain drives or certain directories, and is there anything unusual about the drives involved (e.g. NAS devices, cloud storage, that type of thing).
I have sent a couple emails with my minidumps and it seems more now than before that my opus is crashing a little too often.
It's frustrating. Opus is a great program - but i cannot keep it open long enough to work fluidly. I dont know what to do past sending my mini dumps. Im not really getting any responses.
Hi, Unfortunately the dump files did not point to any particular component. It looks like a shell extension is corrupting memory when it runs, but the corruption does not trigger a crash until later on, when something else trips over the mess it has left behind, and something different ends up crashing in each of the dump files.
The best thing to do is run ShellExView and disable all of the non-Microsoft shell extensions, then fully exit Opus & restart it. If the problem does not reoccur, re-enable the shell extensions a few at a time until it comes back, which then tells you the likely problem extension is one of the ones you just re-enabled, and you can narrow it down to a single extension from there.