Checking if and who is using DirectInput is not something we can do across process boundaries. Probably by design and by chance.
The whole idea behind the COM and IUnknown interface that DirectInput also uses is that you grab a handle to the interface before using it. This increments an internal reference count. When ->Release() is called, the reference count is decremented and when it goes down to 0 it is destroyed. Nothing new here. If multiple people make use of it, then they don't have to know if or who is using it simultaneously. As long as everybody ->Acquire()s and ->Release()s the interface properly everything should work out. This is under the assumption that they willingly share the same object with each other somehow. The stack trace in your screenshot looks kind of like a double delete/free. This can only happen if someone isn't playing by the rules.
Because of how the overlay works (that thing that is rendered on top of your game that you can control with keyboard and mouse, obvious culprit judging from the stack trace), I am fairly certain that it tries to hook DirectInput. It basically "pretends" to us like it is the real DirectInput even though it isn't. In order to intercept and when applicable block input events from reaching our code, they need to do some funky stuff in theirs. This is the reason why they couldn't simply just create their own DirectInput object and had to hijack ours. The facts are kind of clear. We create an object (which implies ->AddRef()). And at some point we destroy the object with ->Release(). From our perspective, nothing else can happen in between. A double delete/free can only happen if they also play around with the the reference count for an object that we own.
There is nothing we can do. If they want/have to hook a DLL, then the least they can do is at least try to make sure it behaves like the real deal under all circumstances, yes... including C++ code... that doesn't make use of SDL... with static object destructors... that can ->Release() objects after main() returns. This tendency to design everything under the assumption that everybody programs in C style can be kind of disturbing at times...