there are three root hubs in my PC (one of them USB3.0 but I guess that's not relevant as the issue has been there before I've asked USBPcap to identify the USB3.0 hub).
When I run USBPcapCMD.exe from the command line and capture on a root hub with no traffic, one instance of USBPcapCMD.exe is running and the task manager window says it takes 0 % of CPU (so below 0.05 % actual load).
When I run USBPcapCMD.exe from Wireshark on the same root hub, three instances of USBPcapCMD.exe are spawned, and each of them takes about 29 % of CPU. At the same time, Wireshark processes (Wireshark itself and dumpcap) show 0 % of CPU.
My suspicion (and not more than that) is that in extcap mode, the process checks whether it is possible to write to the output named pipe all the time. It comes from the fact that the same binary, if writing the same output data to a file rather than to a named pipe, behaves in a decent way.
Hello,
there are three root hubs in my PC (one of them USB3.0 but I guess that's not relevant as the issue has been there before I've asked USBPcap to identify the USB3.0 hub).
When I run USBPcapCMD.exe from the command line and capture on a root hub with no traffic, one instance of USBPcapCMD.exe is running and the task manager window says it takes 0 % of CPU (so below 0.05 % actual load).
When I run USBPcapCMD.exe from Wireshark on the same root hub, three instances of USBPcapCMD.exe are spawned, and each of them takes about 29 % of CPU. At the same time, Wireshark processes (Wireshark itself and dumpcap) show 0 % of CPU.
My suspicion (and not more than that) is that in extcap mode, the process checks whether it is possible to write to the output named pipe all the time. It comes from the fact that the same binary, if writing the same output data to a file rather than to a named pipe, behaves in a decent way.
Other users seem to have a similar experience, see the related question at the Wireshark Q&A site.