Andrew Jackson wrote:
I think that the resource manager basically doesn't work right unless
you return either STATUS_SUCCESS or STATUS_PENDING from a tracking IRP
and then sometime complete the IRP with STATUS_SUCCESS or
STATUS_CANCELLED.

Does your driver fully pass IFDTEST? It checks to make sure that the
expected error returns happen in a variety of situations. I don't know
if it would catch this problem, but I suspect that the part A test
might.

--
Walter Oney, Consulting and Training
SmartCard drivers a specialty

"Walter Oney" <waltoney@oneysoft.com> wrote in message
news:3F0BD8AD.E4E57B26@oneysoft.com...
IRP.

the card state is correct when the call to 'reader power' exits but
something else in the resource manager isn't happy.

What I did wonder is should the driver still do the card tracking callback
even when it is doing power control? I know that the BULL sample driver does
NOT do that but maybe that's incorrect.

Andrew

IOCTL_SMARTCARD_IS_PRESENT call) but clearly the smartcard driver library
*is* - hence my query (particularly since there is no source code and the
documentation for smartcards could be described as minimal). The sequence of
IOCTLs was what I extracted tracing through my driver and is returned by the
driver library without anything in my driver being called at all.


few ideas to try.

Andrew

Andrew Jackson wrote:
Oh, wait a minute. STATUS_DEVICE_BUSY from SMCLIB means that a tracking
IRP is already pending. The resource manager must be confused to be
sending two of them.

--
Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com