Crashes, possibly due to Crowdstrike Falcon Sensor

I'm having quick crash problems with no dump reports. I did just receive the following error message:

I went in and turned off all of the Plugins in an attempt to track the issue.

Any ideas?

Which version of Opus are you using?

If that dialog is shown a DMP file should be created. Make sure you're looking in the correct place for it. Details are here: Automatic crash logs (for bug reports)

A crash on the dopus_fileinfo thread will usually be triggered by a specific file or type of file which some component (either part of Opus or a DLL another piece of software has installed) is getting confused by. If you can work out which file/type is causing the problem, that can also help narrow down the cause.

In our experience, it's often video files, as the DLLs for getting information from them often have bugs.

Thanks for sending the DMP files!

I can't say anything definitive from the files, but my suspicion is it's due to something hooking Windows APIs incorrectly.

Both crashes are happening quite deep inside a stack of Windows API calls, culminating in an RtlSizeHeap call (which resizes an allocated block of memory):

Crashes in memory-allocation code usually make me suspect something in the process has corrupted memory, which can happen if something frees the same block or memory twice, or just writes random data into a place it shouldn't. That could be something that's in Opus itself or it could be something another component has loaded into our process.

But I'm not sure it is memory corruption in this case. Both crashes are because RtlSizeHeap is trying to access a null pointer (+ 24 byte offset from it):

That pointer, that deep in the stack of Windows API calls, could only have come from Windows itself, and it's happening in two quite different places* in terms of the top-level Opus code that's calling into those APIs (which makes it more unlikely the null pointer is coming from Opus, unless we have the same bug in two places which isn't triggering on any other machines).

(*In the first crash, the file-info thread is asking Windows for some information about a file/document, and Windows is calling a very common API for parsing the name of a file/folder on the way to doing that when it crashes. In the second case, Opus is looking up the Start Menu "startup" folder's location via another API call, completely unrelated to the file-info thread; that Windows API then also does a nested call into the name-parsing API before crashing, but everything above that part is very different.)

I'm guessing Windows itself doesn't have a bug here where it's passing null pointers to itself, especially in two quite different places, or the crash would be much more common. Which makes me suspect something is hooking/modifying the OS in a way which is going wrong.

Looking at the non-Windows/Opus DLLs loaded into the process, we see these ones:

It may be worth a quick try to disable the Autodesk (Ac*), Adobe (CoreSync*) and OneDrive (FileSync*) shell extensions using ShellExView, and then restart. I'd be surprised if it is them, given the nature of the crash, but it's still worth a quick try, and you can re-enable them afterwards if they're all ruled out as possible causes.

But the DLL that makes me more suspicious is the umppc15406.dll one, which appears to be part of CrowdStrike Falcon Sensor, an anti-malware tool that would hook Windows. (The DLL name seems to vary by version, which makes it a little hard to find details for it on the web.) That definitely hooks Windows APIs, so it could be involved in what's going wrong. I also found this article on BroadCom's site:

When both CrowdStrike Falcon Sensor Platform and Symantec Endpoint Protection (SEP) Application and Device Control (ADC) are installed, some applications may fail or crash when launched.

CrowdStrike Falcon Sensor (ScriptControl64_####.dll / umppc####.dll) injection appears to be using a hooking technique that does not conform with the method outlined by Microsoft Windows.

(Emphasis mine.)

That further raises my suspicions that it's causing the problem. But it is also possible that CrowdStrike Falcon Sensor is innocent, as nothing points to it directly; this is all circumstantial so far.

1 Like

In case it helps anyone finding this thread, additional info via email was that the problem started right after Crowdstrike Falcon Sensor was installed.

Combined with the analysis above and other strange crashes the same thing has caused other software, it seems very likely that it is the cause here.

Hi Leo, I super appreciate all the diagnostics work you did on this problem and apologize for not responding sooner. It is my understanding that this issue has been handed off to our vendor (I was told we would receive an answer from them in a few days). I'll add to this thread as soon as I receive any additional information.

1 Like

As of today, any color change [set label] drops Directory Opus off the screen.

If Clowdstrike is making Windows APIs fail in random ways, anything could happen, and if it is doing that then only they can fix it.

The only way to be sure is to test without it on the system, but from what we know so far it looks like the most likely cause, especially when the problems started right after it was installed.

I removed and reinstalled Directory Opus this afternoon. Installed 12.23. It continued to crash. I then updated to 12.28 (which is what I removed), reapplied my customizations and it hasn't crashed. It has also stopped crashing when I hover over either Outlook or Teams. I have also been able to apply colors [set labels] again without a crash. I have noticed that it now takes approx. 3 seconds for a color to apply from the time I select the button until it updates on the screen. Prior to the crashing it was instantaneous. Fingers crossed. Directory Opus is critical to my workflow. Thank you for all of your help Leo!