perevoznyk / swelio-sdk

Belgian eID card SDK for .NET and C++

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

ReaderCallbackDelegate triggered constantly

Rans4ckeR opened this issue · comments

Hi, do you have an idea what might cause this?

ReaderCallbackDelegate (Swelio32.dll, SetCallback) is being triggered constantly with eventCode CardEvent.ReadersChange. This is triggered every second and never ends.

There's only 1 reader connected ACS CCID USB Reader 0.
The reader and driver have been reinstalled several times with no luck.
The reader itself was already replaced with a different one of the same type.
Tested on version 1.4 and 1.8.

Reader callback is triggered when Windows reports the change in the list of the smartcard readers or in case if Windows stops smart cards readers service. The services stops and starts automatically in Windows 10 when reader is removed or inserted.
It can be the problem of the reader power management. When reader is not used then Windows is trying to put in in the sleep state. Maybe you can try to do soething like this: https://apteryx.zendesk.com/hc/en-us/articles/360041367673-Disable-USB-Power-Management-Selective-Suspension. I can also try to implement filter and make and option not to trigger callback function in this situation, but then would be not possible to detect when the reader is removed

@perevoznyk I tried changing those usb power settings but there's no change in behavior. Note that applications not using swelio-sdk seem to work fine on the same pc with the same reader and card (e.g. Belgium eID Viewer). OS is Windows 10. Any other ideas or is there something I can check/run on the pc to help debug?

In 1.18.7 release I added 2 additional properties to control the card reader events. In addition to TraceEvents there are TraceHardwareEvents and TraceServiceEvents .

I would suggest to set TraceServiceEvents to false and do the test. If this doesn't help, then set TraceHardwareEvents to false.
This will stop triggering readers list change event.

@perevoznyk I'm not sure what changed on this particular PC but for some reason calling the Swelio64.dll SetCallback now causes the application to crawl to a halt. This now happens with older versions as well. When using the included EIDTestApp as soon as SetCallback is called you can see the individual user controls being drawn, each control taking about a second. The callback is not triggered for any events and the app remains slow to react even when left running for many minutes. When commenting out the call to SetCallBack the app draws the controls as expected and reacts normally. The list of readers is populated as expected so Swelio64.dll GetReadersCount etc. are fine.

Do you have an idea why SetCallback might cause this behavior? Could you perhaps give some insight on what it is doing behind the scenes?

@Rans4ckeR Please try v1.18.8
In code of event activation

private void ActivateCardEventsTracing()
       {
           engine.CardInserted += new EventHandler<CardEventArgs>(engine_CardInserted);
           engine.CardRemoved += new EventHandler<CardEventArgs>(engine_CardRemoved);
           engine.ReadersListChanged += new EventHandler(engine_ReadersListChanged);
           engine.TraceHardwareEvents = true;
           engine.TraceServiceEvents = true;
           engine.TraceEvents = true;
       }

change engine.TraceHardwareEvents = false;
You can also try engine.TraceServiceEvents = false;

Behind the scenes the engine is doing the following:

for all attached card readers the function SCardGetStatusChange is called to get the card reader status change. After timeout the worker thread doing short sleep and calling the same function in the loop.

Additionally, the same function is called for card reader with name "\\?PnP?\Notification" to get PNP notifications for USB attached card readers.

In case of the status change the worker thead will send a message to the main thread with the reader index and the event code

@perevoznyk setting TraceHardwareEvents to false fixed the issue when using EIDTestApp (1.18.8).
Would you say it is safe to set TraceHardwareEvents to false for all configurations, or would you recommend only setting it to false for PCs where this problem occurs? Do you have an idea why this could occur on some systems?

@Rans4ckeR the TraceHardware events is needed if your application must response to USB card reader insertion or removal while application is running. If this is not important for application, then you can switch it off to save application resources; otherwise it is better to set it to false only in case of problem.
I suspect that there is a physical problem with PC where the code is not working properly. But I would definetely do some extra tests to investigate it