RNDIS on Windows 10 to connect to CE7 running on T20

I have been using the RNDIS feature of the USB port to allow my customers to connect to my PXA and T20 based systems for several years and it has been working very well. But I have run into problems when trying to support users of Windows 10.

The first problem was that Windows 10 will not allow unsigned drivers to be installed. I have solved that by buying a code signing certificate and using it to generate a signed .cat file from my .inf file.

The second problem is that Windows 10 thinks my product is a USB serial port when I first connect it and it loads the wrong driver. I can then click on the device in the device manager and browse to the correct driver and everything then works correctly. But I can’t have my customers go through a manual process like that.

The problem is described here on MSDN. The problem is that Windows 10 has a new default driver which is installed for USB\Class_02&SubClass_02 and the RNDIS interface of the T20 matches that class and subclass, so Windows 10 loads the USB serial port driver instead of the RNDIS driver.

I think a potential solution would be for the T20 to report a different subclass than 02 in order to force the PnP manager to search for a driver based on the USB PID and VID. I though the USB class and subclass might be specified in the T20 registry, but I can’t find them.

Has anyone else made the RNDIS feature work with Windows 10? I feel that I am very close, but I am also stuck!

I do already use a custom VID and PID for my product, and I set those in the registry. The problem seems to be that Windows 10 is using the USB class and subclass to load a standard driver before it looks at the VID and PID. I don’t use Platform Builder, I just use the standard Toradex image.

I found another web page which describes the Windows 10 problem for a different device here. About two thirds of the way down that page is a paragraph containing this, “The key was specifying the compatible and subcompatible ids so that it matches “USB\MS_COMP_RNDIS&MS_SUBCOMP_5162001” in rndiscmp.inf”. That’s what makes me think that a solution could be changing the setup on the T20 so that it reports MS_COMP_RNDIS for the USB class instead of 02. But I don’t know how to change the USB class on the T20.

Here is another useful link from Microsoft. This suggests than an RNDIS device should use USB class 2 and subclass 0. But the T20 uses class 2 and subclass 2, which matches the serial port driver that Windows 10 is loading. If we could change the subclass from 2 to 0 in the T20 image then I think we might solve this problem.

Here’s a quote from the link in my first post to MSDN which supports the comment I just made about changing the subclass from 2 to 0:

If you want to load Usbser.sys automatically, set the class code to 02 and subclass code to 02 in the Device Descriptor. For more information, see USB communications device class (or USB CDC) Specification found on the USB DWG website. With this approach, you are not required to distribute INF files for your device because the system uses Usbser.inf.

If your device specifies class code 02 but a subclass code value other than 02, Usbser.sys does not load automatically. Pnp Manager tries to find a driver. If a suitable driver is not found, the device might not have a driver loaded. In this case, you might have to load your own driver or write an INF that references another in-box driver.

Ok, we would have to rewrite the RNDIS FN driver for that.

Do you have platformbuilder, to quickly give it a try if it works with changing the subclass ID? You have to add an other condition in the function ReadConfigurationValues where SetClassIds is called. Unfortunately these values are hardcoded there as defines currently and can not be modified by registry change.

I don’t have Platform Builder. I have tried to avoid using that with Toradex products by using the standard images instead. I do have some limited experience with using PB with other vendors hardware from years ago though. I will attempt to download and install PB in order to do this experiment. If the experiment is successful then would you make this change in the next T20 image so that I can go back to using a standard image in the future? That would also solve this problem for everyone else.

You could also save me some time by making this change in PB for me as you probably already have PB installed and configured on your PC. You could then simply send me the image file for me to test.

@MikeS: Please have a look at this patched RNDIS driver. It is a debug build. To use it, you have to put it into \FlashDisk\System folder and change the DLL names in the registry at:

[HKEY_LOCAL_MACHINE\Drivers\USB\FunctionDrivers\RNDIS]
[HKEY_LOCAL_MACHINE\Comm\RndisFn]

If this works, we can make a proper solution an put it into the image, please let us know.

@samuel.tx, thanks for making that patched DLL for me to test. I did also download and install Platform Builder and used it to build the Toradex image 1.4. I also found the line of code in rndisfn.cpp that looked like it needed to be changed to change the USB subclass. But I realized that building an OS image is not the same as building that DLL so it saved me quite a bit of time to use your DLL instead.

The patched DLL worked as expected in that the Subclass changed from 2 to 0. This stopped Windows 10 from loading the virtual COM port driver as we hoped, but Windows 10 still did not load my driver instead. I learned that the reason for that is the technique I have been using for a long time of putting .inf files into C:\Windows\Inf so that Windows can find. This technique no longer works on Windows 10. I have to actually install the driver into the the Windows Driver Store using the API call DiDriverInstall(). If I install the driver this way then Windows 10 finds it when I plug in my USB cable and everything works correctly.

