The guide Ghadzoeux pointed to is the official answer. That's what to do.
(Oops, I got the two names mixed up before.)
Thank you Leo.
I do not understand that guide and request support.
to put it more specifically, I do not get any what you call " CLSID strings".
I get Number, Time, Debug Print.
The debug output (that will appear in DebugView, in the Debug Print column) should look like in the guide's example, with things like this:
CLSID: {8DD448E6-C188-4aed-AF92-44956194EB1F}
(WMP Burn Audio CD Launcher)
CLSID: {7850a720-705f-11d0-a9eb-0080488625e5}
(BestCrypt Shell Extension)
CLSID: {8D9D4D0D-FDDD-44CB-AAB2-6161FA0757C5}
(IZArc Shell Context Menu)
The things in {...} on the lines starting with "CLSID:" are CLSIDs.
Each CLSID identifies a particular shell extension, like an ID number.
From http://www.fileresearchcenter.com/showglossaryterm.html?term=CLSID:
[quote]A Class ID (CLSID) is a 128 bit (large) number that represents a unique id for a software application or application component. Typically they are displayed like this "{AE7AB96B-FF5E-4dce-801E-14DF2C4CD681}".
You can think of a CLSID as a "social security number" for a piece of software, or a software component.[/quote]
This is the kind of output that I get. And a search for "CLSID" returns no result
[1340] =====================
[1340]
[1340] =====================
[1340] Property::GetValue(key) Exception, Key= 68|0|32
[1340]
[1340] =====================
[1340]
[1340] =====================
[1340] Property::GetValue(key) Exception, Key= 68|0|32
[1340]
[1340] =====================
[1340]
[1340] =====================
[1340] Property::GetValue(key) Exception, Key= _TRASH_COMMAND
[5716] OnEnter 1/3
[1340]
[1340] =====================
[5716]
[5716] =====================
[5716] Property::GetValue(key) Exception, Key= KEYEVENT_BLOCKING
[5716]
[5716] =====================
[5716] OnEnter 0/41670736
That's all coming from another program or component. Other programs can send things to DebugView at the same time as Opus. (It's bad form for them to do so, when not switched into a diagnostic mode, but nothing stops sloppy apps/components from doing it.)
Have you enabled context_menu_debug in Opus?
With that enabled, and DebugView running, have you right-clicked a file?
If you do that, you should see output like in the example.
I did not realise the I have re-enable that each time the application crashed.
Now I went three time through the cycle: crash, enable debug, restart, test, crash...
This is ridiculous. Please ad vise how I can go back to V10.
You don't have to reenable it each time, but you may need to wait 10 seconds after OK for the Preferences to be saved. So if you're triggering the crash right after making the change, it might not have been saved yet, but if you wait 10 seconds before right-clicking anything, it'll be fine.
You can also force them to be saved using File > Exit Directory Opus.
Either way, you'll probably only need to generate the debug output once.
I also had this issue with Dopus 11. In Dopus 10 it worked ok, but in Dopus 11 it crashed on right click on any file.
I've checked Windows Event Log, and there I found it was due to Notepad++ shell extension.
I've updated Notepad++ and the problem was gone.
But since it worked properly on Dopus 10, I'm guessing there maybe an issue with Dopus 11. Not sure how shell extension works but I'm guessing that Dopus shouldn't crash due to some shell extension error.
Maybe your issue is with some arhiver application, try to update the one you're using.
No, shell extensions add code to the Opus process, and if that code crashes, the whole process crashes, even if we've done absolutely nothing wrong.
That's why they can take out Explorer as well.
No, shell extensions add code to the Opus process, and if that code crashes, the whole process crashes, even if we've done absolutely nothing wrong.
That's why they can take out Explorer as well.[/quote]
I see. Thanks Leo.
Then it is strange how it worked with Dopus 10 for months, but when I switched to Dopus 11 it started to crash.
It's not that strange if the crash was due to random memory corruption or something similar. Things move around in memory and something that was harmless becomes serious.
As an example -- and I'm not picking on Notepad++, which is a good app; I just found this while looking to see if any recent changes mentioned the shell extension -- the Computer Management tool in Windows 8 was crashing until a Notepad++ update to fix something in its shell extension: notepad-plus-plus.org/news/notep ... lease.html
Anyway, talking about this here is making it harder for zumaxb to find the information he needs earlier in the thread, so let's leave it.
If you have notepad ++ and Dopus 11 crashes when right clicking, upgrade notepad! The latest version fixed my issues.
I'm running Windows 8.1 64bit. Dopus 11, with notepad ++ v6.5.5 with no problems now. 
Same problem since Dopus 11, all other things equal.
Dopus closes silently on right-click on any file type, but not on folders.
[quote="benpal"]Same problem since Dopus 11, all other things equal.
Dopus closes silently on right-click on any file type, but not on folders.[/quote]
Same problem -> Same answer -> Use this guide, from the FAQs and linked in 3rd post in this thread, to find the shell extension causing the crash:
[ul][li]Crash, exit or high CPU when right-clicking certain files[/li][/ul]
(Assuming you are not using Notepad++; if you're using that, try updating it first, since that fixed the problem a couple of people were seeing and may save you time.)
Notepad++ upgrade helped here!! 
I tried to follow the manual route, switching off single extensions - still crashed on right click
Then I did the first suggestion, switching it completly off - still crashes on right click.
I prefer not to beta test.
Please advise how on how to back to previous version.
Ok, Notepadd++ update seems to have solved it.
Although I do not know why switching it off did not help. Possibly because it is not easy to switch off individual extensions the way the tutorial explains it.
It's not that every other advice says to update the Notepad++, I know, it was hard to find it 
right by the time i was here - not!
thank you for your helpful remark.