DISE Programmer application sometimes won't use the correct handle to access the HID Keyboard.

[CJGuirao]

I separated this issue in a new different thread for the shake of clarity.

Problem:

Sometimes after plugging and unplugging the keyboard in different ports the keyboard the Programmer app won't be able to communicate to the keyboard.

Causes:

It seems that when you plug the DISE there are two devices listed as connected in windows HIDLibrary.
The last one is always used. But not always the correct one.

How to replicate:

Connect the keyboard in different USB ports until the app stops showing any of the keypresses despite of showing the green connected icon.

Workaround:

Disconnect the DISE and then using a program like devmanview remove all the non connected HID entries. then connect the keyboard and it will work again. Beause windows will list the devices and install the drivers in the right order.

Details and a temporary fix:

I've changed the code from the InitDevice to debug whats been listed, and all the available information from each device using this code:
** MainWindow.xml.cs** Line 248 function InitDevice()

 private void InitDevice()
        {
            if (kbdDevice != null)
                return;
            foreach (HidDevice detectedKbd in HidDevices.Enumerate(VendorId, ProductId)) {
                Console.WriteLine("Detected one Keyboard connected!");
                Console.WriteLine("Detected: " + detectedKbd.ToString());
                Console.WriteLine("Description: " + detectedKbd.Description.ToString());
                Console.WriteLine("DevicePath: " + detectedKbd.DevicePath.ToString());
                Console.WriteLine("Attributes: " + detectedKbd.Attributes.ToString());
                Console.WriteLine("Capabilites: " + detectedKbd.Capabilities.ToString());
                if (detectedKbd != null && detectedKbd.IsConnected &&  detectedKbd.DevicePath.Substring(detectedKbd.DevicePath.Length - 3) != "kbd")
                {
                    Console.WriteLine("Detected one that will work :) ");
                    kbdDevice = detectedKbd;
                }
                else Console.WriteLine("Detected one that won't work :( ");

            }
            //kbdDevice = HidDevices.Enumerate(VendorId, ProductId).LastOrDefault();
            if (kbdDevice == null)
                return;
            dispatcherTimer.Stop();
            SetTitle(true, "Connected");
            kbdDevice.Inserted += KbdDevice_Inserted;
            kbdDevice.Removed += KbdDevice_Removed;
            kbdDevice.MonitorDeviceEvents = true;
        }

This modification in a non working condition will make the keyboard work and display this at the output:

Detected one Keyboard connected!
Detected: VendorID=0x0483, ProductID=0x573E, Version=512, DevicePath=\\?\hid#vid_0483&pid_573e&mi_01#a&177847e2&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
Description: Dispositivo compatible con HID
DevicePath: \\?\hid#vid_0483&pid_573e&mi_01#a&177847e2&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
Attributes: HidLibrary.HidDeviceAttributes
Capabilites: HidLibrary.HidDeviceCapabilities
Detected one that will work :)

Detected one Keyboard connected!
Detected: VendorID=0x0483, ProductID=0x573E, Version=512, DevicePath=\\?\hid#vid_0483&pid_573e&mi_00#a&4482ba4&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}\kbd
Description: Dispositivo de teclado HID
DevicePath: \\?\hid#vid_0483&pid_573e&mi_00#a&4482ba4&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}\kbd
Attributes: HidLibrary.HidDeviceAttributes
Capabilites: HidLibrary.HidDeviceCapabilities
Detected one that won't work :( 

The only difference that the HIDLibrary is showing as far as I know is the ending \kbd of one of them on the DevicePath.
What the modification is doing to make the program select the right one is:

• Checking every entry listed by the search function of the Enumerate method.
• Checking for each entry that the device is listed as connected
• Checking that entry doesn't end with kbd. Because that's the device that won't work.

Final notes

I have the feeling that this fix is kind of ugly. Excluding a device by it's ending on the device path probably doesn't cut it.
And i'm unsure about the longevity of the fix on future Windows releases.

I don't know if anyone knows a better solution, to differentiate between the good and bad HID device now that we have the problem identified.

If you want to have this solution implemented for the time being, I can clean up the logging output lines and commit a pull request.

[shaise]

