Wireshark · Wireshark-dev: Re: [Wireshark-dev] Npcap 0.01 call for test about Windows loopback traffic capture feature

[Yang Luo <hsluoyb@xxxxxxxxx>]

Hi Jim,

On Fri, Jul 17, 2015 at 1:15 PM, Jim Young <jyoung@xxxxxxx> wrote:

Hello Yang,

From:  Yang Luo <hsluoyb@xxxxxxxxx> Date:  Thursday, July 16, 2015 8:44 PM

>When your Cisco AnyConnect VPN Client stops working, how about your other
>Internect connections? There seems to be a bug in Npcap that will lead to
>the whole network failure.
>

In my case the (Wifi) network interface was still working; I could still
use Firefox (and git pull) after the Cisco AnyConnect error messages had
popped up.

 

If only Wireshark is opened, Npcap actually only monitor the traffic didn't modify any packets, so there's no obvious reason that Npcap would affect your VPN client. My VPN client also stops working after some time without installing WinPcap or Npcap. If this is cause by Npcap, I guess it's related with the reboot failure issue possibly.

Interestingly while I was testing Npcap on my Window's system I was
actually multi-tasking between two different systems.  I was using Firefox
on each.   The Windows system with Npcap installed seemed to be getting
progressively slower to load web pages.  But the second system, a MacBook
Pro running OS X 10.8.5, did not seem to have any page load issues.   At
one point I pointed the browsers on each system to the same virgin web
page and followed the same set of links on each and simply eyeballed the
page load speeds. The Window's system with Npcap appeared to be an order
of magnitude slower (perhaps 30 seconds or more) versus 3 seconds for the
OS X system.  <blush> Stupidly I didn't bother to do a network trace at
that time to see if I might be able to determine the source of the
slowdown. (server vs client) </blush>.  Not sure this slowdown observation
is truly related to the Npcap install, but it was quite noticeable at the
time.   if I get an opportunity I might re-try again this weekend I might.

> About this BAD_POOL_CALLER BSOD, I think there may be some bugs in
>allocating pool memory. I have found this in MS:
>https://msdn.microsoft.com/en-us/library/windows/hardware/ff560185(v=vs.85
>).aspx.
> It needs the four parameters in your BSOD screen to check the detailed
>crash reason. It's good if you can provide it:)

I downloaded Nirsoft's BlueScreenView v1.55 to hopefully extract some
useful info from the Bluescreen minidump.

Here's a transcription of what BlueScreenView reported (please let me know
if you would prefer a screen snapshot or something else):

Bug Check String:  BAD_POOL_CALLER
Bug Check Code: 0x000000c2
Parameter 1: 00000000`00000007
Parameter 2: 00000000`00001200
Parameter 3: 00000000`00000000
Parameter 4: ffffe001`f04319d8
Caused By Driver: tcpip.sys
Caused By Address: tcpip.sys+ 1c7370
Processor: x64
Crash Address: ntpskrnl+ 150ca0
Full Path: C:\Windows\Minidump\071315-4125-01.dmp
Processors Count: 4
Major Version: 15
Minor Version: 9600
Dump File Time: 7/13/2015 7:46:48 PM

MSDN says the cause is "The current thread attempted to free the pool, which was already freed". What is weird is that it's tcpip.sys that caused the BSoD instead of Npcap driver, whatever, I have secured all ExFreePool calls in Npcap. Only WFP callout part in Npcap could communicate a bit with tcpip.sys, and I have improved that part. Let's see if there is still this bug in Npcap's next release.

 

Cheers,

Yang