I am working on an Java application which uses smartcardio
to work with smartcard.
It must be possible to have one removing its USB card reader and then inserting it again without starting again the applet.
I am using the terminals()
and waitForChange()
methods to detect terminal changes and it is working fine on Linux, MacOS and Win7.
But on Windows 8 (and Windows 8 only), after the removal of the last terminal, these methods throw a SCARD_E_NO_SERVICE
CardException
, and don't detect any more changes.
I'm not sure what "Service" is it talking about. But I think this is launched in my thread when I call TerminalFactory.getDefault()
to have a TerminalFactory
singleton. And I think this singleton may have a way to manage the underlayed service and this is what is broken.
Has anyone any lead on how to manage terminal disconnection with smartcardio
on Windows 8 ?
I have found a way, but it's using reflective code. I'd rather found a cleaner method, but it seem there is no official API to manage Smart Card Context. All classes are private.
The
initContext()
method ofsun.security.smartcardio.PCSCTerminals
(http://www.docjar.com/html/api/sun/security/smartcardio/PCSCTerminals.java.html) prevents new threads from getting a new context after the first one was initialized : the method is called, but the context is seen as a singleton and isn't re-initialzed.Passing through the
private
in everything around this withjava.lang.reflect
, it is possible to force the creation of a new context and store its new id as the "official"contextId
. This should be done before instanciating the newTerminalFactory
.(This is just a comment but I don't have enough rep to post comments.)
The service it refers to is the Windows Smart Card service, also known as the smart card resource manager. If you open the Services MMC console you'll see it there with the startup type set to Manual (Trigger Start). In Windows 8 this service was changed to run only while a smart card reader is attached to the system (to save resources) and the service is automatically stopped when the last reader is removed. Stopping the service invalidates any outstanding handles.
The native Windows solution is to call SCardAccessStartedEvent and use the handle it returns to wait for the service to start before using SCardEstablishContext to connect to the resource manager again.
This post is quite old, but it has been useful for me to fix the problem described on Windows 8.
The solution from JR Utily did not work fully: in case of a reader unplugged then plugged again, there were errors on the CardTerminal instance.
So I added some code to clear the terminals list, as you can see in the code below.