Recently I enabled madExcept on a project that uses an activeX to read a human fingerprint from a sensor.
The fingerprint sensor exposes an SDK through an activex control.
After initialization of the SDK one can register an event handler (OnImageReceived) that gets fired whenever the fingerprint sensor captures a finger image.
The problem is that when we have a madexcept enabled application, that event doesn't get fired. This behavior doesnt occur when the application doesnt use madexcept. I have also tried with eurekalog (v 18.104.22.168 quite old) and I dont get the problem either.
I dont know the inner workings of the activex but we find that it uses some threads to achieve the funcionality. When the sensor detects a finger, one thread finishes, and another starts; and in between the OnImageReceived event gets fired
When we use madexcept the thread finishes, but no other starts and the onImageReceived event handler doesnt get fired.
We have reported this behavior to the manufacturer but did not have a response yet.
Do you imagine how can madexcept be interfering with the sdk to have this behavior?
Do you have an idea of what can we try to workarround this problem?
Also, after some trial an error we have found that activating "report resource leaks" option the application behaves as expected (the event gets fired and we can access the captured fingerprint image)
I used the madTraceProcess32.exe tool to get data from the application threads and the difference i can see is that right after the 'sensorGetStatus' function is called,
madExcept uses HookedThreadExcecute and CallThreadPRocSafe (when the "report source leaks is not enabled")
I attached both mbr files, one with "report source leaks" enabled and other unenabled.
The SDK that im using for the fingerprint capture is ZKFinger SDK v22.214.171.124, and the fingerprint sensor is a ZK4500 in case its helpful.
Delphi XE7 - Windows 10
Thanks in advance.
- Zipped mbr files
- (8.56 KiB) Downloaded 16 times
It's hard for me to say why the problem happens. Probably the best way to analyze it would be to set breakpoints in the fingerprint SDK code to see why it doesn't call your callback function.
I've had it before that some 3rd party code creates threads using an incorrect thread function definition, and that caused problems with madExcept (but not without). I've no idea if that could be the same problem here.
Unfortunately I don't have access to the SDK source code, and the provider has not responded yet my query.
Can i consider doing this as a workaround?
use the fingerprint scanner;
quit using the fingerprint scanner;
I have set a breakpoint at HookedCreateRemoteThread, HookedCreateRemoteThreadEx, HookedCreateThread and when I initialize the SDK it stops at HookedCreateRemoteThreadEx the values of the parameters are:
Do you suggest any recommendation i can make to the provider of the SDK or think of something they should check?
But yes, doing those calls as you mentioned would be a (nasty) workaround.