Hello, here's my problem: After "some" operations (varies greatly) DOpus stops working, especially after opening media files like WMVs. The system tray icon remains visible but doesn't show its context menu, or if it does, it's dysfunctional. Essentially, I can't open a new lister in any way. In the task manager there is dopus.exe running, sometimes also dopusrt.exe. There is no dump file in %TEMP% (not surprising I guess, since the EXEs are still running). In the event viewer there is an Application Hang event, dopus.exe, and the binary data under details reads "Cross-thread Deadlock".
I'm running Win 7 64 bit, DOpus 10, but updated today to the current evaluation version of 11 (same behaviour).
If you right-click the process in Task Manager, there should be a Create Dump File option which will take a snapshot of the live process and tell you where it has saved it.
If you can do that with Opus 11 and email it to leo@gpsoft.com.au I will take a look and see if we can tell where it's deadlocking, and whether it's in our code or an external video codec/splitter.
The DMP file will be quite large (~130MB) but should zip down to about 1/3 the size. If you have trouble emailing it, a Dropbox or Google Drive link or similar is fine.
Please try using ShellExView to disable any shell extensions which are part of C:\Program Files\COMODO\COMMON\ShellExtension.dll (and anything else in the same directory) and then reboot and see if the problem is still there.
Does that help at all, or does the problem remain?
That shell extension is suspicious because it appears to be doing significant work as it is being unloaded. Win32 rules forbid almost anything from being called from a DLL while it is being unloaded, because it will cause deadlocks exactly like the one you are seeing, so this is a definite red flag.
(It's also suspicious because "ShellExtension.dll" is probably not a great choice of name for a shell extension DLL. Extensions by various vendors have to coexist within every process that loads them, and two DLLs using the same generic name could cause problems for each other. That won't be causing the problem you are seeing, but adds to the theory that the DLL may be written by someone new to writing shell extensions, who would be more likely to make the other mistake as well.)
When I tried, ShellExtension wasn't in the list, so I could not disable it via ShellExtView. I then simply renamed the file directly, and strangely, the deadlock disappeared. How is that possible when the DLL doesn't even get loaded? Also, the browser is working as always, I didn't notice anything different. A bit surprising, what may that DLL be good for at all?
Anyway, there wasn't a single failure since the renaming, so somehow your advice seems to have worked. Thank you very much for that. It was actually quite instructive and entertaining. I'm only a hobbyist programmer, but I'm certainly going to look into that dump file stuff, this seems to be quite a powerful tool. Thanks again.
That backup program is where the "extra" ShellExtension.dll is coming from. It provides right-click access to the backup program. So, you can right-click files and/or folders to tell Comodo Backup to do whatever backuppy things you want it to do to said files and/or folders.
Presumably, it's getting all tangled up because it's using the non-friendly method of having a DLL with an identical name as a system-provided DLL.
Oh ok, thanks for the tip, I appreciate your help. As it happens, I ran the program today, everything went fine, but I wasn't using the context menu. Looks like it's time to search for an alternative backup solution.
