USBCap freezes Wireshark on launch in Win10

[iansebryk]

Wireshark flat out won't launch with USBCap installed. using latest version of both (2.6 & 1.2). when i looked at the process in ProcExp64, i noted that the path to USBCap has double slashes in the path (see screenshot). don't know what that means but USBCap flat out kills it. after removal, wireshark loads just fine. this is nae good.

which means all my external cap devices are useless. Win10 just sucks... ;(

[desowin]

I am not able to reproduce this issue neither on my home laptop running Windows 10 Home nor on my work laptop running Windows 10 Enterprise.

Could you please try executing: C:\Program Files\Wireshark\extcap\USBPcapCMD.exe --extcap-config --extcap-interface \\.\USBPcap1 from the cmd window and check if it prints anything?

[iansebryk]

C:\Program Files\Wireshark\extcap>USBPcapCMD.exe --extcap-config --extcap-interface . \USBPcap1

C:\Program Files\Wireshark\extcap>arg {number=0}{call=--snaplen}{display=Snapshot length}{tooltip=Snapshot length}{type=integer}{range=0,65535}{default=65535}
arg {number=1}{call=--bufferlen}{display=Capture buffer length}{tooltip=USBPcap kernel-mode capture buffer length in bytes}{type=integer}{range=0,134217728}{default=1048576}
arg {number=2}{call=--capture-from-all-devices}{display=Capture from all devices connected}{tooltip=Capture from all devices connected despite other options}{type=boolflag}{default=true}
arg {number=3}{call=--capture-from-new-devices}{display=Capture from newly connected devices}{tooltip=Automatically start capture on all newly connected devices}{type=boolflag}{default=true}
arg {number=99}{call=--devices}{display=Attached USB Devices}{tooltip=Select individual devices to capture from}{type=multicheck}
Couldn't open device - 5

hope this helps.

[desowin]

@iansebryk and once it prints the "Couldn't open device - 5" (which is Access Denied) it does fall into endless loop? If yes, then atleast the endless loop itself can be fixed (not sure if it would be possible to actually list all the devices). I think, even if USBPcap wouldn't list the devices, but would allow other Wireshark functions to operate correctly, it would be much better than current situation.

[desowin]

@iansebryk Could you please check if the latest USBPcapCMD build from AppVeyor is no longer causing Wireshark freeze on your computer?

[daulis]

Related Wireshark bug is here: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14657

[daulis]

If this is the same issue as the Wireshark bug, then users have also seen this on Windows 8.1 and I believe Windows 7.

[desowin]

This should be fixed in USBPcap 1.2.0.4 - this issue will get closed once I receive positive feedback from someone who experienced this problem with earlier USBPcap release.

[fabianbuettner]

I just tested it with USBPcap 1.2.0.4 and at least for me this issue is not fixed.
I still get the "Couldn't open device - 5" error:

PS C:\Program Files\Wireshark\extcap> .\USBPcapCMD.exe --extcap-config --extcap-interface . \USBPcap1
PS C:\Program Files\Wireshark\extcap> arg {number=0}{call=--snaplen}{display=Snapshot length}{tooltip=Snapshot length}{type=integer}{range=0,65535}{default=65535}
arg {number=1}{call=--bufferlen}{display=Capture buffer length}{tooltip=USBPcap kernel-mode capture buffer length in bytes}{type=integer}{range=0,134217728}{default=1048576}
arg {number=2}{call=--capture-from-all-devices}{display=Capture from all devices connected}{tooltip=Capture from all devices connected despite other options}{type=boolflag}{default=true}
arg {number=3}{call=--capture-from-new-devices}{display=Capture from newly connected devices}{tooltip=Automatically start capture on all newly connected devices}{type=boolflag}{default=true}
arg {number=99}{call=--devices}{display=Attached USB Devices}{tooltip=Select individual devices to capture from}{type=multicheck}
Couldn't open device - 5

EDIT: Just saw that USBPcapCMD in C:\Program Files\Wireshark\extcap was from 2017, so I replaced it with the version from the USBPcap directory but still the same error message ...

[desowin]

Error 5 is Access Denied. This can happen if another USBPcapCMD instance has opened the USBPcap1.

Did you write the interface properly as \\.\USBPcap1? It is really important that this starts with two backslashes, followed by a dot, and then another single backslash and finally "USBPcap1" (or whatever number, depending how many root hubs there are).

So the command is: USBPcapCMD.exe --extcap-config --extcap-interface \\.\USBPcap1

Does the interactive (without parameters) version of USBPcapCMD show the devices? Does it still freeze wireshark?

[fabianbuettner]

Wireshark was frozen so I killed it via windows task manager. So I think the interface was not open anymore.
I think I copied the command line from @iansebryk's comment. I'll check it at work tomorrow.

[desowin]

When the USBPcapCMD freezes can you attach to it from a debugger and check where does it loop? In Visual Studio it can be done using Attach To Process option. The pdb file is in the usbpcap release source 7z archive.

[desowin]

If you are unable to launch debugger, could you please send me (eg. via email) the user mode dump file of the frozen USBPcapCMD? This can be created using Windows builtin task manager.

[fabianbuettner]

I will have to check If there is a visual studio license I can use, I am doing embedded development ...
The user mode dump I think I will be able to provide tomorrow

[fabianbuettner]

so it turns out, you were correct. I didn't use the correct interface name.

PS C:\Program Files\Wireshark\extcap> .\USBPcapCMD.exe --extcap-config --extcap-interface \\.\USBPcap1

PS C:\Program Files\Wireshark\extcap> arg {number=0}{call=--snaplen}{display=Snapshot length}{tooltip=Snapshot length}{type=integer}{range=0,65535}{default=65535}
arg {number=1}{call=--bufferlen}{display=Capture buffer length}{tooltip=USBPcap kernel-mode capture buffer length in bytes}{type=integer}{range=0,134217728}{default=1048576}
arg {number=2}{call=--capture-from-all-devices}{display=Capture from all devices connected}{tooltip=Capture from all devices connected despite other options}{type=boolflag}{default=true}
arg {number=3}{call=--capture-from-new-devices}{display=Capture from newly connected devices}{tooltip=Automatically start capture on all newly connected devices}{type=boolflag}{default=true}
arg {number=99}{call=--devices}{display=Attached USB Devices}{tooltip=Select individual devices to capture from}{type=multicheck}
value {arg=99}{value=2}{display=[2] USB-Eingabegerät}{enabled=true}
value {arg=99}{value=2_1}{display=HID-konformes, vom Hersteller definiertes Gerät}{enabled=false}{parent=2}
value {arg=99}{value=5}{display=[5] Generischer USB-Hub}{enabled=true}
value {arg=99}{value=4}{display=[4] Generischer USB-Hub}{enabled=true}
value {arg=99}{value=7}{display=[7] USB-Verbundgerät}{enabled=true}{parent=4}
value {arg=99}{value=7_1}{display=Razer Electra V2 USB}{enabled=false}{parent=7}
value {arg=99}{value=7_2}{display=Kopfh├Ârer (Razer Electra V2 USB)}{enabled=false}{parent=7_1}
value {arg=99}{value=7_3}{display=Kopfh├Ârermikrofon (Razer Electra V2 USB)}{enabled=false}{parent=7_1}
value {arg=99}{value=7_4}{display=USB-Eingabegerät}{enabled=false}{parent=7}
value {arg=99}{value=7_5}{display=HID-konformes Benutzersteuergerät}{enabled=false}{parent=7_4}
value {arg=99}{value=7_6}{display=HID-konformes Headset}{enabled=false}{parent=7_4}
value {arg=99}{value=8}{display=[8] USB-Verbundgerät}{enabled=true}{parent=4}
value {arg=99}{value=8_1}{display=USB-Eingabegerät}{enabled=false}{parent=8}
value {arg=99}{value=8_2}{display=HID-Tastatur}{enabled=false}{parent=8_1}
value {arg=99}{value=8_3}{display=USB-Eingabegerät}{enabled=false}{parent=8}
value {arg=99}{value=8_4}{display=HID-konforme Maus}{enabled=false}{parent=8_3}
value {arg=99}{value=8_5}{display=HID-konformes Benutzersteuergerät}{enabled=false}{parent=8_3}
value {arg=99}{value=8_6}{display=HID-konformer Systemcontroller}{enabled=false}{parent=8_3}
value {arg=99}{value=8_7}{display=HID-konformes, vom Hersteller definiertes Gerät}{enabled=false}{parent=8_3}
value {arg=99}{value=8_8}{display=HID-konformes, vom Hersteller definiertes Gerät}{enabled=false}{parent=8_3}
value {arg=99}{value=9}{display=[9] USB-Verbundgerät}{enabled=true}{parent=4}
value {arg=99}{value=9_1}{display=Logitech USB Input Device}{enabled=false}{parent=9}
value {arg=99}{value=9_2}{display=HID-Tastatur}{enabled=false}{parent=9_1}
value {arg=99}{value=9_3}{display=USB-Eingabegerät}{enabled=false}{parent=9}
value {arg=99}{value=9_4}{display=HID-konforme Maus}{enabled=false}{parent=9_3}
value {arg=99}{value=9_5}{display=HID-konformes Benutzersteuergerät}{enabled=false}{parent=9_3}
value {arg=99}{value=9_6}{display=HID-konformer Systemcontroller}{enabled=false}{parent=9_3}
value {arg=99}{value=9_7}{display=HID-konformes, vom Hersteller definiertes Gerät}{enabled=false}{parent=9_3}
value {arg=99}{value=9_8}{display=USB-Eingabegerät}{enabled=false}{parent=9}
value {arg=99}{value=9_9}{display=HID-konformes, vom Hersteller definiertes Gerät}{enabled=false}{parent=9_8}
value {arg=99}{value=9_10}{display=HID-konformes, vom Hersteller definiertes Gerät}{enabled=false}{parent=9_8}
value {arg=99}{value=9_11}{display=HID-konformes, vom Hersteller definiertes Gerät}{enabled=false}{parent=9_8}
value {arg=99}{value=6}{display=[6] EgisTec ES603 Swipe Fingerprint Sensor}{enabled=true}
value {arg=99}{value=3}{display=[3] Intel(R) Wireless Bluetooth(R)}{enabled=true}
value {arg=99}{value=3_1}{display=Microsoft Bluetooth LE-Enumerator}{enabled=false}{parent=3}
value {arg=99}{value=3_2}{display=Bluetooth Device (RFCOMM Protocol TDI)}{enabled=false}{parent=3}
value {arg=99}{value=3_3}{display=Microsoft Bluetooth-Auflistung}{enabled=false}{parent=3}
value {arg=99}{value=3_4}{display=Bluetooth Device (Personal Area Network)}{enabled=false}{parent=3}
value {arg=99}{value=10}{display=[10] USB-Verbundgerät}{enabled=true}
value {arg=99}{value=10_1}{display=Chicony USB 2.0 Camera}{enabled=false}{parent=10}
value {arg=99}{value=1}{display=[1] Generischer Hochgeschwindigkeits-USB-Hub (SuperSpeed)}{enabled=true}

EDIT: gnaah github seems to replace those \\ by \

[desowin]

Did the USBPcapCMD process freeze or exit (check if there is USBPcapCMD.exe visible in task manager)? The output looks just fine.

If this USBPcapCMD.exe (when used as extcap) still freezes Wireshark on startup, please start Wireshark, wait for the freeze, wait reasonable amount of time (eg. 2 minutes), then create process dump (in Task Manager) and email me the file.

[fabianbuettner]

Yes, USBPcapCMD.exe was visible in task manager when it had frozen this morning.
I already emailed you with a link to the dump.

[desowin]

So far the most plausible explanation is https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14657#c16 which means that it might not be a bug in USBPcapCMD after all.

[fabianbuettner]

Ok, that comment of yours there makes sense.

[desowin]

This problem should be fixed in Wireshark 2.6.3. Can anyone of the people who experienced this issue confirm that it is fixed?

[davidva-ecco]

Unfortunately I am still experiencing this issue. Wireshark hangs for some time (order of minutes) on "Initializing external capture plugins," then finally starts up but becomes unresponsive if I try to capture on the USB interface or configure its settings. If I remove USBPcapCMD.exe from the extcap directory, Wireshark starts up as I would expect (minus the USB interfaces of course).

I am running:

• Windows 10 Enterprise 64-bit, Version 1709
• Wireshark 2.6.3
• USBPcap that is installed via the Wireshark installer (version 1.2.0.4)

The Task Manager shows no CPU cycles for USBPcapCMD.exe or Wireshark while it is stalled on start. Running the command in PowerShell stated above (.\USBPcapCMD.exe --extcap-config --extcap-interface \\.\USBPcap1) works a bit, but seems to crash at some point as I don't get back to the command prompt and there is no USBPcap process in the Task Manager, and the PowerShell process isn't consuming any CPU cycles.

I tried unplugging as many USB devices as I could and disabling Bluetooth to reduce the length of the output from the command line, but no luck. In both cases the last device listed before crash was:

value {arg=99}{value=17}{display=[17] Generic SuperSpeed USB Hub}{enabled=true}

Any suggestions?

[davidva-ecco]

I realized I never tried running Wireshark after unplugging extra USB devices and disabling Bluetooth, and sure enough that fixed the issue and it runs properly now. So maybe there is still some issue related to the bug linked earlier (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14657#c16). It seems like too many devices (docks, hubs, etc) causes USBPcap to have a bad time on Windows.

[desowin]

What do you mean by don't get back to command prompt? Note that USBPcapCMD is really a "gui application" simply to make it not open a window when you execute it from oher processes. This has downside that when you run it from command prompt, it'll still print to the command prompt window but that'll appear after the next prompt. In other words, simply press enter in the powershell and it should work just fine. As long as the process is no longer running and exit code was 0, everyhing is ok and there was no crash. The extcap commands are not really intended to be run from command prompt so it is how it works - note that the ineractive cmd window opens if you run USBPcapCMD from shell wihout any parameter.

See https://stackoverflow.com/questions/10262231/obtaining-exitcode-using-start-process-and-waitforexit-instead-of-wait
for a analogy how to execute gui process (notepad) and check its exit code. Please use the same to check USBPcapCMD exit code.

Can you try redirecting outputs of all usbpcap interface(s) to a file(s) and attaching that here? Ideally with the full set that causes freezing and the limited set.

[fabianbuettner]

This problem should be fixed in Wireshark 2.6.3. Can anyone of the people who experienced this issue confirm that it is fixed?

Sorry for the late reply, I was on vacations ...

For me it is also not fixed, yet.
However, if I disconnect one of my two external USB hubs. Wireshark successfully starts up.
If you need more info please let me know.

[davidva-ecco]

Hi @desowin,

"This has downside that when you run it from command prompt, it'll still print to the command prompt window but that'll appear after the next prompt. In other words, simply press enter in the powershell and it should work just fine."

I was referring to PowerShell not dropping back to the command line after printing the output from USBPcapCMD.exe, but like you said the output appeared after the next prompt which I didn't notice, so I don't think there was an error exit code.

I will try to capture the output of USBPcapCMD.exe today with my working and non-working system configurations and get you the dumps.

[davidva-ecco]

Unfortunately I do not have administrator permissions to run PowerShell scripts on my work machine, so I wasn't able to capture the exit code.

However, here are the outputs from .\USBPcapCMD.exe --extcap-config --extcap-interface \\.\USBPcap1, working (USBPcapCMD-ok.txt) and not working (USBPcapCMD-freeze.txt) configurations.

In both cases I have Bluetooth disabled on my machine. The not working configuration has a 4-port USB hub connected to a Dell laptop dock, and the 4-port hub has 3 devices connected. The working configuration has the 4-port hub unplugged from the Dell laptop dock.

Let me know if there's any other information I can provide to help with this.

USBPcapCMD-freeze.txt
USBPcapCMD-ok.txt

[desowin]

Looks like the devices from the USB hub are not listed. Is the USBPcapCMD still running after it prints the last line from the freeze log you posted? If it does, then that should explain the behavior that you wrote about the Wireshark eventually starting up. And if that's the case, please let it running for atleast the same amount of time it takes for Wireshark to get past the initializing external capture interfaces. Are there any lines printed later on if you let it running longer?

Do you have only USBPcap1 in your system? Or do you have more? If there's more, can you include the extcap config for all of them?

[davidva-ecco]

USBPcap1 is the only interface that appears when I start Wireshark in working and non-working configurations.

According to the Task Manager, USBPcapCMD is no longer running after the output is printed; PowerShell and its Console Window Host show 0% CPU usage and USBPcapCMD is not in the "Apps" list. Is there somewhere else I need to look? In any case, no more lines print out from USBPcapCMD when I let it go for the same amount of time as it takes Wireshark to get past "Initializing external capture plugins".

It appears that the 4-port hub itself is producing the issue. If I have the hub plugged in to my dock, with no devices attached to the hub, Wireshark hangs. The USBPcapCMD output in this configuration is attached, USBPcapCMD-hub.txt. Additionally if I plug the hub directly into my laptop's USB port rather than through the dock, Wireshark also hangs, output attached in USBPcapCMD-hub-direct-conn.txt.

If I unplug the hub, Wireshark starts up right away, the output for this is in USBPCapCMD-no-hub.txt.

Comparing diffs of the files shows that when the hub is connected to either PC or dock, the "Generic SuperSpeed USB Hub" gets printed twice at the end of the output, but differently:

Connected to PC:
value {arg=99}{value=20}{display=[20] Generic SuperSpeed USB Hub}{enabled=true}
value {arg=99}{value=2}{display=[2] Generic SuperSpeed USB Hub}{enabled=true}

Connected to HUB:
value {arg=99}{value=2}{display=[2] Generic SuperSpeed USB Hub}{enabled=true}
value {arg=99}{value=18}{display=[18] Generic SuperSpeed USB Hub}{enabled=true}{parent=2}

So maybe something with having two Generic SuperSpeed USB Hubs?

The 4-port hub shows as both a Generic USB Hub and Generic SuperSpeed USB Hub in the Device Manager. Its VID:PID for the Generic USB Hub are 0x2109:0x2813, and for the SuperSpeed are 0x2109:0x0813, if that helps.

USBPcapCMD-direct-hub-conn.txt
USBPcapCMD-hub.txt
USBPcapCMD-no-hub.txt

[desowin]

Can you find the hub in device manager when the grouping by connection (default is by type) is active? Can you include the screenshot of expanded device tree around this hub?

[fabianbuettner]

@desowin my usb hubs do not show up in the device manager when the grouping by connection is active

[fillbert]

I have got the same issue with Bluetooth adapter on my laptop (Lenovo). After I had switched off it Wire shark started normally.
And I noticed that the output of the command: C:\Program Files\Wireshark\extcap\USBPcapCMD.exe --extcap-config --extcap-interface \.\USBPcap1 has been stopped on the problem device.

[MoshiMoshi0]

I have the same problem, it seems that its not that the USBPcapCMD.exe freezes, but it just waits for input. So if I just press enter it returns to the command prompt.

It seems like the process exits fine because it disappears from procexp, but there is a weird phantom read on the console. This even happens with USBPcapCMD.exe --help.

So I guess maybe the console handle is not freed correctly?

GIF of it happening:
https://gfycat.com/linedsaneaardvark

edit: yea I think something is wrong with how the console is handled, so I guess the USBPcapCMD process spawns a thread that attaches to the parent console and then immediately exits. The thread then writes directly to the console. You can see this if you do USBPcapCMD.exe --help && dir. The dir command should only be executed after the USBPcapCMD successfully finishes, but its output is before the help output which makes no sense.

So I guess I was wrong and the console weird behavior might be just a problem with redirection:

https://support.microsoft.com/en-us/help/190351/how-to-spawn-console-processes-with-redirected-standard-handles

Child processes that use such C run-time functions as printf() and fprintf() can behave poorly when redirected. The C run-time functions maintain separate IO buffers. When redirected, these buffers might not be flushed immediately after each IO call. As a result, the output to the redirection pipe of a printf() call or the input from a getch() call is not flushed immediately and delays, sometimes-infinite delays occur. This problem is avoided if the child process flushes the IO buffers after each call to a C run-time IO function. Only the child process can flush its C run-time IO buffers. A process can flush its C run-time IO buffers by calling the fflush() function.

Also when debugging I noticed that in my case the first call to GlobalFree here seems to take a long time and that is what is causing the freeze.

[fabianbuettner]

So how can we get this fixed? :(

[desowin]

Does USBPcap 1.3.0.0 affect the freeze in any way?

[fabianbuettner]

The debug build you sent me works for me :)
I started the Wireshark.exe so I guess I wasn't using USBPcap 1.3.0.0? Because I only do have USBPcap 1.2.0.4 installed right now.
Thank you!

EDIT: If you want me to retest with 1.3.0.0 installed, just let me know.

[desowin]

So the problem (atleast when using USBPcap 1.2.0.4 or newer) is actually in how Wireshark reads extcap output. In releases older prior to Aug 16, 2018, it was a deadlock and in newer releases it is "just" a performance issue.

[MoshiMoshi0]

Does not seem to work for me.
But ive noticed that USBPcapCMD.exe version in 1.3.0.0 installer is still 1.2.0.4, shouldn't it also be 1.3.0.0?

[desowin]

@devcompl The version number being invalid in 1.3.0.0 release is a known bug.

Fabian was referring to debug build of the Wireshark, as the problem seems to be indeed there. I'll create a review linked to the Wireshark bug, so if you anyone is interested please CC the Wireshark bug.

[fabianbuettner]

@desowin Do you still want me to comment on the wireshark bugzilla link you sent me?

[desowin]

@fabianbuettner Yes, I think it is good to have Wireshark related changes disscussed in Wireshark bug tracker.

[fabianbuettner]

@desowin I am not really sure what I should add to the discussion there

[desowin]

This turns out to have been a Wireshark issue. The potential mitigatins I have done in USBPcap probably don't hurt, but the issue is resolved by just fixing Wireshark.

For more information please check:

• https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12845

• https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14657

• https://code.wireshark.org/review/#/c/29159/ and https://code.wireshark.org/review/#/c/29163/ changed the issue from a deadlock to "very slow" (so essentially reduced the initialization time from infinity to some minutes)

• https://code.wireshark.org/review/#/c/32773/ is the change that fixed it for good (reduced the initialization time to sensible value)

[bdun]

I had this issue with wireshark 3.0.1, and found turning off bluetooth fixes it.

[desowin]

First Wireshark release where this is fixed is 3.0.2.

[niczoom]

Wierd. I had WireShark 3.0.1 installed since this May. I hadn't used it for the last month, fired it up the other day to capture using USBPcap and it was working fine until at some point yesterday when it started to have a very long initialization startup period. This led me to this thread. I have now installed v3.1.0 dev and all is good again. I have v1.5.3.0 USBPcap installed.