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 of 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!
No more crashing (as of 8/10/22) but the 3 second delay for color changes still exists (happening on local drive). I'm wondering now if maybe an upgrade from Windows 10 to Windows 11 might help?
I doubt that would improve anything. 
If labels are slow to calculate, they may just be configured to do something which takes too long. Labels can potentially be configured to do things like search file contents, which can be slow for large files (or slow devices). Difficult to say without knowing what the configuration is. But also better discussed in a separate thread, as it's unlikely to be related to the crashes you were seeing before. Please post details of the labels to a new thread and we can see if anything looks likely to be causing the delay.
1 Like
Thanks Leo, will move to its own thread.
Directory Opus is now throwing error dialogues again.
First this one:
And then this one:
The problem gets progressively worse the longer I use Directory Opus (over a 2-3 day period).
Ive now seen this progression twice (once before and then after the fresh install of Directory Opus).
No other APPS on my machine are crashing, only Directory Opus.
Have you had any response from the vendor of Crowdstrike yet?
Have you tried removing it?
Give the analysis above, and what you said about the problem starting right after it was installed, it seems the most likely cause of the problem. We can't really do anything until that has been ruled out.
Reinstalling Opus won't be making a difference, since it would just be copying the same files over themselves. Opus will tell you if its files are corrupted, and registry issues aren't likely to cause a crash, so the installer is likely just a placebo. Crowdstrike looks like the likely cause and what should be investigated first.