This discovery made me wonder if using DiDriverInstall() would have worked with the unpatched driver as well. It turned out that it did. By installing a signed driver I made Windows 10 use my driver to match my VID and PID instead of using the class driver for class 2 and subclass 2. That means that my driver now works with the standard Toradex image and you do not need to patch it. My new driver works with Windows 10, Windows 7 and Windows XP. Some of my customers still use XP. It probably works with Windows 8 as well but I didn’t have a Windows 8 PC available to test it.

This is a good outcome as it means that I do not need to update the OS image in the products I have already shipped, I just need to update my Windows code to install the driver correctly. Thanks for helping me to figure this out.

@samuel.tx, that is a great idea! Using the correct USB Class and Subclass settings to specify RNDIS has multiple advantages:

  • It adds support for Windows 10
  • I no longer need to distribute .inf files with my products (Or sign them)
  • I don’t need to install the drivers along with my Windows app
  • It uses RNDIS 6 on Windows 7 and 10, while using RNDIS 5.1 on Windows XP
  • Customers can access my device without installing any of my software if they want

I tested this on Windows XP, 7 and 10 and it worked on each of them. One minor difference with Windows 10 is that the device name appears in the Device Manager as “Remote NDIS Compatible Device” while in Windows 7 and XP it is shown with the product name that I specified in the T20 registry. This is not a show stopper, just a cosmetic concern.

I am going to deploy that DLL with my product in order to add Windows 10 support. I think you should include this change in the standard Toradex image when you get a chance, and I will then stop deploying the patched DLL and use the one built into the image instead. I think you should make this change for all of your modules, not just the T20, as this seems to be the right way to implement RNDIS and everyone should benefit from this change - especially as Windows 10 becomes more popular.

We have added issue 18765 to the roadmap. It will appear there as soon as it was reviewed internally.

To workaround issues with RNDIS on Windows 10 you have to change the default USB identifier to the following setting:

  • Class: 0xEF
  • Subclass: 0x04
  • Protocol: 0x01

A modified driver can be downloaded from here.


We have created two new issues to our roadmap to fix this in our default image:

  • Fix RNDIS function driver: Issue 18765 (fixed in image 2.0b3.
  • Fix RNDIS driver used for platform debugging: Issue 18716 (fixed in image 2.0b2)

Thanks to user @MikeS helping solving that issue.

@MikeS: We also made some more investigations and may be found a easier solution: If you set the following config you not even need to sign your driver and the default RNDIS driver will be used:

Class: 0xEF
Subclass: 0x04
Protocol: 0x01

If you want to test this driver, you can download it from here. Rename it and change the registry as described previous comment in this issue.

@kwebster83: Did you tried with the patched driver linked in the answer (https://share.toradex.com/8wk410my2g11rwm?direct)? I think with this you not even have to reboot in advanced mode. Please give it a try. You can replace the driver in the registry by putting the downloaded driver into \FlashDisk\System, rename it and as well rename the driver in the registry itself. The driver was built for CE 7.

@samuel.tx - I’m running a custom Linux build on the Apalis T30, not WinCE.

Done. Sorry, didn’t mean to hijack the post but wondered if there was a similar simple answer.

@kwebster83: Would you mind creating a new question an reference to the proper class settings to this issue. Tag the question with “linux”, so the you will get some answers from a Linux engineer or community member.

We have facing the same issue. Internally we use RNDIS for Platform Debugging and have some issues there as well. I quickly checked the driver source.

The Class ID is set programmatically in the RDNIS driver. If you have platform builder, check the file Drive:\WINCE700\public\COMMON\oak\drivers\UsbFn\class\rndis\rndisfn\rndisfn.cpp. What you can change is the productId or the VendorId. Changing that, you should already be able to force Windows 10 to use the custom driver, shouldn’t it?

Note: We have additional issues with RNDIS freezing the whole Windows 10 (was also the case in Windows 8): In case you are doing platform debugging and the target system hangs, after about 10 seconds also Windows 10 will hang and reboot. We have not been able to fix this. Not sure this also affects you in case you use RNDIS as function driver in the OS itself.

I’ve also run into a similar issue with the Apalis T30 using RNDIS on Windows 10. It is not feasible to ask our customers to restart Windows 10 in advanced startup mode in order to temporarily disable the signed driver feature. As per the comments above, is it easy to change the USB class and Subclass settings for Linux?

I can get Windows to auto-install RNDIS driver.

Yes, it’s been working well for me too since 2016. It’s probably working for you now because you are using an image that includes the fix that we made back in 2016. I have found that it doesn’t work on all PCs though for some reason though.