Sticky Windows 11 and Legacy USB Drivers for HEX-USB+CAN and Older Interfaces

[wh17]

I don't think that will work because the host OS needs to recognize the interface before it can pass data to the VM.

On a Mac it works: If i connect any usb device i am asked whether to pass it directly to my Windows VM or to the Mac and then internally to a VM. The second way wont work with proper driver.
I am using Hex-Net on a M3 Mac (ARM) with Windows 10 and Windows 11 VM.
If i connect it directly to the Windows VM, MacOS has no knowledge of the Hex-Net.





So even that old Interface (i dont have one) would work that way.


Next week i will try online mode with SFD on my Mac but i have no doubt: i wlll work.

Yes i know, it is not supported from you and i use it at own risk, but it works and VCDS is two times faster (MLines) in a Windows 11 VM than on a native Windows 11 Laptop:-)

How about making a small partition on the Windows 11 PC and installing Windows 10 on that partition, then dual-boot?

That sound cool, running a VM with Windows 10 on a Windows 11 is .. how should i name it... cool/ugly/waste-of time... no i would not do this

The environment where vcds is used would be perfect for a used old laptop just for using vcds and nothing more. With an old Windos10 Laptop and no updates you are ready to use Hex-Can for the next 10 years :-)

 

[Sebastian]

A HEX-NET is not a legacy device and uses a simple HID driver, while HEX+CAN and Micro-CAN etc. require a special driver.

 

[wh17]

A HEX-NET is not a legacy device and uses a simple HID driver, while HEX+CAN and Micro-CAN etc. require a special driver.

The topic was legacy Hex-Can and Windows 11 NOT if HEX-NET is a legacy or not.

We talked about how to get the legacy device running - right ?

Solution 1: Patch Windows 11 and open doors (works but no good idea)

Solution 2: Windows 10 device (available for less than 100 Euro/Dollar)

Solution 3: Dual boot with Win 10 partition on a Windows 11 System (requires some time to change partition + install Win10)

Solution 4: Run Win 10 VM on a VM with pass-through like. VM Fusion on mac.. (works if you have this setup)

Solution 5: Upgrade Hex-Can to Hex-Net (works and saves your time+money)


Not all VM Solutions route the USB signal through the Host. With "pass through" the usb signel is passed directly to the VM. This works even if you Host-System does not support the device.

MacOS has not support and driver for any of your products but it works with pass-through to my Windows VM.

 

[Uwe]

Solution 4: Run Win 10 VM on a VM with pass-through like. VM Fusion on mac.. (works if you have this setup)

Unless you test this with an actual legacy interface, you don't know whether this really works, you are just assuming it will.

MacOS has not support and driver for any of your products but it works with pass-through to my Windows VM.

I'm pretty confident that MacOS supports HID devices natively; i.e. it has built-in drivers for HID devices, and current interfaces (HEX-NET and HEX-V2) enumerate as HID devices.

-Uwe-

 

[trv2]

The topic was legacy Hex-Can and Windows 11 NOT if HEX-NET is a legacy or not.

We talked about how to get the legacy device running - right ?

Solution 1: Patch Windows 11 and open doors (works but no good idea)

Solution 2: Windows 10 device (available for less than 100 Euro/Dollar)

Solution 3: Dual boot with Win 10 partition on a Windows 11 System (requires some time to change partition + install Win10)

Solution 4: Run Win 10 VM on a VM with pass-through like. VM Fusion on mac.. (works if you have this setup)

Solution 5: Upgrade Hex-Can to Hex-Net (works and saves your time+money)


Not all VM Solutions route the USB signal through the Host. With "pass through" the usb signel is passed directly to the VM. This works even if you Host-System does not support the device.

MacOS has not support and driver for any of your products but it works with pass-through to my Windows VM.

Solution 6: Use the original FTDI driver, which can be installed manually on older HEX-CAN without any problems and works perfectly:

https://ftdichip.com/wp-content/uploads/2025/03/CDM-v2.12.36.20-WHQL-Certified.zip

It's strange that RT doesn't offer this obvious solution.

 

[golfi_vend]

Solution 6: Use the original FTDI driver, which can be installed manually on older HEX-CAN without any problems and works perfectly:

https://ftdichip.com/wp-content/uploads/2025/03/CDM-v2.12.36.20-WHQL-Certified.zip

It's strange that RT doesn't offer this obvious solution.

Yes, unmodified FTDI drivers are OK. FTDI gets them WHQL certfied. Problem is that our old interfaces used a different block of PIDs that was assigned to us by FTDI, and if you change the PIDs for the driver, the certification is not valid. In the past this was no problem, since we could sign the modified driver with our regular Code Signing Certificate, and Windows was happy with that. Now Windows 11 is demanding not just a signed driver, but a WHQL certified driver, and the process to get that done is not something we are willing to undertake for legacy products that were introduced more than 20 years ago and that we haven't sold in almost 10 years.

-Uwe-

 

[trv2]

I think Uwe's explanation is somewhat misleading—not because it's technically incorrect, but because it omits the simplest solution.

Yes, Ross-Tech modified the original FTDI driver by adding support for their own VID/PID (0403/FA20) in the INF file. As Uwe explains, once the INF is modified, the original WHQL certification is no longer valid. That's absolutely correct.

However, there is no need to modify the INF file just to install the driver. The official FTDI driver package is already Microsoft WHQL-signed and can be installed manually through Device Manager without making any changes to the driver files.

For Windows 11 x64:
https://ftdichip.com/wp-content/uploads/2025/03/CDM-v2.12.36.20-WHQL-Certified.zip

For Windows 11 ARM64 (for MacBook with M series processor):
https://ftdichip.com/wp-content/uploads/2025/03/CDM-v2.12.36.20-for-ARM64-WHQL-Certified.zip

