Native Windows file crashing DO?

I'm running DO 11.18 x64 on Win10 Pro x64.

Lately I've been having DO crashes when right clicking shortcut (LNK) files. I used Debugview to find out what was giving DO trouble, and it's C:\Windows\System32\windows.storage.dll:

dopus: CLSID: {00021401-0000-0000-C000-000000000046} (Shortcut) (C:\Windows\System32\windows.storage.dll)

Sure enough, excluding {00021401-0000-0000-C000-000000000046} in DO prevents the crash, but also prevents most of the normal context menu items from appearing for LNK files.

My windows.storage.dll is not corrupt. I checked it on VirusTotal to make sure it was legit, and its hash was found (i.e. someone else had already uploaded the identical file to VirusTotal).

What happens when you right-click the same files in Explorer? Any issues there as well?

No issues in Explorer on the same files.

If there are crash dumps I can take a look to see if they provide any extra details. Please zip and email them to leo@gpsoft.com.au if possible.

It may take a few days to respond at the moment, but I'll have a quick look in case anything jumps out.

Sent. I mention it here in case it you don't receive it for some reason.

Thank you. I do appreciate it.

From the crash dumps, I see you're using EMET in some way, and WinDbg is coming up with this:

Probably caused by : mscorwks.dll ( mscorwks!DontCallDirectlyForceStackOverflow+10 )

Searching on that finds some discussion talking about how some EMET settings may trigger it. Nothing definite, and it could be a symptom rather than a cause, but it is worth trying with EMET disabled to see if it makes a difference.

mscorwks.dll is part of the .Net framework, so this also indicates that a shell extension may have loaded .Net into the Opus process, which often indicates a shell extension has been loaded which is breaking various rules (not using .Net is traditionally one of the rules for shell extrensions, although newer versions of .Net are less problematic than before when loaded into file managers and other processes where lots of 3rd party components have to coexist).

So it's worth a try using ShellExView to disable most shell extensions (you can usually leave the ones which are part of Windows itself, although the File History extension in Windows 10 is worth disabling as it has some serious bugs at the moment). After disabling them, reboot and see if the problem is still there. If it is, re-enable everything again as we then know they aren't involved. But if the problem is gone, only re-enable a few at a time and see when it comes back.

Thank you. I found the culprit. It was AirDroid's global shellex. Specifically:

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\*\shellex\ContextMenuHandlers\{69c98f6d-48e1-4eb7-8424-ea5cb42ec3d7}

The (Default) value under that key is AirShellExtContextMenuHandler.FileContextMenuExt Class.

However, excluding {69c98f6d-48e1-4eb7-8424-ea5cb42ec3d7} in DO does not prevent the crashes (I already had that CLSID excluded in my DO setup before any of this fun commenced).

I simply deleted the aforementioned registry key completely. I don't use that shellex anyway. It stops the DO crashes; no reboot or logoff necessary.

I would have figured this out before posting if the issue with it seeming to come from a native DLL didn't throw me off course. Sorry about that.

I really appreciate the help. At least we discovered another DO compatibility issue.