Unexpected behaviour of activex application when enabling madExcept

delphi package - automated exception handling
Post Reply
rnavarro
Posts: 2
Joined: Tue Jan 11, 2022 8:55 pm

Unexpected behaviour of activex application when enabling madExcept

Post by rnavarro »

Hi,

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 7.6.6.14 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 v5.3.0.21, and the fingerprint sensor is a ZK4500 in case its helpful.

Delphi XE7 - Windows 10

Thanks in advance.
Attachments
MBR_Files.7z
Zipped mbr files
(8.56 KiB) Downloaded 16 times
madshi
Site Admin
Posts: 10528
Joined: Sun Mar 21, 2004 5:25 pm

Re: Unexpected behaviour of activex application when enabling madExcept

Post by madshi »

I'm not really sure what's going on there. madExcept does hook into threads, in order to be able to report crashes in threads. One thing you could try is call "madExcept.DontHookThreads()" in your initialization. Does the problem go away if you do that? It's not recommended, though.

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.
rnavarro
Posts: 2
Joined: Tue Jan 11, 2022 8:55 pm

Re: Unexpected behaviour of activex application when enabling madExcept

Post by rnavarro »

Ok, i tried calling "madExcept.DontHookThreads()" and the problem does go away.

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?

madExcept.DontHookThreads;
use the fingerprint scanner;
quit using the fingerprint scanner;
madExcept.HookThreads;

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:

process: 4294967295
threadAttr: nil
stackSize: 0
threadProc: $70971500
param: $72D1278
creationFlags: 0
attribList: nil
@threadId: nil


second thread:

process:4294967295
threadAttr: nil
stackSize: 0
threadProc:$66B4344
param: $6840A38
creationFlags: 4
attribList: nil
threadId: 0


Do you suggest any recommendation i can make to the provider of the SDK or think of something they should check?

Thanks
madshi
Site Admin
Posts: 10528
Joined: Sun Mar 21, 2004 5:25 pm

Re: Unexpected behaviour of activex application when enabling madExcept

Post by madshi »

You could check the definition of the thread function of the threads created by the SDK (via disassembler). It should be stdcall with 1 parameter, so it should end with "ret 4".

But yes, doing those calls as you mentioned would be a (nasty) workaround.
Post Reply