Simply extract the archive, open Device Manager, locate the interface, select Update driver → Let me pick from a list of available drivers, and point Windows to the extracted FTDI driver folder to ftdibus.inf. Windows will install the Microsoft WHQL-certified FTDI driver without requiring any changes to Secure Boot or other security settings.

In my opinion, this should be the first recommendation to users. It takes less than a minute, doesn't require disabling Secure Boot, doesn't require enabling Test Mode, and doesn't involve deleting EFI policy files.

Compared to recommending:

• Step 1: Disable Secure Boot
• Step 2: Delete the policy files from the EFI System Partition

as the initial approach, manually installing the official FTDI driver through Device Manager is much simpler, safer, and more user-friendly.

 

[Uwe]

I think Uwe's explanation is somewhat misleading—not because it's technically incorrect, but because it omits the simplest solution.

Yes, Ross-Tech modified the original FTDI driver by adding support for their own VID/PID (0403/FA20) in the INF file. As Uwe explains, once the INF is modified, the original WHQL certification is no longer valid. That's absolutely correct.

However, there is no need to modify the INF file just to install the driver. The official FTDI driver package is already Microsoft WHQL-signed and can be installed manually through Device Manager without making any changes to the driver files.

I'm confused. How can this be a solution when the .INF for FTDI's WHQL certified driver package does not include any of the PIDs for our legacy interfaces?

Even so, I wanted to test this, so I dug up an old HEX+CAN (HC474xxx). However, it seems my computer is not a good platform for this test, because that old interface worked just fine without doing anything special at all.



Yes, my computer has a fully up-to-date Windows 11 on it. I suspect it's because the computer started life with Windows 10 on it and was upgraded to Windows 11, and has always had Memory Integrity -> Core Isolation left OFF.



Of course if anyone else wants to test this, we'd be more than happy to hear feedback.

-Uwe-

 

[wh17]

Unless you test this with an actual legacy interface, you don't know whether this really works, you are just assuming it will.

I got for a test a legacy Interface and as i assumed:

The Host itself must support a device whether you use the native OS or not.

If you let it connect to Windows11 -> legacy will fail due to lack of support in the OS itself. If you tunnel is with pass-through the host it will work (if the VM supports the device)

I'm pretty confident that MacOS supports HID devices natively; i.e. it has built-in drivers for HID devices, and current interfaces (HEX-NET and HEX-V2) enumerate as HID devices.

-Uwe-

Well the better idea is to let it connect with pass-through to my VM. In this case, the Hex-Net is not visiable in MacOS but in the VM, the same applies to the legacy interface
If i connect it to the mac and try to use it in a VM it wont work, if i let it connect to a Windows 10 VM it works with pass-through mode.

Hmm currently there is a promotion if you trade in your old device here in germany at PCI (official Distributor). If i would own a legacy interface i would upgrade now.

 

[trv2]

The VID/PID entries in the INF are actually only required for automatic driver matching and installation (for example, via DPInst or by pointing Windows to a driver folder and letting it search automatically).

When installing the driver manually through Device Manager (Update driver → Browse my computer → Let me pick from a list → Have Disk...), Windows does not require the hardware ID to be listed in the INF in order to install the driver. It will warn that the driver may not be intended for the device, but since the FTDI driver itself is Microsoft WHQL-signed, it installs and works correctly.

The only noticeable difference is that Device Manager displays the device name defined in FTDI's INF (for example, USB Serial Converter G) instead of the Ross-Tech-specific name. Functionally, however, the driver works as expected.

If you don't have a legacy HEX+CAN interface available for testing, you can reproduce this with virtually any FT232-based K-Line interface. Simply program its USB IDs to VID 0403 / PID FA20, manually install the original FTDI driver as described above, start VCDS, and press Test. The interface is detected correctly, and VCDS proceeds to "Not plugged into car", demonstrating that the USB communication is working normally.

My hope is that this simple approach—manually installing the original Microsoft WHQL-signed FTDI driver through Device Manager—can finally put the Windows 11 compatibility issue to rest, both for x64 and ARM64 systems, without requiring users to disable Secure Boot, enable Test Mode, or modify the EFI System Partition. It would certainly be the simplest solution for owners of legacy interfaces.

Uwe, in your own test with the HEX+CAN interface, I would encourage you to manually install the original FTDI driver using Update driver → Browse my computer → Let me pick from a list → Have Disk... and select the FTDI INF file.
I'm confident you'll find that the interface works correctly. The only differences are that Device Manager will display the generic FTDI device name (rather than the Ross-Tech-specific one), and the VCDS Test screen will report the FTDI driver's own library versions instead of the versions from the Ross-Tech package:
USB driver: 02.12.36
Other than that, the interface communicates normally.

 

[Sebastian]

Long story short, nice find. It looks like we simply didn't take this approach into account and I can confirm this works as intended. It's not necessarily a layman's approach, but should be manageable for folks who want to keep working with the old generation hardware. We'll likely update the instructions and details once we have done more testing...

 

[Uwe]

Uwe, in your own test with the HEX+CAN interface, I would encourage you to manually install the original FTDI driver using Update driver → Browse my computer → Let me pick from a list → Have Disk... and select the FTDI INF file.
I'm confident you'll find that the interface works correctly. The only differences are that Device Manager will display the generic FTDI device name (rather than the Ross-Tech-specific one), and the VCDS Test screen will report the FTDI driver's own library versions instead of the versions from the Ross-Tech package:
USB driver: 02.12.36
Other than that, the interface communicates normally.

Confirmed, it works!





(That's a 2026 Tiguan, so the "Unsupported vehicle" is fully expected.)

-Uwe-