-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
this is a curiosity more than a problem … my driver works well also with
this little “bug”.
Could you tell me why a keyboard filter driver seems to not receive the IRP
for the first KEY_MAKE, but it starts
to receive packets only from the KEY_BREAK of that key ? This happens only
for the 1st key pressed once the filter
is installed. After that all works fine.
I’m very curious about that, even if it’s not a really big problem … it
causes me problems only if the
first key pressed is a SHIFT-ALT-CTRL (a key of which i’ve to keep track of
the keyup/keydown state), but
i can live well with that 
Thanx in advance for the reply,
Valerio
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0
iQA/AwUBP28Dr2Gxr2U3nc5EEQJswwCfZ53ezohmc89XSlB/zguWnsO3vxcAoMyy
+n3m0oCaGY7IK9HefoBarSQw
=Uo1k
-----END PGP SIGNATURE-----
How are you attaching to the class driver? through IoGetDeviceObjectPointer or are you in the UpperFilters class key and you are loaded by pnp for each device?
D
This posting is provided “AS IS” with no warranties, and confers no rights
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Valerino
Sent: Monday, September 22, 2003 7:14 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Keyboard filter not catching the very first IRP ?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
?
Hi,
?this is a curiosity more than a problem … my driver works well also with
?this little “bug”.
?Could you tell me why a keyboard filter driver seems to not receive the IRP
?for the first KEY_MAKE, but it starts
?to receive packets only from the KEY_BREAK of that key ? This happens only
?for the 1st key pressed once the filter
?is installed. After that all works fine.
?I’m very curious about that, even if it’s not a really big problem … it
?causes me problems only if the
?first key pressed is a SHIFT-ALT-CTRL (a key of which i’ve to keep track of
?the keyup/keydown state), but
?i can live well with that
?
?Thanx in advance for the reply,
?Valerio
?
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0
?
iQA/AwUBP28Dr2Gxr2U3nc5EEQJswwCfZ53ezohmc89XSlB/zguWnsO3vxcAoMyy
+n3m0oCaGY7IK9HefoBarSQw
=Uo1k
-----END PGP SIGNATURE-----
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
> How are you attaching to the class driver? through =
IoGetDeviceObjectPointer or are you in the UpperFilters class key and =
you are loaded by pnp for each device?
I’m using DriverWorks, and i see it uses the standard
IoGetDeviceObjectPointer
followed by IoAttachDeviceToDeviceStack (on \device\keyboardclass0). And
no,i’ve not an AddDevice routine … its a nonpnp driver.
What’s the problem with this approach ?
Thanx,
Valerio
There are 3 problems with this approach:
- there is no guarantee of when you attach to the stack, the raw input
thread (RIT) could have already opened the device and then you can run
out of stack locations in the IRP b/c the RIT has the wrong StackSize
value
- you will completely hose power management on the machine if you
don’t handle power, which I think you are not doing since you say you
don’t handle pnp. I think system control (ie WMI) is also busted as
well).
- there is no guarantee on that there is only one keyboard or that
keyboardclass0 is the only keyboard on the machine; on XP and later,
keyboardclass0 ends up being the terminal services redirected keyboard
more often then not, not the actual plugged in keyboard
D
This posting is provided “AS IS” with no warranties, and confers no
rights
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Valerio Lupi
Sent: Monday, September 22, 2003 10:15 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] RE: Keyboard filter not catching the very first IRP ?
How are you attaching to the class driver? through =
IoGetDeviceObjectPointer or are you in the UpperFilters class key and
=
you are loaded by pnp for each device?
I’m using DriverWorks, and i see it uses the standard
IoGetDeviceObjectPointer
followed by IoAttachDeviceToDeviceStack (on \device\keyboardclass0).
And
no,i’ve not an AddDevice routine … its a nonpnp driver.
What’s the problem with this approach ?
Thanx,
Valerio
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Thank you man!
Is that the cause of the missing 1st keydown ?
Better i switch my driver to wdm asap so … it was already in my
projects,anyway
btw : sometimes (very very rarely) my driver bugcheks saying that a worker
thread returned at a bad IRQL
(i use workitems to dump keystrokes to disk once my queue is full … i.e.
every 100 keystrokes i
fire a workitem). I’m puzzled about that … how a workerthread could return
at an higher IRQL
if the system (should) guarantee its executed at PASSIVE_LEVEL ?
Valerio
I would assume you are not releasing a spinlock or some other lock
before returning from your work item.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Valerino
Sent: Monday, September 22, 2003 3:58 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: Keyboard filter not catching the very first IRP ?
Thank you man!
Is that the cause of the missing 1st keydown ?
Better i switch my driver to wdm asap so … it was already in my
projects,anyway
btw : sometimes (very very rarely) my driver bugcheks saying that a
worker
thread returned at a bad IRQL
(i use workitems to dump keystrokes to disk once my queue is full …
i.e.
every 100 keystrokes i
fire a workitem). I’m puzzled about that … how a workerthread could
return
at an higher IRQL
if the system (should) guarantee its executed at PASSIVE_LEVEL ?
Valerio
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
> Thank you man!
Is that the cause of the missing 1st keydown ?
Better i switch my driver to wdm asap so … it was already in my
projects,anyway
Switching to a PnP driver may not solve the problem … I had a keyboard
filter driver on NT and always missed the first keystroke message. Posted
a message here a number of years ago about it and nobody had any
suggestions on why I was missing that elusive first message. I’m also not
the only one who has missed that message - I’ve received the two different
emails over the past few years from people asking if I ever fixed my
driver to get the first message.
Now all of this was on NT, not 2k or XP, so it might have been fixed in
the later versions but then again it may not. Just a word of caution that
you still might not be able to get that first item.
Judy L
Converting to PNP will solve the missing keystroke problem b/c there is
no longer a race between the device being created, the filter attaching,
and the raw input thread opening the device. If you install a service
callback in the filter (asusming you sit below kbdclass), you will see
each raw keystroke as they are reported.
D
This posting is provided “AS IS” with no warranties, and confers no
rights.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@itt.com
Sent: Wednesday, September 24, 2003 6:06 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: Keyboard filter not catching the very first IRP ?
Thank you man!
Is that the cause of the missing 1st keydown ?
Better i switch my driver to wdm asap so … it was already in my
projects,anyway
Switching to a PnP driver may not solve the problem … I had a keyboard
filter driver on NT and always missed the first keystroke message.
Posted a message here a number of years ago about it and nobody had any
suggestions on why I was missing that elusive first message. I’m also
not the only one who has missed that message - I’ve received the two
different emails over the past few years from people asking if I ever
fixed my driver to get the first message.
Now all of this was on NT, not 2k or XP, so it might have been fixed in
the later versions but then again it may not. Just a word of caution
that you still might not be able to get that first item.
Judy L
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
> Converting to PNP will solve the missing keystroke problem b/c there is
no longer a race between the device being created, the filter attaching,
and the raw input thread opening the device. If you install a service
callback in the filter (asusming you sit below kbdclass), you will see
each raw keystroke as they are reported.
I want to make sure I’m understanding this correctly and I’m not sure if
my interpretation is correct since I don’t know how the interaction
between the RIT and the device goes. Here’s the way I’m picturing the
timing of the race:
- RIT and device are created independently of each other but before the
filter
- RIT opens device and device, in response, sends an IRP (or whatever the
equivalent is between the device and the RIT) to the RIT waiting for the
first keystroke and that IRP** is pended by the RIT.
- In the meantime, the filter is being created and attaches to the device
after step 2 occurs but before step 4 occurs.
- The first keystroke comes in and is returned in the pended IRP** sent
in step 2 directly to the device since the device itself was the
originator.
- Now that the filter is attached, the next IRP** that is pended to the
RIT for the second (and subsequent) keystroke will have a “return” device
of the filter.
** IRP or equivalent
Is that right?
If it is, I guess there’s no way to fix the issue on an NT4 system since
that OS is not PnP … or is there? Can you force the filter driver to
load before the RIT or is the RIT part of the base device in NT?
Judy L
> If it is, I guess there’s no way to fix the issue on an NT4 system since
that OS is not PnP … or is there? Can you force the filter driver to
load before the RIT or is the RIT part of the base device in NT?
RIT is part of win32k, which is IIRC loaded after all System start drivers in
NT.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Kbdclass pends the IRP, but that is about right. Kbdclass is completely
public, it has been an NT DDK example since the beginning. I don’t know
what your load order group is, but you could modify the list to insert
your own group and have it depend on kbdclass’s group (NT4 only
solution).
D
This posting is provided “AS IS” with no warranties, and confers no
rights.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@itt.com
Sent: Wednesday, September 24, 2003 10:22 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: Keyboard filter not catching the very first IRP ?
Converting to PNP will solve the missing keystroke problem b/c there
is
no longer a race between the device being created, the filter
attaching,
and the raw input thread opening the device. If you install a service
callback in the filter (asusming you sit below kbdclass), you will see
each raw keystroke as they are reported.
I want to make sure I’m understanding this correctly and I’m not sure if
my interpretation is correct since I don’t know how the interaction
between the RIT and the device goes. Here’s the way I’m picturing the
timing of the race:
- RIT and device are created independently of each other but before the
filter
- RIT opens device and device, in response, sends an IRP (or whatever
the
equivalent is between the device and the RIT) to the RIT waiting for the
first keystroke and that IRP** is pended by the RIT.
- In the meantime, the filter is being created and attaches to the
device
after step 2 occurs but before step 4 occurs.
- The first keystroke comes in and is returned in the pended IRP** sent
in step 2 directly to the device since the device itself was the
originator.
- Now that the filter is attached, the next IRP** that is pended to the
RIT for the second (and subsequent) keystroke will have a “return”
device
of the filter.
** IRP or equivalent
Is that right?
If it is, I guess there’s no way to fix the issue on an NT4 system since
that OS is not PnP … or is there? Can you force the filter driver to
load before the RIT or is the RIT part of the base device in NT?
Judy L
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Thanks Doron! I know I’ve specified something for my group loading and
dependencies but I don’t remember off the top of my head (it’s been over
two years since I’ve worked on that particular project and it doesn’t
reside anywhere I can check quickly). Don’t you mean “modify the list to
insert your own group and have kbdclass depend on the filter’s group”
instead of what you wrote? Since kbdclass pends the IRP, the filter needs
to be running BEFORE kbdclass starts up and pends that first IRP. I think
that’s what you meant but its not what you wrote.
Ah, the joys of fixing a bug that’s been around for years (it doesn’t
really affect the overall performance of the whole project but it’s always
bothered me). Feels nice. Thanks again!
Judy
Kbdclass pends the IRP, but that is about right. Kbdclass is completely
public, it has been an NT DDK example since the beginning. I don’t know
what your load order group is, but you could modify the list to insert
your own group and have it depend on kbdclass’s group (NT4 only
solution).=20
D
This posting is provided “AS IS” with no warranties, and confers no
rights.=20
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@itt.com
Sent: Wednesday, September 24, 2003 10:22 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: Keyboard filter not catching the very first IRP ?
> Converting to PNP will solve the missing keystroke problem b/c there
is
> no longer a race between the device being created, the filter
attaching,
> and the raw input thread opening the device. If you install a service
> callback in the filter (asusming you sit below kbdclass), you will see
> each raw keystroke as they are reported.
I want to make sure I’m understanding this correctly and I’m not sure if
my interpretation is correct since I don’t know how the interaction
between the RIT and the device goes. Here’s the way I’m picturing the
timing of the race:
- RIT and device are created independently of each other but before the
filter
- RIT opens device and device, in response, sends an IRP (or whatever
the
equivalent is between the device and the RIT) to the RIT waiting for the
first keystroke and that IRP** is pended by the RIT.
- In the meantime, the filter is being created and attaches to the
device
after step 2 occurs but before step 4 occurs.
- The first keystroke comes in and is returned in the pended IRP** sent
in step 2 directly to the device since the device itself was the
originator.
- Now that the filter is attached, the next IRP** that is pended to the
RIT for the second (and subsequent) keystroke will have a “return”
device
of the filter.
** IRP or equivalent
Is that right?
If it is, I guess there’s no way to fix the issue on an NT4 system since
that OS is not PnP … or is there? Can you force the filter driver to
load before the RIT or is the RIT part of the base device in NT?
Judy L
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Wow seems i’ve started an interesting thread
Anyway, i’ve solved my problems temporarly, but i haven’t switched yet to WDM since my whole project (its a complete
system logging tool, including TDI and IFS filter) must support also old NT4.
But i’m finding another weirdness … if my driver gets loaded at startup, as Boot or as System, and placing it
in every possible group, with any possible load order, simply blocks the keyboard.
Driver gets loaded and it succesfully attach to kbdclass (i use a systemthread in driverentry to wait for the
presence of the keyboard device, since at boot time when i load kbdclass is not yet up… i must load very early
in the boot stage for other stuff of the driver,not kbd related ).
Seems like the system works normally but the keyboard is like dead…
Checking with OSR’s DeviceTree, it correctly shows my device attached to keyboardclass0.
Now, I’ve scratched my head for 2 days now and haven’t found a clue yet on what could be the cause…
Only thing i’m thinking about is that i do my testing/debugging using vmware 4.
Haven’t tested on a real system. Could that be the cause ?
Of course the driver,if loaded on the fly works fine (again tested only in vmware) …
Thank you all
Valerio
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0
iQA/AwUBP3OUQmGxr2U3nc5EEQLWpQCg42ouwVIMhEp9Mas1+JLV1W4Hn90An1pn
yMD4V6j+yWr3QyI0fAxl3HOo
=8L2d
-----END PGP SIGNATURE-----
Are you opening the class driver for read? If so, don’t. kbdclass only allows one reader and if you get there before the raw input thread, the RIT can’t open the device and suck data out of it.
d
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Valerino
Sent: Thursday, September 25, 2003 6:20 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: Keyboard filter not catching the very first IRP ?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
?
Wow seems i’ve started an interesting thread
?
Anyway, i’ve solved my problems temporarly, but i haven’t switched yet to WDM since my whole project (its a complete
system logging tool, including TDI and IFS filter) must support also old NT4.
?
But i’m finding another weirdness … if my driver gets loaded at startup, as Boot or as System, and placing it
in every possible group, with any possible load order, simply blocks the keyboard.
Driver gets loaded and it succesfully attach to kbdclass (i use a systemthread in driverentry to wait for the
presence of the keyboard device, since at boot time when i load kbdclass is not yet up… i must load very early
in the boot stage for other stuff of the driver,not kbd related ).
Seems like the system works normally but the keyboard is like dead…
Checking with OSR’s DeviceTree, it correctly shows my device attached to keyboardclass0.
Now, I’ve scratched my head for 2 days now and haven’t found a clue yet on what could be the cause…
Only thing i’m thinking about is that i do my testing/debugging using vmware 4.
Haven’t tested on a real system. Could that be the cause ?
Of course the driver,if loaded on the fly works fine (again tested only in vmware) …
?
Thank you all
Valerio
?
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0
?
iQA/AwUBP3OUQmGxr2U3nc5EEQLWpQCg42ouwVIMhEp9Mas1+JLV1W4Hn90An1pn
yMD4V6j+yWr3QyI0fAxl3HOo
=8L2d
-----END PGP SIGNATURE-----
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Doron, what do u mean by “opening for read” ?
I do this :
- I load in the filter group
- In driverentry, i create a systemthread to wait for
\device\keyboardclass0 to be available. I simply loop with
IoGetDeviceObjectPointer until it succeeds, and after that i dereference
its fileobject ptr (i do this way for kbd filter and for TDI filter, since
both are not yet available when i load)
I’ve tried to remove the IoGetDeviceObjectPointer loop and (just for trying)
loading just after kbdclass … but still, keyboaracd seems dead.
Since i use DriverWorks classes, i examined their sources to check if they
do something different than the usual IoAttachDevice etc… but they
don’t.
Seems they don’t clear the DO_DEVICE_INITIALIZING flag, but i do myself from
my code.
Any further tip ?
Thanks,
Valerio
“Doron Holan” wrote in message
news:xxxxx@ntdev…
>
>Are you opening the class driver for read? If so, don’t. kbdclass only
allows one reader and if you get there before the raw input thread, the RIT
can’t open the device and suck data >out of it.
d