Right click crashes... That won't go away

I've read the FAQ, and taken the steps outlined there. First, though, let me backup a step.

I did a clean install of Directory Opus 9.0.0.9 on WinXP Pro SP2. I noticed immediately that right clicking (seemingly) any file would make DOpus crash at least 1/4 of the time, on average.

At this point, I've unregistered all third-party shell extensions. In ShellExView, the only non-Microsoft shell extension entries that show are those from DOpus, and the HyperTerminal entry that is actually part of Windows.

After unregistering all of the shell extensions and still having crashes, I ran DebugView as advised, with context_menu_debug enabled. Here is what appeared in DebugView when the crash would occur (I've added my own notes on what each CLSID corresponds to):

[quote]{B22A40F0-BD69-11D3-8D28-006097C82E57} - Beyond Compare
{EECEEFEE-3DF7-11D0-9576-0000837A2FDE} - Path Copy
{A470F8CF-A1E8-4f65-8335-227475AA5C46} - Open With Encryption Menu
{68f32140-2ca3-11d0-acc1-444553540000} - PicaView
{b5eedee0-c06e-11cf-8c56-444553540000} - UltraEdit
{B41DB860-8EE4-11D2-9906-E49FADC173CA} - WinRAR
{a2a9545d-a0c2-42b4-9708-a0b2badd77c8} - Start Menu Pin[/quote]

I have added each one of the foregoing CLSIDs to ignore_context_menus. And I still have the crashes whenever I right click any given file. But now, in DebugView, nothing at all is showing. (I did have context_menu_debug enabled when I checked this.)

I've already corresponded with the author, and he doesn't think it's DOpus at fault. But what could it be? I'm running out of ideas, if I haven't already.

Can't edit posts? Great. I forgot to mention that I am not running any anti-virus or anti-spyware or anti-boogeymen software right now. So that is no explanation, either. (I ran Kaspersky up until a few days ago, and have removed it thoroughly.)

I've also checked the SSDT, checked for injected DLLs, and checked for applications using windows hooks. None of this has helped.

So what do I do now? What could it possibly be if not DOpus?

[Why can't I edit my posts?)

Have you passed to the support exact numbers that display on crash?

Developers are usually able to tell if the crash was in DO address space (so actually DO crashed) or somewhere else (so that something else crashed and DO crashed in effect)

X.

Does the Hide Windows items on file context menus option make the crash go away or does it happen regardless of that setting?

You're not shift-clicking, are you? That will override the option, so if the crashes only occur when shift is held down then that's an important distinction.

I made a dump available. I've sent about four emails back and forth already. He didn't ask for anything specific; he just kept blaming my system based on inherent assuredness that it wasn't DOpus at fault.

Yes, that option makes the crashing stop. But that doesn't help much, since I'm trying to figure out what (specifically) is causing the crashes.

It helps a little bit since it means we know it's something to do with how Opus and another context menu handler interact, rather than something purely to do with Opus.

Have you tried running Process Monitor to see which files or registry entries dopus.exe accesses just before the crash happens? That may provide a clue about which handler is involved.

Temporarily disabling the HyperTerminal extension, if you haven't tried that already, may be worth a quick go in case it turns out to be that. I know it's a Microsoft component but it's one which may not be used by many people which could explain why the problem hasn't been noticed before.

It still could be purely DOpus. Particularly since the last several times it crashed when I was monitoring with DebugView, nothing at all showed up there because they were all excluded. At this point, I have no idea.

I did try that. I tried Regmon first, and then Process Monitor. DOpus wouldn't crash at all, and it was annoying. (Imaging, annoyed that a program wouldn't crash...) Maybe it had something to do with how those utilities slowed everything down, because DOpus was displaying the context menus very sssslowly at that point.

Good thought. I don't use HyperTerminal either, and there must be many systems out there that also have it installed. I'm pretty sure it's installed by default (too lazy to check).

I'm going to try a thorough uninstall/reinstall. I'm not even going to restore settings. I'll post another exciting follow-up then.

I've found the cause of the crash. It occurs when a shortcut with a nonexistent target exists under a subfolder of the SendTo menu. I've reproduced this crash on two systems, and have had unassociated third parties reproduce it as well.

Good work tracking it down!

Did you report your findings to GPSoft? If not I'll file a bug report for you.

GPSoftware have been able to duplicate this.

I had the same problem. Read an article on bad context menus. Found the problem with NVIDIA.

NVIDIA CPL EXTENSION was the culprit.
disabled it and now opus works properly.

windowsxp.mvps.org/slowrightclick.htm
this page describes in detail the procedure to find the offending context handler.

I almost gave up and was looking for a new file explorer.
I am happy again.

Hope this helps.

Thanks, but this problem is unrelated to shell extensions. The cause has been found and is now known to development.

True... though the link he posted is some additional detail similar to what is posted in the FAQ about tracking down possible conlicting shell extensions. All is good stuff to keep in mind when working through problems like yours... but like nudel said, great work plugging away finding the problem!