DO 11.18 x64 on Windows 10 right-click crashes

Hello everyone,

I upgraded my Window 7 system to Windows 10 two days ago and then updated DOpus to v. 11.18. DOpus now crashes reproducibly when right-clicking on any file in any folder, be it local or shared. Right-clicking on folder icons will not cause DOpus to crash. Is there any setting I could change to avoid this?

Cheers,
Armin

Please see the FAQ Crash, exit or high CPU when right-clicking certain files for suggestions on how to track down the problem.

Thank you for the fast reply. DebugView displays the following line immediately after DOpus has crashed, but I don't have the foggiest idea what application this might belong to:

[1332] shell\twinui\nowplayingsessionmanager\localprovider\baseprovider\lib\baseprovider.cpp(516)\NPSMDesktopProvider.dll!00007FFA0119E7E8: (caller: 00007FFA01194A09) ReturnHrPreRelease tid(3f30) 80070490 Element nicht gefunden.

Do you have any idea?

Look at the context menu CLSID that's shown immediately before that line, it will probably be the culprit.

There is no such CLSID column in my DebugView output. The only visible columns are #, Time, Debug and Print. Do you happen to know how this information can be displayed?

Has the debug mode been enabled as per the guide Jon linked above?

Please show us the full output, with everything from when you right-click through to the crash.

Oops. With debug mode enabled, the culprit becomes clear: it is Notepad++64. Actually I had already initiated an update to the latest build, but then I got distracted and forgot to finish the installation dialog. :unamused:

Everything works fine now - thanks for your help!

Was it quite an old version of Notepad++?

There was a bug in it causing crashes which got fixed on their side, but it was some time ago. I'm wondering if it was that same old version or if it's a newer bug, since we still get a few reports of problems.

If the old version is still common in the wild, we could add something to detect it and prevent the crashes for people still on that version. But if it has happened again in a new version then we can't do much (other than block all versions of the DLL, but that wouldn't make sense in this case as most versions are OK).

It was surely an older version, from April 2012 as far as I can remember.