usbpcap
usbpcap copied to clipboard
desowin
USBPcap renders Windows 10 To go unable to boot
Hello,
I hope you're doing ok. Unfortunately I'm experimenting a huge issue with this driver.
Scenario Macbook Pro, Windows 10 with latest updates is booting via an External USB (Windows 10 to go) After installing Wireshark with usbpcap and performing a reboot, Windows Starts and then simply stops with the windows logo. Seemed that USBpcap rendered unusable the USB ports, and since windows is booting from USB, it simply can't start.
I already deleted the usbpcap folder from program files, deleted the usbpcap.sys and tried to locate the upperfilters regkey in the registry but it's not there (I'm able to boot only to cmd in advanced troubleshooting)
How can I get rid completely of this tool? Since I can't start windows I can only attach this disk to another computer and do whatever its needed via file system only.
What else do I need to do?
Thanks in advance
I managed to solve this issue. Since I was able to boot to command prompt I did the following: Changed location to C: I launched regedit, then select HKEY_LOCAL_MACHINE, right click on it. Click in File -> Load Hive Go to C:\windows\system32\config and select SOFTWARE Put any name you want, it's just to identify it once loaded Click in Edit menu and select Find, type USBPcap, and delete every reference to it Unload the hive Load Hive again but this time select SYSTEM Once loaded, go to CurrentControlSet001\Control\Class{36FC9E60-C465-11CF-8056-444553540000}\UpperFilters Delete the UpperFilters Click in Edit -> Find and delete every reference to USBPcap Unload the hive Exit and shutdown Restart again. Everything will work now
I had the same problem a few weeks ago and fixed it the same way as you did. However, since then Device Manager says "Unknown" instead of USB devices. Do you experience the same problem? Any fix for this?
Sorry for the noise, I seem to have accidentally deleted more keys than just UpperFilters. I could fix it by copying the missing ones from another Windows installation.
The next USBPcap release should notify user that USBPcap cannot be installed on Windows To Go. This is most I can do in the foreseeable future. Such message is implemented in d0bd0199869f2572c5c4e3a89a8440baa307817c
I would imagine that the filter driver would have to "detach" all USB devices and then "reattach them" or let them selves reattach after the driver as loaded. this would cause an issue if booting windows from any kind of a USB device because windows and whatever device it is would need to be able to access the disk and that would not be able to be done..
This is also going to present an issue possibly if a person is running on a tablet. it does not necessarily have to be Windows To Go.. This is going to be a do not use this if your windows installation resides on any kind flash type of storage where the primary or system disks are connected via USB..
I might be wrong in my assessment, but this seems like a valid possibility... I only say this because I ran across a similar issue that took me almost 2 years to figure out what the issue was. but every time I rebooted my PC I would only have keyboard. no other USB device would work until I uninstalled the reinstalled the drivers for the devices. No easy feat to accomplish only using the keyboard. i did finally write a script to do it.. The issue was caused by a filter driver that AMD used on the USB.. it got installed with the drivers for my video card. once I remove the registry entries for the filter driver essentially uninstalling it the problem went away.
This problem might also effect tablet installations that make use of a strange Intel device I saw recently it was a USB device that was kind of like a root hub but wasn't in the same token. I do not remember the symbol name of the GUID for the device class but it had yet another strange thing where there was a Wifi card as a child and also a memory card as a child and the memory card was the "HDD" for the tablet. very strange setup..
I do not know if usbpcap is what disconnects the other devices or if it is windows that would handle that. If it is being done by usbpcap then a recursive lookup of the parents of the system volumes would need to be done to see if it leads back to a usb root hub. and if it does then that device cannot be disconnected. If usbpcap is disconnecting all of the devices at the same time and then reconnecting all of them it might be a better solution to do one at a time.
Again this is all under the assumption that usbpcap is disconnecting and reconnecting if it isn't I do not see how this issue could be resolved.
Again this is all under the assumption that usbpcap is disconnecting and reconnecting if it isn't I do not see how this issue could be resolved.
As far as I understand the USB subsystem in Windows, USBPcapDriver does not do any disconnecting/reconnecting.
The biggest potential issue with changing USBPcap to not be a filter driver is how to obtain the endpoint mapping. Currently USBPcap always monitors all USB IRPs, and if it sees _URB_SELECT_INTERFACE then it updates endpoint table (see USBPcapParseInterfaceInformation for details). As USBPcap is present in {36FC9E60-C465-11CF-8056-444553540000} UpperFilters, USBPcap has a chance to peek at every's USB device _URB_SELECT_INTERFACE.
then what would cause it to not allow a boot to take place from a USB drive? maybe this should be tested with other releases of windows using an external HDD, and an SD card. I can't imagine there being anything different in the boot process between the versions other then what it is using as a system drive. I know that the USB drivers are one of the first things to get loaded by Windows. I do not know to what extent tho. If you want to install windows from USB stick using USB 3.0 you would need to slipstream the installation package so it would load the drivers into the installation program. there is another way to do it is to plug the stick into a usb2.0 get to the point of creating the partitions for the OS and you can use that driver install for SCSI drivers to install the USB drivers.. then move the stick to the other port when that is done and windows will continue the rest of the installation using 3.0 having to do this may not exist in windows 10. IDK I am not a fan of windows 10. Because Windows can be installed and boot from a USB device those drivers have to be loaded right at the beginning of the boot process. If usbpcap only listens to the information on the bus then it should not be causing an issue.. Now I do have a dumb question on this.. what is the requirement for it being a filter driver? can't it be created as a "fake" device that is plugged into the USB???. if all you are doing is putting an ear to the track so to speak then you should be able to create a fake device that does nothing, this would give you the ability to listen..
I had thought that possibly usbpcap took the role of man in the middle so to speak in order to capture the data. I know nothing of USB and how the information flows over the bus.. I envision it to have the same basic idea as how RS485 works. but the requirement of a reboot after install threw me for a loop.. if only attaching to listen and not interrupting the chain of communications at all you should be able to install the drivers for usbpcap just like any other usb device.. I have never had to reboot my computer for plugging in a USB stick.. or a web cameras, keyboard or anything else like that.... I think that npcap is a man in the middle kind of a thing where it gets it's self between the hardware and windows.. being the man in the middle would force the need for a reboot after installation.
this may be the way windows is designed as well in order for you to be able to get access to all of the _URB_SELECT_INTERFACE messages for the other devices..
Here is a thought, Take this as an example and I could see it being a potential issue if coded this way.... when does usbpcap start to build a table from the _URB_SELECT_INTERFACE messages?? does it do it as soon as the driver loads?? or does it do it upon request???... If it does it at driver load time there could be some kind of security issue causing it to hang. you would not get any kind of an error because those services have not loaded yet... write the driver in a manner so that it will only do the things needed to satisfy the requirements of being an installed and functional driver.. and not a thing more until either after windows is completely loaded or until a request for the information is made. That is the only thing I think could cause an issue... when this table is built where is it stored?
maybe someone with this problem would be willing to boot the thing up in debugging mode to see if it is getting stuck at the usbpcap driver load or not.. It could be something else acting goofy because of usbpcap, the boot freezing may not be directly caused by usbpcap (seen this kind of thing happen as well).. trying to toss some ideas out there that could spark a thought as to where the issue is..
after usbpcap gets the _URB_SELECT_INTERFACE message does it then query for any other information? if it does and it performs these operations at driver load time is there a need to have it done then?