There are a lot of threads here about monitoring usb bandwidth, however none of them helped me, so that I post my problem here (device manager doesn't show me the usb bandwidth...):

I have a Lenovo notebook with Win10 on which I use an external USB3 camera. As long as the notebook's power cable is plugged, everything works smooth, but when removing it, the usb starts to loose data packets and frames massively. Enabling max performance in Windows power management settings hepls. However, when playing around with power settings I realized that its no usb setting (like suspend mode etc.) causing the errors, its settings of the wireless adapter. If I apply any power saving mode to the wireless adapter, my usb looses data packets. Same is true for switching off wlan, then immediately the usb looses data packets. Weird, isn't it?

My speculation is that usb controller and wifi share same recources, data bus, whatever, so that switching off wifi limits somehow usb controller bandwidth. I like therfore to monitor the current usb bandwidth. But how can I do? Is there any powershell command? Alternatively, it seems to be possible to get usb bandwidth using WinAPI, but therfore you have to dive deep into implementing Microsoft functions to your C++ source code...

Any help is welcome!

  • What computer (COU, chipset, ..) are you talking about? USB problems you describe often are cause by the CPU sleeping too often (or too deep). Make sure you have the latest BIOS/firmware installed.
    – Robert
    May 13, 2021 at 13:51
  • It's a lenovo thinkpad with i3 processor. Where do I see more detailed info about the chipset? However, processor idle states aren't the reason. I have written a small c++ code using winapi to monitor idle states every 5 s... The processor cores almost never go idle even in battery saving mode... May 13, 2021 at 14:01
  • You can use e.g. cpu-z. Regarding the CPU sleep I think the situation is way more complex as you think. Unless you have your CPU always running at 100% a typical CPU in an office PC spends 95% of the time in one of the sleep states (C1-C7).
    – Robert
    May 13, 2021 at 14:05
  • 1
    If you want to monitor idle states you might be better off looking at HWiNFO which has a "sensors" mode that can show package idle states and give a measurement "over time" rather than the instant your program checks it which may not give a true indication. For example my computer when idle shows very high (>70%) idle state occupancy: i.stack.imgur.com/XU5DX.png Note that there is also a big distinction between package and core idle states.
    – Mokubai
    May 13, 2021 at 14:06
  • There does appear to be a performance counter for the USB system which looks like it includes bandwith and bytes per transfer statistics, but either it is not available on my system, requires a newer version of powershell, or simply isn't accessible... wutils.com/wmi/root/cimv2/win32_perfformatteddata_usbhub_usb
    – Mokubai
    May 13, 2021 at 14:20

1 Answer 1


After a lot of good comments to my question I was able to dive deeper into the problem and here is the conclusion: First I downloaded HWiNFO and monitored the idle states of my processors. HWiNFO offers an option to record performance, which I did for a couple of minutes while my software capturing usb camera data was running with

  1. first 3 minutes: Plugged power cable, wifi active and in no power saving mode -> no errors (no lost usb packets)
  2. next 3 minutes: Power cable unplugged, wifi active but power saving (this is default setting in windows balanced mode when running on battery) -> errors
  3. next 3 minutes: Power cable off, wifi active and set to max performance in power options -> no errors
  4. Switching wifi off (in the taskbar) -> errors

The corresponding idle states of processors and packages are displayed below:

idle states using own software

The 4 periods explained above can be clearly seen, especially in the top subplot (package idle mode). Obviously it is true and the frequency of erros (lost usb packets) is related to the time the processor spends in an idle state: The larger the percentage of time in an idle state, the more usb lost packets (or vice versa, the larger the time in C0, the less errors).

I assume my observation of loosing usb data from the attached camera when wireless adapter is switched off or saves power is just because the processor sleeps much more often when you switch off wifi or try to save power here. However, it would be helpful if some experienced user could confirm that?

However, this does explain but not solve my problem, so I continued:

I have a vendor software (basically the software which came with the camera), which is not loosing any usb data, independent of any plugged or unplugged power cables or power saving modes. This is in strong contrast to my own software I am wirting in C++ (which has the explained problems).

I repeated my test above with the vendor software. The result is not shown here, but with the vendor software the packages never go idle and thus no usb data is lost. Interesting is the following chart, where I stopped and restarted the usb camera many times in the vendor software while recording idle states with HWiNFO: Idle states while stopping and starting usb camera with vendor software

It is very clear to see that no packages ever go idle when starting the usb camera in the vendor software. When stopping it, idle states start again.

Conclusion: My original mystery is solved (idle states are the reason for lost usb packets), but the problem remains. However, it must be possible to prevent the processor (or packages) to go idle in a programmatical way, meaning I need some command that my c++ program can execute, maybe also a compiler directive to tell the processsor "don't go idle". Something like this must exist, because the vendor software seems to do that. So I am not closing the question for now but need to ask for further expert help.

  • Update: I disabled CPU power saving (idle states) in BIOS, which solved my problem (no lost data or frame from my usb cam for hours!). So the problem was really related to idle states. May 15, 2021 at 23:50
  • Unfortunately this helps only for the computer on which I have access to BIOS settings. As mentioned, I like a programmatical solution, and I'm 100% sure this exists, because the vendor software seems to do that. I posted a question about that, which was unfortunately closed (off topic) and I was asked to post that question on stackoverflow, where they closed my question immediately as well (off-topic)... So any help is still welcome, at least where an appropriate forum (not off-topic) for this question is... May 15, 2021 at 23:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .