Hello NTDEV,
I have written a UMDF driver for my USB smartcard readers. What I want to do is to increment a “global” counter each time the driver loads the driver for the same smartcard reader brand and type, in order to be able to tell Windows which instance it is (when Windows issues an IOCTL_SMARTCARD_GET_ATTRIBUTE code SCARD_ATTR_DEVICE_UNIT).
So I inside my driver I want to return SCARD_ATTR_DEVICE_UNIT “0” for the first reader of brand A and type B and “1” for the second reader of same brand and type.
What is the most elegant way to do this? Currently I am tracking device instances and their indexes via the Windows registry. Is there a better way to do this inside the driver?
The native Windows smartcard driver is also an UMDF driver. How does it solve this task?
xxxxx@gmail.com wrote:
I have written a UMDF driver for my USB smartcard readers. What I want to do is to increment a “global” counter each time the driver loads the driver for the same smartcard reader brand and type, in order to be able to tell Windows which instance it is (when Windows issues an IOCTL_SMARTCARD_GET_ATTRIBUTE code SCARD_ATTR_DEVICE_UNIT).
So I inside my driver I want to return SCARD_ATTR_DEVICE_UNIT “0” for the first reader of brand A and type B and “1” for the second reader of same brand and type.
What is the most elegant way to do this? Currently I am tracking device instances and their indexes via the Windows registry. Is there a better way to do this inside the driver?
You can use a simple global variable for this. If the concept of a
global offends you, then add a context structure to your WDFDRIVER
object and store the counter in your context.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Hello Tim,
I forgot to mention that I am using UMDF 1.11 because of backward
compability reasons. Also, for each USB smartcard reader I connect, a
separate WUDFHost.exe process is started (I can see them in the task
manager). I already tried to use a global variable but it did not work,
because I get different values when accessing it from different driver
processes (which is logical). I am really wondering how Microsoft solved
this.
2017-05-09 18:52 GMT+02:00 Tim Roberts :
> xxxxx@gmail.com wrote:
> > I have written a UMDF driver for my USB smartcard readers. What I want
> to do is to increment a “global” counter each time the driver loads the
> driver for the same smartcard reader brand and type, in order to be able to
> tell Windows which instance it is (when Windows issues an
> IOCTL_SMARTCARD_GET_ATTRIBUTE code SCARD_ATTR_DEVICE_UNIT).
> >
> > So I inside my driver I want to return SCARD_ATTR_DEVICE_UNIT “0” for
> the first reader of brand A and type B and “1” for the second reader of
> same brand and type.
> >
> > What is the most elegant way to do this? Currently I am tracking device
> instances and their indexes via the Windows registry. Is there a better way
> to do this inside the driver?
>
> You can use a simple global variable for this. If the concept of a
> global offends you, then add a context structure to your WDFDRIVER
> object and store the counter in your context.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
></http:></http:>
Johnny Dakovo wrote:
I forgot to mention that I am using UMDF 1.11 because of backward
compability reasons. Also, for each USB smartcard reader I connect, a
separate WUDFHost.exe process is started (I can see them in the task
manager). I already tried to use a global variable but it did not
work, because I get different values when accessing it from different
driver processes (which is logical). I am really wondering how
Microsoft solved this.
One way would be to use a memory-mapped file. Well, the mapping object
gets a name, but the file does not need one. The technique is described
here:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa366551.aspx
There are also ways to declare one of your DLL’s sections to be “shared
data”, which ends up being implemented in much the same way.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Interproces communication. There are a number of solutions, Hooks are very effective (SetWindowsHookEx), windows messages (needs a window though), or writing to a file…
Since the registry is just a file your current method has as much merit as any, so stick with it.
This works great, thank you.
2017-05-09 22:32 GMT+02:00 Tim Roberts :
> Johnny Dakovo wrote:
> >
> > I forgot to mention that I am using UMDF 1.11 because of backward
> > compability reasons. Also, for each USB smartcard reader I connect, a
> > separate WUDFHost.exe process is started (I can see them in the task
> > manager). I already tried to use a global variable but it did not
> > work, because I get different values when accessing it from different
> > driver processes (which is logical). I am really wondering how
> > Microsoft solved this.
>
> One way would be to use a memory-mapped file. Well, the mapping object
> gets a name, but the file does not need one. The technique is described
> here:
> https://msdn.microsoft.com/en-us/library/windows/desktop/aa366551.aspx
>
> There are also ways to declare one of your DLL’s sections to be “shared
> data”, which ends up being implemented in much the same way.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
></http:></http:>
However, this works if only readers are connected to my system, which are
using my driver. There is inconsistency when I connect a reader which uses
my driver and afterwards connect a reader which uses Windows native driver.
The Windows driver will not see my memory-mapped file I created and apply
index 0 for its device.
I found out that, when the Windows driver is loaded it queries attributes
SCARD_ATTR_VENDOR_IFD_TYPE, SCARD_ATTR_VENDOR_IFD_TYPE and
SCARD_ATTR_DEVICE_UNIT from my driver (and from all other drivers currently
loaded). I guess this way the Windows driver can know which device units
are taken and apply a free one to its reader.
Does anybody how I can query these attributes from all loaded smart card
reader driver instances in my system?
2017-05-10 17:41 GMT+02:00 Johnny Dakovo :
> This works great, thank you.
>
> 2017-05-09 22:32 GMT+02:00 Tim Roberts :
>
>> Johnny Dakovo wrote:
>> >
>> > I forgot to mention that I am using UMDF 1.11 because of backward
>> > compability reasons. Also, for each USB smartcard reader I connect, a
>> > separate WUDFHost.exe process is started (I can see them in the task
>> > manager). I already tried to use a global variable but it did not
>> > work, because I get different values when accessing it from different
>> > driver processes (which is logical). I am really wondering how
>> > Microsoft solved this.
>>
>> One way would be to use a memory-mapped file. Well, the mapping object
>> gets a name, but the file does not need one. The technique is described
>> here:
>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa3
>> 66551.aspx
>>
>> There are also ways to declare one of your DLL’s sections to be “shared
>> data”, which ends up being implemented in much the same way.
>>
>> –
>> Tim Roberts, xxxxx@probo.com
>> Providenza & Boekelheide, Inc.
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list online at: http:>> lists.cfm?list=ntdev>
>>
>> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>> software drivers!
>> Details at http:
>>
>> To unsubscribe, visit the List Server section of OSR Online at <
>> http://www.osronline.com/page.cfm?name=ListServer>
>>
>
></http:></http:>
Are you using smclib or equivalent? None of the other smart card drivers query global state to report a unit id. This should be something you can do without global state.
Bent from my phone
From: xxxxx@lists.osr.com on behalf of Johnny Dakovo
Sent: Thursday, May 18, 2017 5:25:21 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Share information between two UMDF driver instances
However, this works if only readers are connected to my system, which are using my driver. There is inconsistency when I connect a reader which uses my driver and afterwards connect a reader which uses Windows native driver. The Windows driver will not see my memory-mapped file I created and apply index 0 for its device.
I found out that, when the Windows driver is loaded it queries attributes SCARD_ATTR_VENDOR_IFD_TYPE, SCARD_ATTR_VENDOR_IFD_TYPE and SCARD_ATTR_DEVICE_UNIT from my driver (and from all other drivers currently loaded). I guess this way the Windows driver can know which device units are taken and apply a free one to its reader.
Does anybody how I can query these attributes from all loaded smart card reader driver instances in my system?
2017-05-10 17:41 GMT+02:00 Johnny Dakovo >:
This works great, thank you.
2017-05-09 22:32 GMT+02:00 Tim Roberts >:
Johnny Dakovo wrote:
>
> I forgot to mention that I am using UMDF 1.11 because of backward
> compability reasons. Also, for each USB smartcard reader I connect, a
> separate WUDFHost.exe process is started (I can see them in the task
> manager). I already tried to use a global variable but it did not
> work, because I get different values when accessing it from different
> driver processes (which is logical). I am really wondering how
> Microsoft solved this.
One way would be to use a memory-mapped file. Well, the mapping object
gets a name, but the file does not need one. The technique is described
here:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa366551.aspxhttps:
There are also ways to declare one of your DLL’s sections to be “shared
data”, which ends up being implemented in much the same way.
–
Tim Roberts, xxxxx@probo.commailto:xxxxx
Providenza & Boekelheide, Inc.
—
NTDEV is sponsored by OSR
Visit the list online at: http:>
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:>
To unsubscribe, visit the List Server section of OSR Online at http:>
— NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at To unsubscribe, visit the List Server section of OSR Online at</http:></http:></http:></mailto:xxxxx></https:>