HID reports are not delivered? consumed? by VHF?

[hansmbakker]

As discussed in #522 and in the comments on https://docs.microsoft.com/en-us/windows-hardware/drivers/hid/virtual-hid-framework--vhf-:
It seems that custom HID reports do not work well with the HID Injector. I could inject the keyboard HID reports from the sample, they seemed to work.

However when I changed the HID reports AND the HID report descriptors to emulate a radial controller, nothing happened anymore. The wheel tab in the settings app appeared (showing that windows properly recognized the HID report descriptors) but the HID events did not work.

I'll post code later so that it can be reproduced.

[hansmbakker]

Quotes from @FansteKaRiNa1998 from #522

Try copying the code to a new project, works for me. I have the exact same problem with delivering actual report.

@FansteKaRiNa1998 what works for you? I thought that you said that you have a problem?

When transfering a project to x64, additional dependencies are deleted. That's why you must add in the project properties -> linker -> input -> additional dependencies
next line: (DDK_LIB_PATH)vhfkm.lib

That line was already ok here, I took the whole HIDInjector project as a basis, I didn't create a project from scratch.

[FansteKaRiNa1998]

Did you look at the device manager when you tested keyboard? When testing for a gamepad, it would appear only in USB Game Controllers, while it wouldn't appear in Device Manager. Also, I could uninstall driver at any time.

The difference with testing a keyboard is that it created a HID compliant device in the Keyboard section of Device Manager, and I couldn't uninstall the main driver until I uninstalled HID compliant keyboard I have just added.

Maybe the problem is not registering it in the system? This is a quote from https://docs.microsoft.com/en-us/windows-hardware/drivers/hid/virtual-hid-framework--vhf-
,,Note In some scenarios, a HID client might need to identify the source of HID data. For example, a system has a built-in sensor and receives data from a remote sensor of the same type. The system might want to choose one sensor to be more reliable. To differentiate between the two sensors connected to the system, the HID client queries for the container ID of the TLC. In this case, a HID source driver can provide the container ID, which is reported as the container ID of the virtual HID device by VHF".

This probably means what I have just described: the source is an unknown device and thus it doesn't listen, while, for the keyboard, it properly registers the device object and thus it listens to it.

[hansmbakker]

Unfortunately the kernel mode debugging tools are a disaster. I could not connect properly with the Visual Studio debugger, but oddly enough I CAN connect with WinDbg Preview from the Windows Store. However with that I'm not sure what to do.
So - unfortunately now new insights.

Having my custom code deployed I did see that there is a HID-compliant device node in the Human Interface Devices class. It reports being on Virtual HID Framework (VHF) HID device which is also in the Human Interface Devices class. Lastly there is the Sample device node.

Unfortunately it still doesn't give a sign of life..

[FansteKaRiNa1998]

In which Visual Studio are you working? Also, describe the problem with kernel mode debugging.

[hansmbakker]

I’m using visual studio 2015 update 3 with WDK 15063 since unfortunately that is the only usable combination now.

I tried WDK 16278 on vs 2017 15.4.0 preview I but that didn’t install, but somehow the windbg version in visual studio 2015 got upgraded to 16278..

Visual studio 2015 can provision the target pc properly and also it can deploy the driver. However that builtin windbg version does not connect to the target of while the WinDbg Preview app from the windows store can connect to the target fine. So not a problem with the target pc.

Lastly I didn’t know how to use that separate Windbg Preview app - it didn’t recognize the source files I loaded, therefore I couldn’t set breakpoints properly

[FansteKaRiNa1998]

You mean you deploy the driver successfully but you don't see any messages shown?

[hansmbakker]

Yes the driver is deployed successfully, but when running the HidInjectorTest sample app, which uses modified HID reports so that they match the modified HID report descriptors, nothing happens. The driver / device is correctly recognized as a Windows Wheel device but no actions are triggered.

[FansteKaRiNa1998]

Okay, we recognized that problem earlier. I am asking you about KdPrint/DbgPrint messages. I thought they also don't display?

[hansmbakker]

Aah - You mean I should see them in WinDbg without having a breakpoint set? I didn't notice them, but I'll have a look again when I'm home.

Did you do any kernel debugging? Did you see these messages?

[FansteKaRiNa1998]

For that, there are three possible reasons that I know of:

1. Something went wrong when turning up the test machine or the computer you are programming on. This solution is the easiest and it just requires you to reboot.

2. When provisioning target device for deployment, you mismatched your own ip address (host address) or your address isn't static so next time you booted in it got changed. Try updating host address to solve this problem.

3. You didn't add a key in RegEdit to make those messages pop up. This is the link which solves it: http://karuppuswamy.com/wordpress/2008/09/04/enabling-debug-print-dbgprint-in-windows-vista-and-server-2008/
   NOTE: don't edit default value "default". Add a new value "DEFAULT" and apply the described rule.

Can you execute DebugView on that Win 10 tablet? If anything can see these messages, than the DebugView in administrative mode (check Capture -> Capture Kernel is checked) can see these messages.

This is going off the current topic, but I didn't understand clearly what is your problem. I will try to stick to the topic.

[hansmbakker]

I tried
ed Kd_DEFAULT_Mask 0xFFFFFFFF and ed Kd_DEFAULT_Mask 0x8 according to https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/reading-and-filtering-debugging-messages (KdPrint uses the default component and by default it publishes at level 3 which in bitmask is 0x8). It showed a lot of Windows kernel messages but strangely enough not the ones that are in the HidInjector Sample driver code... The driver is installed fine, though, and the test application finds its device node properly (if it is not installed the test application will return an error)

I don't know what I'm missing here...

[FansteKaRiNa1998]

You must restart test PC after making changes in its RegEdit

[hansmbakker]

I didn’t do it via regedit, I did it directly via WinDbg. Those commands should have effect immediately. And they triggered other log messages from Windows.

[FansteKaRiNa1998]

I really can't help you other way, I am not familiar with the utility.