Device Drivers Generic Rndis Usb
Etas Vci Usb Rndis Device now has a special edition for these Windows versions: Windows 7, Windows 7 64 bit, Windows 7 32 bit, Windows 10, Windows 10 64 bit, Windows 10 32 bit, Windows 8,Windows 10 Pro 64bit, Windows 10 Team 32bit, Windows Vista Home Basic 32bit, Windows Vista Home Premium 64bit, Windows 8 32bit, Windows 8 Enterprise 64bit, Windows 7 Enterprise (Microsoft Windows NT) 64bit, Windows 10 Mobile Enterprise 64bit, Windows 10 Home 64bit, Windows 7 Home Premium 32bit, Windows Vista Starter 64bit, Windows 8 Pro 32bit, Windows 7 Home Basic 32bit, Windows 7 Starter 32bit.
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 on MSDN.
The problem is that Windows 10 has a new default driver which is installed for USBClass02&SubClass02 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!Environment:WCE 7 1.4.
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:WINCE700publicCOMMONoakdriversUsbFnclassrndisrndisfnrndisfn.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 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.
Generic Rndis Htc
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 'USBMSCOMPRNDIS&MSSUBCOMP5162001' in rndiscmp.inf'. That's what makes me think that a solution could be changing the setup on the T20 so that it reports MSCOMPRNDIS for the USB class instead of 02.
But I don't know how to change the USB class on the T20. 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.
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.
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:WindowsInf 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.
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 wantI 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.
Device Drivers Generic Rndis Usb Windows 10
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.