Windows 8.1 - Teensy PID_0487 (Serial/Keyboard/Mouse/Joystick) no longer recognised

Status
Not open for further replies.
Experimentalist

Experimentalist

Well-known member
Hi All

I have a very strange problem which I have been trying to fully understand.

My Windows 8.1 desktop will no longer enumerate the HID elements of the 'Serial/keyboard/Mouse/Joystick' Teensy USB type when the original Vendor and Product IDs are used, VID_16C0 and PID_0487 respectively. The USB serial element still functions fine.

If I set the Teensy to any other USB type it works fine and my tests seem to show that something is corrupted for that particular product ID, 0487.

If I edit '\hardware\teensy\cores\teensy3\usb_desc.h' and change the PID for the 'Serial/keyboard/Mouse/Joystick' device, I tried 0489, then download it will reappear.

I think the issues may have come from using both T3.0 and T3.1 on the same machine but that is just a hunch

I have tried removing all devices with USBDeview and also with Windows Devcon but the problem persists

Any ideas?

Ex
 
Does anything show up in the Windows Device Manager, like a device with a yellow triangle error?

If so, maybe you can right-click on it and tell Windows to uninstall or reinstall the driver. I have no idea why Windows gets so messed up sometimes, but sometimes just getting it to dump stale stuff and reinstall fixes everything.
 
Paul, thanks for the quick response. No nothing in device manager with regard to HID devices expected or any devices in error. I can see the USB serial port and I can re-program it. As I said if I edit the PID for USB_SERIAL HID and then recompile it will appear and everything works, I just can't get it to work on the original PID for USB_SERIAL_HID of 0487. I have tried running in safe mode and removing all registry entries relating to VID_16C0&PID_0487, still no joy. It actively refuses to let me delete 2 of the entries.

Here are the Teensy entries under: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB

RegKeys.JPG

It has me baffled at the moment
 
This happened to me again this morning and I found this after searching Google. It took me a minute or so to notice it was me that had raised the issue in the first place! My only regret was not publishing how I fixed it. After 4 hours trying to fix this and having lost all keyboard functionality along the way I have finally had to submit and use system restore to restore my PC. Luckily I had an automatic restore point from 3 days ago. I am updating this so that if it happens again at least I know how I resolved it!
 
Does your registry have HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\DriverSearching with key SearchOrderConfig set to 1?

If so, try changing it to 2. (this is supposed to be a safe edit)

This only seems to make a difference on Windows 7 & 8.

Also, I've seem some pretty stern warnings about the dangers of messing with stuff in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum. Apparently Microsoft even added some special security/permissions token to prevent some edits. Seems a good rule of "look but don't touch" for that part of the registry....
 
FWIW, I've spent the last few weeks working on a major redesign of how Teensyduino detects and communicates with USB. It's still pretty rough around the edges, but here's the first beta.

https://forum.pjrc.com/threads/49831-Teensyduino-1-42-Beta-1

The new ports detection on Windows is able to catch the case where Windows has detected the USB device, but then had problems creating the device instances for its interfaces, or problems loading their drivers. Of course it can't actually fix those problems (or at least not yet....) and without device handles created by working drivers, there only so much that can be done. But at least the new code can show you the USB device and indicate there's a problem, rather than leaving Arduino's Tools > Ports menu blank.
 
PaulStoffregen said:
Does your registry have HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\DriverSearching with key SearchOrderConfig set to 1?

If so, try changing it to 2. (this is supposed to be a safe edit)

This only seems to make a difference on Windows 7 & 8.

Also, I've seem some pretty stern warnings about the dangers of messing with stuff in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum. Apparently Microsoft even added some special security/permissions token to prevent some edits. Seems a good rule of "look but don't touch" for that part of the registry....
Click to expand...

Hi Paul, sorry only just had chance to catch up with my email. I am now running Windows 10 but that key is set 1. You indicate that this is not used in Windows 10 though. I have had to run system restore a couple of times and I am currently dreading a reboot as none of my bespoke mouse buttons are working and I fear this means that I may suffer the same fate again.
 
PaulStoffregen said:
FWIW, I've spent the last few weeks working on a major redesign of how Teensyduino detects and communicates with USB. It's still pretty rough around the edges, but here's the first beta.

https://forum.pjrc.com/threads/49831-Teensyduino-1-42-Beta-1

The new ports detection on Windows is able to catch the case where Windows has detected the USB device, but then had problems creating the device instances for its interfaces, or problems loading their drivers. Of course it can't actually fix those problems (or at least not yet....) and without device handles created by working drivers, there only so much that can be done. But at least the new code can show you the USB device and indicate there's a problem, rather than leaving Arduino's Tools > Ports menu blank.
Click to expand...

Paul, thanks for the reply, as ever. I will try and have a look at this beta as soon as I get a chance but my work is crazy busy presently leaving me with little time to play. It's very odd what happened to my PC as everything had been working fine for some time so it was obviously caused by one update or another. The most recent change that I could remember making was updating Visual Studio Code to V1.20.1 and I am still concerned this may have been the root of the issue but it's just a hunch. Thanks again
 
FWIW, the latest beta versions are a major effort I've been making over the last month to improve how we detect USB. It still isn't ready for general use, but the new code can detect when a device is present but Windows hasn't loaded a driver, or has some other problem.
 
Status
Not open for further replies.
Back
Top