usbport.sys Non-paged memory leak with Intel 5 Series/3400 Series Chipset Family USB Enhanced Host Controller
While testing a USB device driver, I discovered what appears to be a memory leak in usbport.sys when using certain USB host controller and device/hub configurations.
The problem occurs on computers using the Intel 5 Series/3400 Series Chipset.
Intel(R) 5 Series/3400 Series Chipset Family USB Enhanced Host Controller - 3B34
Intel(R) 5 Series/3400 Series Chipset Family USB Enhanced Host Controller - 3B3C
I'm using Windows 7 64-bit (usbport.sys version is 6.1.7601.17586).
The problem also occurs with the 32-bit version.
A pecularity with the Intel 5 Series/3400 Series Chipset Family USB Enhanced Host Controller (and subsequent chipsets, it seems) is that there is no OHCI/UHCI (USB 1.1 Host Controller) for communicating with Low-speed and Full-speed devices. Instead, for each Enhanced Host Controller, the chipset includes a built-in (virtual) USB 2.0 hub connected to the Root Hub. USB devices inserted into the computer connect to the ports of this "hub". The USB 2.0 hub handles the translation between High-speed and Full/Low-speed.
The memory leak can be seen using poolmon.exe, checking the non-paged pool usage for the "usbp" tag:
poolmon.exe -u -p -iusbp
Starting with both USB Enhanced Host Controllers disabled (in Device Manager), the usbp Nonp usage is 0 bytes.
There are two types of "memory leak" problem I have observed.
In the first type, usbp Nonp memory usage continues to increase, however all of the allocated memory is freed when the Host Controller is disabled (usbp Nonp usage returns to 0).
In the second type, some of the allocated memory is not freed, and the allocation remains even when the Host Controller is disabled.
The first type is easy to reproduce using a generic usb hub (or even the built-in "Generic USB Hub"). If you unplug the usb hub, then re-insert it (or disable / enable the built-in Generic USB Hub using Device Manager), for each iteration, usbp Nonp increases. Disabling the Host Controller, usbp Nonp returns to 0. This problem also occurs with some USB devices.
The second type occurs whenever a bulk-IN transaction with a full-speed device is cancelled (ie, the USB host is continuously sending IN tokens, the USB device is responding with NAK, and the USB driver cancels the transaction (eg, due to timeout, device closed, etc)). Every time a bulk-IN transaction is cancelled, an extra 64 byte allocation of Nonp memory is leaked (in addition to what appears to be a once-off leak of 2 allocations totalling 6800 bytes (for win7_64). When the Host Controller is disabled, usbp Nonp does not return to zero, but shows the leaked allocations.
What is wierd, is that this problem only occurs if the USB device is directly connected to the computer. If it is connected via a USB 2.0 hub, the memory leak does not occur. This makes me think that the problem could be related to the "Generic USB Hub" (specifically, the Transaction Translator) that's built into the Intel 5 Series/3400 Series Chipset.
The problem does not occur on computers with the more traditional EHCI+OHCI arrangement (even if I "re-create" the above situation by plugging in a USB 2.0 hub and disabling all the OHCI controllers).
I initially thought that the method the USB driver uses to cancel the bulk-IN transaction could be in error, however the problem occurs with all USB devices/drivers I have tried:
usbsamp.sys - Sample WDF USB driver from WinDDK (unmodified)
bulkusb.sys - Sample WDM USB driver from previous WinDDK (unmodified)
ser2pl64.sys - In-box USB driver, for "Prolific USB-to-Serial Comm Port" (WHQL passed, I presume)
So the problem appears to be in usbport.sys and/or the Intel 5 Series/3400 Series Chipset. The symptoms seem to point to the built-in usb hub. It's conceivable that this built-in USB hub may behave (in timing, etc) in subtly different ways to a normal usb hub, producing unexpected problems in usbport.sys.
I'm hoping this problem can be addressed such as by:
- Fix / workaround for usbport.sys
- Fix / workaround for Intel 5 Series/3400 Series Chipset
- Or, if anyone can suggest a workaround (eg Registry setting to affect a hotfix)