First, some more insight: The Linux rndis gadget function has USB class of 2 and subclass of 2, which matches "USB\Class_02&SubClass_02" in the usbser.inf file. This is why for some people, their device is initially detected as a COM port instead of RNDIS. Solution 1: If you are one of the people that found this because your device is showing up as a COM port instead of RNDIS, you may be able to get away using the RNDIS 5.1 driver. Find your device under Ports (COM & LTP) in Device Manager. Right-click it and select Update Driver Software..., then Browse my computer for driver software and then Let me pick from a list of device drivers on my computer and finally choose Remote NDIS Compatible Device. This should install the Microsoft RNDIS 5.1 driver (shows "Acer" as the manufacturer). If this works great. If it causes Network and Settings and other network related things to lock up, then you need the RNDIS 6.0 driver instead. Try one of the other solutions. Solution 2: If you have control over the RNDIS device and it runs Linux (i.e. BeagleBone), you can tweak the driver to get along with Windows better. For example, if you have a 3.16 kernel or newer, you can setup your gadget using configfs and include os descriptors. This is actually what I ended up doing for my case. You can find my fully documented script here. The key was specifying the compatible and subcompatible ids so that it matches "USB\MS_COMP_RNDIS&MS_SUBCOMP_5162001" in rndiscmp.inf. This causes the Microsoft RNDIS 6.0 driver to be installed for this device. With this driver, I have not seen the same lockup as I have with the 5.1 (Acer) driver. I also changed the vendor and product ids so that it wouldn't match the "Acer" driver. Solution 3: If the RNDIS 5.1 (Acer) driver is causing problems and you can't modify the remote device, then you can reboot into a mode that allows you to install unsigned drivers. The you can install this unsigned linux.inf file. However, if you reboot without enabling unsigned drivers again, Windows will not load the driver anymore. For a more permanent solution, you could self-sign that .inf file. Solution 4: This one is for Microsoft (and better than the suggestion below)... Add "USB\Class_02&SubClass_02&Prot_FF" to rndiscmp.inf. ORIGINAL MESSAGE: Here is the workaround that I came up with for my particular case. Assuming your device has the same USB Vendor and Product ID's it should work for you. If not, you can modify the .inf file (see link) accordingly. http://www.ev3dev.org/docs/tutorials/connecting-to-the-internet-via-usb/?os=Windows&os-version=10 It would be really nice if Microsoft could make it so that rndiscmp.inf shows up as compatible with USB\VID_0525&PID_a4a2.