GP SoftwareTwitter
Opus FAQsManualCommandsObjects

Bitlocker error

I have some USB drives that are encrypted. If I right click on those drives before I unlock them Dopus crashes.

Can someone else see if they get the same result?

Is a crash dump generated?

Have you tried the debugging mode to see if it's caused by a particular shell extension?

What happens in Explorer?

hey @Leo,
A crash dump is generated in the %temp%/DOpus.Minidumps folder.
But keen to see if I can track it down. But will send if we hit a wall. Can I see what's in the dmp file?

I had a read over this post Crash, exit or high CPU when right-clicking certain files. Aside good post btw.

I enabled context_menu_debug and opened DebugView. However DebugView does not appear to capture the events when right clicking on drives. I do see the events when right clicking other folders.

Turning on Hide Windows items on file context menus did not impact the error.

I notice the error only occurs in the folder tree and not the Lister. It does not occur in explorer for ether folder tree or 'lister'.
In explorer I see the folder tree menu has three items that the 'explorer lister' does not.

  • A disabled Expand menu at the top
  • An Auto play
  • A new menu at the bottom, this menu has a shielded Folder

Comparing the Lister menu in Dopus to the folder tree menu for non locked drives.

  • Like Explorer the Folder tree has a new menu the lister menu does not.
  • Also the Folder tree does not have the Expand menu (like explore does).

Could it be the New menu option, as the drive is not ready?

Are you able to BitLocker a USB drive and see if you get the same error?

Please zip & email the crash dump to us.

Without the debug symbols you can't see much, but you could try this (or do it yourself offline).

I tested the same drive on some other PC's and did not have the same error. So likely something to do with this PC's set-up.

Dump has been emailed.

I think I have identified the application causing the crash, it was duplicatedetective. Interesting it only happens on a locked drive in the folder tree, and not in explorer.
Let me know if you find anything specific from the dump. I will contact them see if they are interested in investigating the issue.

Developers of Duplicate File Detective here.

We use DOPUS ourselves, and haven't noticed anything along these lines. We'll follow up with you via email and see what we can figure out.

1 Like

In case it helps, here's the callstack from the crash which wowbagger sent us earlier:

It looks like appresolver.dll's GetCommandString implementation is crashing for some reason. (Or the stack is corrupt, which is always a possibility, and could even be caused by a third component that's not in the picture.)

If we can help at all on our side, or if you find we are doing something differently to Explorer that could be triggering the crash, let us know. Removing differences between how Opus and Explorer call shell extensions is usually a good idea for us, even if it's not technically a bug on our side, since other extensions may do the same.

Thanks @Leo

I have been able to reproduce this on another PC. It is running Windows 10, Dopus 12.6.1, Duplicate file detective Much less is installed on this pc than my normal PC.
I was not able to reproduce it on similar setup with windows 8.1.

Thanks for the additional info guys. We'll be running repro tests on this within the next day or two and will update this thread with our findings.

I was finally able to make some progress on this strange, obscure problem.

I still don't fully understand the root cause of the issue, but I found that a simple re-structuring of the parent menu insertion code (in the Duplicate File Detective shell extension) resolves the problem. Literally I switched from using ::InsertMenu to populating a MENUITEMINFO struct and inserting it via ::InsertMenuItem.

Only when using Directory Opus does this distinction seem to matter, and only when a locked BitLocker drive is involved. When the crash does occur, the call stack is always consistent with the one @Leo shared above.

In any event, this change will be rolled into the next minor release of Duplicate File Detective. I'm pretty sure @wowbagger is the only person on the planet who has come across this problem but hey - progress is progress right? :wink:


Hey @Markr, thanks for the update, and for looking in to it.
Will look for to the update.

I'm someone else sees the error, they just don't know what causes it. :slight_smile:

Hi @wowbagger,

Here's a build of Duplicate File Detective that includes this fix:

Please let me know how it works for you, and thanks again for your help and patience.