I just can't reproduce this issue on my PC. No matter what usb port I use, it always recognize the device.
Can you advise how to reproduce this issue?
What windows version do you use?

[CJGuirao]

I'm using Windows 11

Using devmanview64 I can see the two installed devices (look for the device with VID 0483 PID 573e) :

HID Keyboard Device	(Standard keyboards)	kbdhid	Keyboard		HID\VID_0483&PID_573E&MI_00\a&4482ba4&0&0000		0x000000a0	0x00000000	No	No	07/02/2023 4:15:39	07/02/2023 4:15:39		{7fa5de54-2ab7-5446-97a0-875568c42bd5}	{4d36e96b-e325-11ce-bfc1-08002be10318}	07/02/2023 4:15:39	07/02/2023 4:15:39	10/02/2023 4:17:55	10/02/2023 9:45:07	HID Keyboard Device	10.0.22621.1	keyboard.inf	HID_Keyboard_Inst.NT	21/06/2006	07/02/2023 4:15:39	


HID-compliant device	(Standard system devices)		HIDClass		HID\VID_0483&PID_573E&MI_01\a&177847e2&0&0000		0x000000e0	0x00000000	No	No	07/02/2023 4:15:39	07/02/2023 4:15:39		{7fa5de54-2ab7-5446-97a0-875568c42bd5}	{745a17a0-74d3-11d0-b6fe-00a0c90f57da}	07/02/2023 4:15:39	07/02/2023 4:15:39	10/02/2023 4:17:55	10/02/2023 9:45:07	HID-compliant device	10.0.22621.819	input.inf	HID_Raw_Inst.NT	21/06/2006	07/02/2023 4:15:39	

I had the issue twice , just by plugging the device while testing it. I used different ports on different hubs and it happened.

To force this issue It may work to unplug the device, uninstall the entry that is detected as a keyboard with devmanview and plug it again so windows reinstall the device driver.

That may switch the order of the devices.

[shaise]

Do you have an access to a windows 10 machine, to see if you have the same problem?

[CJGuirao]

No right now,
I'll find one to test it.

[twwaters]

I'm using Windows 11

Using devmanview64 I can see the two installed devices (look for the device with VID 0483 PID 573e) :

HID Keyboard Device	(Standard keyboards)	kbdhid	Keyboard		HID\VID_0483&PID_573E&MI_00\a&4482ba4&0&0000		0x000000a0	0x00000000	No	No	07/02/2023 4:15:39	07/02/2023 4:15:39		{7fa5de54-2ab7-5446-97a0-875568c42bd5}	{4d36e96b-e325-11ce-bfc1-08002be10318}	07/02/2023 4:15:39	07/02/2023 4:15:39	10/02/2023 4:17:55	10/02/2023 9:45:07	HID Keyboard Device	10.0.22621.1	keyboard.inf	HID_Keyboard_Inst.NT	21/06/2006	07/02/2023 4:15:39	


HID-compliant device	(Standard system devices)		HIDClass		HID\VID_0483&PID_573E&MI_01\a&177847e2&0&0000		0x000000e0	0x00000000	No	No	07/02/2023 4:15:39	07/02/2023 4:15:39		{7fa5de54-2ab7-5446-97a0-875568c42bd5}	{745a17a0-74d3-11d0-b6fe-00a0c90f57da}	07/02/2023 4:15:39	07/02/2023 4:15:39	10/02/2023 4:17:55	10/02/2023 9:45:07	HID-compliant device	10.0.22621.819	input.inf	HID_Raw_Inst.NT	21/06/2006	07/02/2023 4:15:39	

I had the issue twice , just by plugging the device while testing it. I used different ports on different hubs and it happened.

To force this issue It may work to unplug the device, uninstall the entry that is detected as a keyboard with devmanview and plug it again so windows reinstall the device driver.

That may switch the order of the devices.

Carlos,
Thank you for posting this! I had the exact same problem on my Windows 11 desktop. Your solution worked for me.

[CJGuirao]

Happy to help :)

[twwaters]

Happy to help :)

Carlos,
Do you still have the case CNC files that you made? If so, would you be willing to share?

I totally understand if you don't want to. That was a lot of work!