Hi Jim, On Fri, Jul 17, 2015 at 1:15 PM, Jim Young <jyo...@gsu.edu> wrote:
> Hello Yang, > > From: Yang Luo <hslu...@gmail.com> 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
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
