Pascal Quantin
changed
bug 12845
Comment # 5
on bug 12845
from Pascal Quantin
(In reply to Pavel Sindelka from comment #4)
> Well, with 2.0.5, the last digit of USBPcap package ID was 3, now with 2.2.0
> it is 5, I have no idea what the actual difference is but definitely it is
> not "the same USBPcap version". BTW, who maintains USBPcap as Tomasz seems
> to be busy dealing with other things? I mean, there is the CPU resources
> issue I've filed at github which makes live capture with USBPcap a bit
> adrenaline even without the currently discovered issues, and it still exists
> even in the ....5 version.
Wireshark 2.0.6 provides the -5 version also. It is the same code as the
previous version, with simply the Microsoft cross check signature added to the
EV certificate of the driver so as to properly start on Windows 10 anniversary
update.
As you noticed the USBPcap development is stalled. The increment of the last
digit simply denote changes in the packaging of the program.
>
> > I never faced such issue on my side :(
>
> How can I help further? Will it help you if I install the Process Manager
> and check what is the command line of the zombie USBPcapCMD.exe which stays
> running after Wireshark freezes?
That would be a minimum to provide the full Process Monitor log. And it would
be better if a developer could reproduce the issue also.
I'm adding Roland in the loop as he is our extcap expert and did some major
changes in 2.2.
You are receiving this mail because:
- You are watching all bug changes.
