Is there a place to get the keyhookdll.dll files source code for the TAdvSysKeyboardHook usage.
We are having a very strange issue... where our program closes.. and it causes other software not by us.. to crash.
I can only debug so far, because this uses a DLL for some reason.
It would be nice to see if can track something down that is silly happening.
Details... Delphi 11.3, latest TMS UI pack.
Been able to reproduce easily my self.
Made a new program. Dropped TAdvSysKeyboardHook on form, Used the event to write to a TMemo what key was hit.
Kicks off some crashes and java program dies suddenly.
Also had Delphi itself just die also and disappear.
It is a "rare" chance of happening... i can't reproduce at a whim.
Just playing around doing whatever. may take 30 minutes to finally happen.
Event log where BDS.exe crashed while running... and seeeems keyhookdll.dll was related.
And when i evaluate the dmp log with winDbg
I am working on trying to get a dump log for JAVAW.exe
I am setup now to tell WER to create one next time JAVAW.exe crashes from this.
Doing some research.. as I wasn't even sure WHY a DLL was used... and came to find out.. its a requirement...
' in Windows, all global hooks must reside in a DLL (Dynamic-Link Library). The reason is that when a global hook is installed, the hook must be injected into the address space of every process that is to be monitored. This injection requires the hook's code to be in a DLL, which can be loaded into the different processes.
Here's how it works:
- A global hook (like WH_MOUSE_LL, WH_KEYBOARD_LL, etc.) can monitor events across multiple applications.
- When the system calls the hook procedure, it must inject the hook DLL into the address space of each process that receives the hook messages.
- Without being in a DLL, it wouldn't be possible to share the hook procedure across multiple processes, since each process needs to load the hook procedure code.
For local hooks, the code does not necessarily have to be in a DLL, as it only monitors a single application, and the hook procedure can be part of the application's own code.
So ok.. if that is the case... the DLL is killing programs in some fashion.
Javaw.exe dump stack trace...
The DLL that is deployed for a long time... has NO version stamp on it.
It looks to be from 3/17/2023 ... would be nice if it had version #.
I thought I was on latest pack.
Was not.
Installed latest UI pack.
The keyboarddll.dll file is the same thing. byte for byte..
So still same problems as I was able to get bds.exe and javaw.exe to crash after a little bit of playing around.
Since Win10/Win11 usage of this technique was no longer allowed/supported by Microsoft, so we had to stop supporting this component unfortunately.
ugh ok...it does work on 10/11.... to a degree... just causes some programs to blow up.
Then probably want to just remove it from package? or some red flags of some sort so people like us dont waste dozens of hours
If not supported by TMS, can the DLL source be released?
Not 100% sure what we can do with it if anything... but co-worker who been using this for ever asking.
We got like 20,000+ workstations across the country running this tool for doing lookups from multiple softwares... for like 15 years now or so.
So we need to figure out a stop gap solution for now.
I have to ask, what makes you say not supported anymore?
I can't find anything that really says "no" it does not.
There are things that say its probably a good idea to code sign the DLL to help with any Windows Defender Application Gaurd.
As mentioned, it does work ... other than odd issue of what is reported.
If we had the source, maybe we could deal with it our selves.... versionize and code sign the DLL too since we do that with our software already.