Heinis,
can you see any IRP_MJ_READ requests for the mouclass driver when you
logon remotely and the “Black Box InvisaPC” is plugged ? Check it.
This is an important step to analyse problem. Perhaps the touchscreen
is mapped on the keyboard device, not mouse, and you need to write a
keyboard filter instead a mouse filter. Perhaps InvisaPC bypasses the RDP
input stack although I cannot imagine this.
For example, locate the mouclass driver object (use ObReferenceObjectByName
with device “\Driver\mouclass”) and replace it’s IRP_MJ_READ handler
with your own function:
PDRIVER_DISPATCH OriginalFunction;
int Counter = 0;
NTSTATUS HookFunction(DEVICE_OBJECT * pDeviceObj, IRP * pIrp)
{
DbgPrint(“%d\r\n”, Counter++);
return (OriginalFunction(pDeviceObj, pIrp));
}
InvisaPC must be already plugged at this time.
Now logon remotely and try to move a mouse. If you do not see any debug
messages (are you see debug messages normally ?) the game is over
(or you need to go deeper).
As a next stage, test your driver with the physical mouse, i.e. in the
console environment only. Use driver verifier, static asserts, and,
if you have, checked builds of Windows. Follow the common driver
development guidelines, check return values, do not use paged memory
on a high IRQL, implement all standard routines correctly and so on.
Also, and this is very important, try to plug and unplug other mouse,
touchscreen and touchpad devices during testing. In all cases your driver
must intercept all input without any hangs, loses and any other “anomalies”.
Check that a filter always correctly attached to the all input stacks.
Use !drvobj, !devobj, !devstack commands of the WinDBG. Also you may
call IoRegisterPlugPlayNotification and see every attach and detach events
related to the mouse stack (you need GUID_DEVICE_INTERFACE_ARRIVAL/REMOVAL
on a GUID_DEVINTERFACE_MOUSE).
WinDBG, MSDN and W.Oney (see the chapter “Filter drivers”) will help you.
Now you are ready to intercept the RDP input.
Unfortunately, I never write a filters for the RDP that are attached
to the input stack below the class driver (kbdclass/mouclass). And I can’t
promise that a moufltr code sample will works in the RDP session, especially
with the third-party device installed.
So, try to attach your filter over a mouclass.
This is a pretty simple solution: all of you need is implement AddDevice,
PnP and the Power handlers. And, obviously, you need a read handler.
Other requests may be passed down without any processing (“forward and forget”).
I have positive experience with this technique: everything works fine on
all Windows versions starting from the Windows XP.
