Wireshark · Wireshark-dev: Re: [Wireshark-dev] Npcap 0.03 call for test

Wireshark-dev: Re: [Wireshark-dev] Npcap 0.03 call for test

From: Tyson Key <tyson.key@xxxxxxxxx>

Date: Sat, 1 Aug 2015 23:35:12 +0100

Apologies for all of the spam, and indirection that my brief sojourn with an ancient version of NPCap caused (I shouldn't be doing this kind of repetitive testing, whilst I'm tired) - but it probably provides a control/benchmark, as far as "this is (kinda) the way things are supposed to work, on my machine" goes.

Anyway, after reinstalling the correct version (linked to in the very first mail from Yang), I get an instant, particularly nasty BSoD, as soon as I launch Wireshark, after rebooting:

Microsoft (R) Windows Debugger Version 6.3.9600.17336 AMD64

Loading Dump File [C:\Windows\MEMORY.DMP]

Kernel Bitmap Dump File: Only kernel address space is available

************* Symbol Path validation summary **************

Response Time (ms) Location

Deferred SRV*C:\Symbols\*http://msdl.microsoft.com/download/symbols

Symbol search path is: SRV*C:\Symbols\*http://msdl.microsoft.com/download/symbols

Executable search path is:

Windows 8 Kernel Version 9600 MP (4 procs) Free x64

Product: WinNt, suite: TerminalServer SingleUserTS Personal

Built by: 9600.17736.amd64fre.winblue_r9.150322-1500

Machine Name:

Kernel base = 0xfffff800`0ce07000 PsLoadedModuleList = 0xfffff800`0d0e0850

Debug session time: Tue Jul 28 16:30:31.391 2015 (UTC + 1:00)

System Uptime: 0 days 0:07:03.265

Loading Kernel Symbols

................

Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads that take too long.

Run !sym noisy before .reload to track down problems loading symbols.

...............................................

................................................................

..........................Page 110aba not present in the dump file. Type ".hh dbgerr004" for details

..Page 122ed4 not present in the dump file. Type ".hh dbgerr004" for details

..................................

Loading User Symbols

PEB is paged out (Peb.Ldr = 00007ff7`093db018). Type ".hh dbgerr001" for details

Loading unloaded module list

....................

*******************************************************************************

* *

* Bugcheck Analysis *

* *

*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck C2, {7, 1200, 117ec1, ffffe0015aeeaec8}

unable to get nt!MmNonPagedPoolStart

unable to get nt!MmSizeOfNonPagedPoolInBytes

Probably caused by : NETIO.SYS ( NETIO!NetioCompleteCloneNetBufferListChain+1508d )

Followup: MachineOwner

---------

2: kd> !analyze -v

*******************************************************************************

* *

* Bugcheck Analysis *

* *

*******************************************************************************

BAD_POOL_CALLER (c2)

The current thread is making a bad pool request. Typically this is at a bad IRQL level or double freeing the same allocation, etc.

Arguments:

Arg1: 0000000000000007, Attempt to free pool which was already freed

Arg2: 0000000000001200, (reserved)

Arg3: 0000000000117ec1, Memory contents of the pool block

Arg4: ffffe0015aeeaec8, Address of the block of pool being deallocated

Debugging Details:

------------------

POOL_ADDRESS: ffffe0015aeeaec8

FREED_POOL_TAG: NDnd

BUGCHECK_STR: 0xc2_7_NDnd

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

PROCESS_NAME: svchost.exe

CURRENT_IRQL: 2

ANALYSIS_VERSION: 6.3.9600.17336 (debuggers(dbg).150226-1500) amd64fre

LAST_CONTROL_TRANSFER: from fffff8000d0abff2 to fffff8000cf57ca0

STACK_TEXT:

ffffd000`9bba4ba8 fffff800`0d0abff2 : 00000000`000000c2 00000000`00000007 00000000`00001200 00000000`00117ec1 : nt!KeBugCheckEx

ffffd000`9bba4bb0 fffff801`14a2f83d : 00000000`00000000 ffffe001`5a593040 000008fe`00000010 00000014`00000011 : nt!ExAllocatePoolWithTag+0x1102

ffffd000`9bba4ca0 fffff801`14a013f1 : 00000000`00000000 ffffe001`59b5b600 00000000`00000000 00000000`00000000 : NETIO!NetioCompleteCloneNetBufferListChain+0x1508d

ffffd000`9bba4d10 fffff801`14d2bc18 : fffff801`14a66228 00000000`00000001 00000000`00000000 00000000`00000000 : NETIO!NetioDereferenceNetBufferListChain+0x2d1

ffffd000`9bba4db0 fffff801`14d0118c : ffffe001`5de21fcc 00000000`0000a567 00000000`00000000 00000000`00000000 : tcpip!TcpFlushDelay+0x88

ffffd000`9bba4e60 fffff801`14d36f9f : ffffe001`5a527d80 ffffd000`9bba350b ffffd000`9bba81c1 ffffe001`5a4f81c1 : tcpip!TcpPreValidatedReceive+0x3cc

ffffd000`9bba4f60 fffff801`14d33143 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : tcpip!IppDeliverListToProtocol+0x4f

ffffd000`9bba5020 fffff801`14d31525 : 00000000`00000000 00000000`00000000 00000000`00000000 ffffd000`9bba5128 : tcpip!IppProcessDeliverList+0x63

ffffd000`9bba50c0 fffff801`14ce9c9d : 00000000`00000000 00000000`00000000 00000000`00000000 ffffd000`9bba52d8 : tcpip!IppReceiveHeaderBatch+0x235

ffffd000`9bba51f0 fffff801`14ce91cc : ffffd000`9bba5300 00000000`00000000 ffffe001`5cdfa540 ffffd000`9bba5440 : tcpip!IppLoopbackIndicatePackets+0x39d

ffffd000`9bba52d0 fffff801`14d06eb8 : ffffe001`59e84600 346dc5d6`38865900 ffffd000`9bba5500 00000000`00000000 : tcpip!IppLoopbackEnqueue+0x3dc

ffffd000`9bba5400 fffff801`14d06389 : fffff801`14e81180 00000000`00000000 00000000`00000000 00000000`00000000 : tcpip!IppDispatchSendPacketHelper+0x398

ffffd000`9bba5590 fffff801`14d0491e : ffff0014`00000001 ffffe001`5a4bc568 00000000`00000002 ffffd000`9bba59e0 : tcpip!IppPacketizeDatagrams+0x2d9

ffffd000`9bba5730 fffff801`14d09ab7 : fffff801`14cca4f0 00000000`00000007 fffff801`14e81180 ffffe001`5c76f8c0 : tcpip!IppSendDatagramsCommon+0x49e

ffffd000`9bba5910 fffff801`14cff435 : ffffd000`9bba5cf2 00000000`00000000 ffffe001`5caff550 ffffd000`9bba5f90 : tcpip!TcpTcbSend+0x55b

ffffd000`9bba5c60 fffff801`14cff07c : 00000000`0000a567 ffffe001`5c76f8c0 ffffd000`9bba5cf1 ffffd000`9bba5f00 : tcpip!TcpEnqueueTcbSendOlmNotifySendComplete+0xa5

ffffd000`9bba5c90 fffff801`14cff538 : ffffc001`5b0b1b02 00000000`00000000 ffffe001`5dbf5100 00000000`0ce5a000 : tcpip!TcpEnqueueTcbSend+0x2ac

ffffd000`9bba5d90 fffff800`0ce79703 : ffffe001`5dbf51e0 fffff801`14cff7f6 fffff801`14cff510 ffffd000`9bba5e50 : tcpip!TcpTlConnectionSendCalloutRoutine+0x28

ffffd000`9bba5e10 fffff801`14cff7f6 : fffff801`14cff510 ffffd000`9bba5f30 ffffc001`5b0b1e00 00000000`00000000 : nt!KeExpandKernelStackAndCalloutInternal+0xf3

ffffd000`9bba5f00 fffff801`15402ecf : ffffe001`5dbf51e0 ffffe001`59f3c4c0 00000000`00000000 ffffe001`5db660c0 : tcpip!TcpTlConnectionSend+0x76

ffffd000`9bba5f70 fffff801`184e7860 : ffffe001`5c7b9cb0 00000000`00000002 ffffe001`5db660c0 ffffe001`5c75b050 : afd!WskProIRPSend+0xbf

ffffd000`9bba5fe0 fffff801`184e647c : 00000000`ffffffff ffffe001`59fc96f8 00000580`00000000 fffffa80`001ca790 : HTTP!UxTlInitiateSend+0x1e0

ffffd000`9bba60a0 fffff801`1855b0ea : ffffe001`59fc96f8 00000000`00000000 00000000`00000001 00000000`00000000 : HTTP!UxpTpFastTransmit+0x19c

ffffd000`9bba6140 fffff801`184e7cad : ffffe001`59fc9420 fffff801`184e64ff 00000000`00000000 ffffe001`58ef53b0 : HTTP!UxTpTransmitPacket+0xba

ffffd000`9bba61e0 fffff801`18559bbf : 00000000`00000000 00000000`00000000 fffff801`18536ae0 ffffe001`58ef53b0 : HTTP!UlSendData+0xdd

ffffd000`9bba6270 fffff801`18574a7f : 00000000`00000000 fffff801`18536ae0 ffffe001`5a211850 ffffe001`5a211850 : HTTP!UlFastSendHttpResponse+0x1765

ffffd000`9bba6500 fffff801`184e42b8 : 00000000`00124043 fffff801`1854c180 00000000`00000020 ffffe001`5a2119f8 : HTTP!UlSendEntityBodyIoctl+0xd2f

ffffd000`9bba6840 fffff800`0d22c77f : 00000000`00000000 ffffd000`9bba6b80 ffffe001`5a211850 00000000`00000004 : HTTP!UlDeviceControl+0x78

ffffd000`9bba6880 fffff800`0d22bd22 : ffffd000`9bba6a38 00000000`00000000 00000000`00000000 00000000`00000000 : nt!IopXxxControlFile+0xa4f

ffffd000`9bba6a20 fffff800`0cf634b3 : ffffe001`58edf080 00000000`001f0003 00000031`01acf0f8 00000000`00000001 : nt!NtDeviceIoControlFile+0x56

ffffd000`9bba6a90 00007ff8`24c3123a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13

00000031`01ace928 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ff8`24c3123a

STACK_COMMAND: kb

FOLLOWUP_IP:

NETIO!NetioCompleteCloneNetBufferListChain+1508d

fffff801`14a2f83d 90 nop

SYMBOL_STACK_INDEX: 2

SYMBOL_NAME: NETIO!NetioCompleteCloneNetBufferListChain+1508d

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: NETIO

IMAGE_NAME: NETIO.SYS

DEBUG_FLR_IMAGE_TIMESTAMP: 540ebbe6

BUCKET_ID_FUNC_OFFSET: 1508d

FAILURE_BUCKET_ID: 0xc2_7_NDnd_NETIO!NetioCompleteCloneNetBufferListChain

BUCKET_ID: 0xc2_7_NDnd_NETIO!NetioCompleteCloneNetBufferListChain

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:0xc2_7_ndnd_netio!netiocompleteclonenetbufferlistchain

FAILURE_ID_HASH: {ec09700b-3916-f849-b5d5-75c2ba7b02db}

Followup: MachineOwner

---------

Sadly, this dump has overwritten my last one (which I didn't get chance to back-up), but it seems to be one of the clearest expressions of the BAD_POOL_CALLER error that I've seen, on this machine (at least after removing a bunch of other software that also intimately hooked into WinSock).

Tyson.

2015-08-01 23:12 GMT+01:00 Tyson Key <tyson.key@xxxxxxxxx>:

Oops, it seems that I did all of that testing, against the wrong version (a 0.01 build, instead of 0.03) - but still, some of this info maybe useful :(

Tyson.

2015-08-01 22:48 GMT+01:00 Tyson Key <tyson.key@xxxxxxxxx>:
Aah, if I disable using the .NET Reference Source Symbol Service, and restart WinDBG, I can receive the following information:

Microsoft (R) Windows Debugger Version 6.3.9600.17336 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [C:\Windows\MEMORY.DMP]
Kernel Bitmap Dump File: Only kernel address space is available

************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred SRV*C:\Symbols\*http://msdl.microsoft.com/download/symbols
Symbol search path is: SRV*C:\Symbols\*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 8 Kernel Version 9600 MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 9600.17736.amd64fre.winblue_r9.150322-1500
Machine Name:
Kernel base = 0xfffff800`0ce07000 PsLoadedModuleList = 0xfffff800`0d0e0850
Debug session time: Tue Jul 28 16:30:31.391 2015 (UTC + 1:00)
System Uptime: 0 days 0:07:03.265
Loading Kernel Symbols
...............................................................
................................................................
..........................Page 110aba not present in the dump file. Type ".hh dbgerr004" for details
..Page 122ed4 not present in the dump file. Type ".hh dbgerr004" for details
..................................
Loading User Symbols
PEB is paged out (Peb.Ldr = 00007ff7`093db018). Type ".hh dbgerr001" for details
Loading unloaded module list
....................
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck C2, {7, 1200, 117ec1, ffffe0015aeeaec8}

unable to get nt!MmNonPagedPoolStart
unable to get nt!MmSizeOfNonPagedPoolInBytes
Probably caused by : NETIO.SYS ( NETIO!NetioCompleteCloneNetBufferListChain+1508d )

Followup: MachineOwner
---------

2: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

BAD_POOL_CALLER (c2)
The current thread is making a bad pool request. Typically this is at a bad IRQL level or double freeing the same allocation, etc.
Arguments:
Arg1: 0000000000000007, Attempt to free pool which was already freed
Arg2: 0000000000001200, (reserved)
Arg3: 0000000000117ec1, Memory contents of the pool block
Arg4: ffffe0015aeeaec8, Address of the block of pool being deallocated

Debugging Details:
------------------

POOL_ADDRESS: ffffe0015aeeaec8

FREED_POOL_TAG: NDnd

BUGCHECK_STR: 0xc2_7_NDnd

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

PROCESS_NAME: svchost.exe

CURRENT_IRQL: 2

ANALYSIS_VERSION: 6.3.9600.17336 (debuggers(dbg).150226-1500) amd64fre

LAST_CONTROL_TRANSFER: from fffff8000d0abff2 to fffff8000cf57ca0

STACK_TEXT:
ffffd000`9bba4ba8 fffff800`0d0abff2 : 00000000`000000c2 00000000`00000007 00000000`00001200 00000000`00117ec1 : nt!KeBugCheckEx
ffffd000`9bba4bb0 fffff801`14a2f83d : 00000000`00000000 ffffe001`5a593040 000008fe`00000010 00000014`00000011 : nt!ExAllocatePoolWithTag+0x1102
ffffd000`9bba4ca0 fffff801`14a013f1 : 00000000`00000000 ffffe001`59b5b600 00000000`00000000 00000000`00000000 : NETIO!NetioCompleteCloneNetBufferListChain+0x1508d
ffffd000`9bba4d10 fffff801`14d2bc18 : fffff801`14a66228 00000000`00000001 00000000`00000000 00000000`00000000 : NETIO!NetioDereferenceNetBufferListChain+0x2d1
ffffd000`9bba4db0 fffff801`14d0118c : ffffe001`5de21fcc 00000000`0000a567 00000000`00000000 00000000`00000000 : tcpip!TcpFlushDelay+0x88
ffffd000`9bba4e60 fffff801`14d36f9f : ffffe001`5a527d80 ffffd000`9bba350b ffffd000`9bba81c1 ffffe001`5a4f81c1 : tcpip!TcpPreValidatedReceive+0x3cc
ffffd000`9bba4f60 fffff801`14d33143 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : tcpip!IppDeliverListToProtocol+0x4f
ffffd000`9bba5020 fffff801`14d31525 : 00000000`00000000 00000000`00000000 00000000`00000000 ffffd000`9bba5128 : tcpip!IppProcessDeliverList+0x63
ffffd000`9bba50c0 fffff801`14ce9c9d : 00000000`00000000 00000000`00000000 00000000`00000000 ffffd000`9bba52d8 : tcpip!IppReceiveHeaderBatch+0x235
ffffd000`9bba51f0 fffff801`14ce91cc : ffffd000`9bba5300 00000000`00000000 ffffe001`5cdfa540 ffffd000`9bba5440 : tcpip!IppLoopbackIndicatePackets+0x39d
ffffd000`9bba52d0 fffff801`14d06eb8 : ffffe001`59e84600 346dc5d6`38865900 ffffd000`9bba5500 00000000`00000000 : tcpip!IppLoopbackEnqueue+0x3dc
ffffd000`9bba5400 fffff801`14d06389 : fffff801`14e81180 00000000`00000000 00000000`00000000 00000000`00000000 : tcpip!IppDispatchSendPacketHelper+0x398
ffffd000`9bba5590 fffff801`14d0491e : ffff0014`00000001 ffffe001`5a4bc568 00000000`00000002 ffffd000`9bba59e0 : tcpip!IppPacketizeDatagrams+0x2d9
ffffd000`9bba5730 fffff801`14d09ab7 : fffff801`14cca4f0 00000000`00000007 fffff801`14e81180 ffffe001`5c76f8c0 : tcpip!IppSendDatagramsCommon+0x49e
ffffd000`9bba5910 fffff801`14cff435 : ffffd000`9bba5cf2 00000000`00000000 ffffe001`5caff550 ffffd000`9bba5f90 : tcpip!TcpTcbSend+0x55b
ffffd000`9bba5c60 fffff801`14cff07c : 00000000`0000a567 ffffe001`5c76f8c0 ffffd000`9bba5cf1 ffffd000`9bba5f00 : tcpip!TcpEnqueueTcbSendOlmNotifySendComplete+0xa5
ffffd000`9bba5c90 fffff801`14cff538 : ffffc001`5b0b1b02 00000000`00000000 ffffe001`5dbf5100 00000000`0ce5a000 : tcpip!TcpEnqueueTcbSend+0x2ac
ffffd000`9bba5d90 fffff800`0ce79703 : ffffe001`5dbf51e0 fffff801`14cff7f6 fffff801`14cff510 ffffd000`9bba5e50 : tcpip!TcpTlConnectionSendCalloutRoutine+0x28
ffffd000`9bba5e10 fffff801`14cff7f6 : fffff801`14cff510 ffffd000`9bba5f30 ffffc001`5b0b1e00 00000000`00000000 : nt!KeExpandKernelStackAndCalloutInternal+0xf3
ffffd000`9bba5f00 fffff801`15402ecf : ffffe001`5dbf51e0 ffffe001`59f3c4c0 00000000`00000000 ffffe001`5db660c0 : tcpip!TcpTlConnectionSend+0x76
ffffd000`9bba5f70 fffff801`184e7860 : ffffe001`5c7b9cb0 00000000`00000002 ffffe001`5db660c0 ffffe001`5c75b050 : afd!WskProIRPSend+0xbf
ffffd000`9bba5fe0 fffff801`184e647c : 00000000`ffffffff ffffe001`59fc96f8 00000580`00000000 fffffa80`001ca790 : HTTP!UxTlInitiateSend+0x1e0
ffffd000`9bba60a0 fffff801`1855b0ea : ffffe001`59fc96f8 00000000`00000000 00000000`00000001 00000000`00000000 : HTTP!UxpTpFastTransmit+0x19c
ffffd000`9bba6140 fffff801`184e7cad : ffffe001`59fc9420 fffff801`184e64ff 00000000`00000000 ffffe001`58ef53b0 : HTTP!UxTpTransmitPacket+0xba
ffffd000`9bba61e0 fffff801`18559bbf : 00000000`00000000 00000000`00000000 fffff801`18536ae0 ffffe001`58ef53b0 : HTTP!UlSendData+0xdd
ffffd000`9bba6270 fffff801`18574a7f : 00000000`00000000 fffff801`18536ae0 ffffe001`5a211850 ffffe001`5a211850 : HTTP!UlFastSendHttpResponse+0x1765
ffffd000`9bba6500 fffff801`184e42b8 : 00000000`00124043 fffff801`1854c180 00000000`00000020 ffffe001`5a2119f8 : HTTP!UlSendEntityBodyIoctl+0xd2f
ffffd000`9bba6840 fffff800`0d22c77f : 00000000`00000000 ffffd000`9bba6b80 ffffe001`5a211850 00000000`00000004 : HTTP!UlDeviceControl+0x78
ffffd000`9bba6880 fffff800`0d22bd22 : ffffd000`9bba6a38 00000000`00000000 00000000`00000000 00000000`00000000 : nt!IopXxxControlFile+0xa4f
ffffd000`9bba6a20 fffff800`0cf634b3 : ffffe001`58edf080 00000000`001f0003 00000031`01acf0f8 00000000`00000001 : nt!NtDeviceIoControlFile+0x56
ffffd000`9bba6a90 00007ff8`24c3123a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000031`01ace928 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ff8`24c3123a

STACK_COMMAND: kb

FOLLOWUP_IP:
NETIO!NetioCompleteCloneNetBufferListChain+1508d
fffff801`14a2f83d 90 nop

SYMBOL_STACK_INDEX: 2

SYMBOL_NAME: NETIO!NetioCompleteCloneNetBufferListChain+1508d

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: NETIO

IMAGE_NAME: NETIO.SYS

DEBUG_FLR_IMAGE_TIMESTAMP: 540ebbe6

BUCKET_ID_FUNC_OFFSET: 1508d

FAILURE_BUCKET_ID: 0xc2_7_NDnd_NETIO!NetioCompleteCloneNetBufferListChain

BUCKET_ID: 0xc2_7_NDnd_NETIO!NetioCompleteCloneNetBufferListChain

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:0xc2_7_ndnd_netio!netiocompleteclonenetbufferlistchain

FAILURE_ID_HASH: {ec09700b-3916-f849-b5d5-75c2ba7b02db}

Followup: MachineOwner
---------

This seems a lot more useful, I think...

Tyson.

2015-08-01 22:43 GMT+01:00 Tyson Key <tyson.key@xxxxxxxxx>:
Hi Yang,

This is something of an anti-climax, after doing the post-mortem (I waited a long time to receive this BSoD! :(), but the means of triggering it are really interesting; and I managed to crash Wireshark itself, before I was able to restart it, and do another trace...

I was trying to use Linn Kinsky to play some music via UPnP, on a Raspberry Pi running upmpdcli; and noticed that Asset UPnP (my media streaming server) wasn't being detected as a source in Kinsky, despite the upmpdcli being detected as a "Room"/sink for media playback (due to some problems with multicast traffic, and local unicast server traffic being incorrectly passed into the NPCap Loopback Adapter, instead of my WLAN adapter).

So whilst Wireshark was still happily capturing packets (as it had been, for about an hour), I decided to use "Play To" in Windows Media Player, to send/stream an AAC file - which worked, although oddly, I couldn't see all of the traffic between WMP, and upmpdcli, despite capturing on all interfaces at once, after doing diagnostic on my WLAN, a few times; so I started saving the trace, and tried to start a new one. At this stage, Wireshark crashed; and I ended up restarting it, whilst the media was still streaming (and I could now see the HTTP traffic between the two UPnP implementations) - but about 20 minutes later, I received a long-awaited BSoD...

WinDBG only seems to give me the following information, which suggests that I may have a problem with some symbol files:

Microsoft (R) Windows Debugger Version 6.3.9600.17336 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [C:\Windows\MEMORY.DMP]
Kernel Bitmap Dump File: Only kernel address space is available

************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred SRV*C:\Symbols\*http://msdl.microsoft.com/download/symbols*http://referencesource.microsoft.com/symbols
Symbol search path is: SRV*C:\Symbols\*http://msdl.microsoft.com/download/symbols*http://referencesource.microsoft.com/symbols
Executable search path is:
*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntkrnlmp.exe -
Windows 8 Kernel Version 9600 MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 9600.17736.amd64fre.winblue_r9.150322-1500
Machine Name:
Kernel base = 0xfffff800`0ce07000 PsLoadedModuleList = 0xfffff800`0d0e0850
Debug session time: Tue Jul 28 16:30:31.391 2015 (UTC + 1:00)
System Uptime: 0 days 0:07:03.265
*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntkrnlmp.exe -
Loading Kernel Symbols
...............

Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads that take too long.
Run !sym noisy before .reload to track down problems loading symbols.

................................................
................................................................
..........................Page 110aba not present in the dump file. Type ".hh dbgerr004" for details
..Page 122ed4 not present in the dump file. Type ".hh dbgerr004" for details
..................................
Loading User Symbols
PEB is paged out (Peb.Ldr = 00007ff7`093db018). Type ".hh dbgerr001" for details
Loading unloaded module list
....................

************* Symbol Loading Error Summary **************
Module name Error
ntkrnlmp The system cannot find the file specified

You can troubleshoot most symbol related issues by turning on symbol loading diagnostics (!sym noisy) and repeating the command that caused symbols to be loaded.
You should also verify that your symbol search path (.sympath) is correct.
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck C2, {7, 1200, 117ec1, ffffe0015aeeaec8}

*** ERROR: Symbol file could not be found. Defaulted to export symbols for NETIO.SYS -
*** ERROR: Module load completed but symbols could not be loaded for tcpip.sys
*** ERROR: Module load completed but symbols could not be loaded for afd.sys
*** ERROR: Module load completed but symbols could not be loaded for HTTP.sys
***** Kernel symbols are WRONG. Please fix symbols to do analysis.

*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!PVOID ***
*** ***
*************************************************************************
unable to get nt!MmSpecialPoolStart
unable to get nt!MmSpecialPoolEnd
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_POOL_HEADER ***
*** ***
*************************************************************************
unable to get nt!MmPagedPoolEnd
unable to get nt!MmNonPagedPoolStart
unable to get nt!MmSizeOfNonPagedPoolInBytes
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_POOL_HEADER ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_POOL_TRACKER_BIG_PAGES ***
*** ***
*************************************************************************
Cannot get _POOL_TRACKER_BIG_PAGES type size
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
Probably caused by : NETIO.SYS ( NETIO!KfdQueryLayerStats+2049 )

Followup: MachineOwner
---------

I'm going to retry analysis with "unqualified symbols" enabled - but I thought that I already had all of these symbols installed (for both System32, and SysWoW64), although maybe they became corrupted during installation?

As for the VMware Player issues, I noticed this, in the Event Log:

The application (VMware Player, from vendor VMware, Inc.) has the following problem: To function properly, VMware Player must be reinstalled after you upgrade Windows.

Since I don't have VMware's proprietary symbols, I only get this information from its coredump - but it may still be interesting...

Microsoft (R) Windows Debugger Version 6.3.9600.17336 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [C:\Users\tyson_000\AppData\Local\Temp\vmware-tyson_000\vmplayer-10248.dmp]
User Mini Dump File: Only registers, stack and portions of memory are available

************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred SRV*C:\Symbols\*http://msdl.microsoft.com/download/symbols*http://referencesource.microsoft.com/symbols
Symbol search path is: SRV*C:\Symbols\*http://msdl.microsoft.com/download/symbols*http://referencesource.microsoft.com/symbols
Executable search path is:
Windows 8 Version 9600 MP (4 procs) Free x86 compatible
Product: WinNt, suite: SingleUserTS Personal
Built by: 6.3.9600.17031 (winblue_gdr.140221-1952)
Machine Name:
Debug session time: Sat Aug 1 21:51:12.000 2015 (UTC + 1:00)
System Uptime: not available
Process Uptime: 0 days 0:00:22.000
................................................................
................................................................
.
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(2808.2818): Unknown exception - code cafebabe (first/second chance not available)
*** WARNING: Unable to verify timestamp for ntdll.dll
*** ERROR: Module load completed but symbols could not be loaded for ntdll.dll
eax=00000000 ebx=05262c20 ecx=00000000 edx=00000000 esi=05262bd8 edi=05262be8
eip=76fad28c esp=0734a34c ebp=0734a358 iopl=0 nv up ei pl nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
ntdll+0x3d28c:
76fad28c c20800 ret 8
0:014> .excr
^ Syntax error in '.excr'
0:014> !verify
No export verify found
0:014> !validate
No export validate found
0:014> !analyze -v
*******************************************************************************
* *
* Exception Analysis *
* *
*******************************************************************************

*** WARNING: Unable to verify timestamp for kernel32.dll
*** ERROR: Module load completed but symbols could not be loaded for kernel32.dll
***** OS symbols are WRONG. Please fix symbols to do analysis.

Unable to load image C:\Windows\System32\KERNELBASE.dll, Win32 error 0n2
*** WARNING: Unable to verify timestamp for KERNELBASE.dll
*** ERROR: Module load completed but symbols could not be loaded for KERNELBASE.dll
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!IMAGE_NT_HEADERS32 ***
*** ***
*************************************************************************
Unable to load image C:\Windows\System32\user32.dll, Win32 error 0n2
*** WARNING: Unable to verify timestamp for user32.dll
*** ERROR: Module load completed but symbols could not be loaded for user32.dll
*** ERROR: Symbol file could not be found. Defaulted to export symbols for vmplayer.exe -
Unable to load image C:\Windows\System32\ole32.dll, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ole32.dll
*** ERROR: Module load completed but symbols could not be loaded for ole32.dll

************* Symbol Loading Error Summary **************
Module name Error
ole32 PDB not found : srv*c:\symbols\*http://msdl.microsoft.com/download/symbols*http://referencesource.microsoft.com/symbols

You can troubleshoot most symbol related issues by turning on symbol loading diagnostics (!sym noisy) and repeating the command that caused symbols to be loaded.
You should also verify that your symbol search path (.sympath) is correct.
Unable to load image C:\Windows\System32\combase.dll, Win32 error 0n2
*** WARNING: Unable to verify timestamp for combase.dll
*** ERROR: Module load completed but symbols could not be loaded for combase.dll

************* Symbol Loading Error Summary **************
Module name Error
combase PDB not found : srv*c:\symbols\*http://msdl.microsoft.com/download/symbols*http://referencesource.microsoft.com/symbols

You can troubleshoot most symbol related issues by turning on symbol loading diagnostics (!sym noisy) and repeating the command that caused symbols to be loaded.
You should also verify that your symbol search path (.sympath) is correct.
*** ERROR: Symbol file could not be found. Defaulted to export symbols for GdiPlus.dll -
*** ERROR: Symbol file could not be found. Defaulted to export symbols for nuragoLSPService.DLL -
*** WARNING: Unable to verify timestamp for ws2_32.dll
*** ERROR: Module load completed but symbols could not be loaded for ws2_32.dll
*** WARNING: Unable to verify timestamp for mswsock.dll
*** ERROR: Module load completed but symbols could not be loaded for mswsock.dll

FAULTING_IP:
KERNELBASE+14598
76a14598 8b4c2454 mov ecx,dword ptr [esp+54h]

EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 76a14598 (KERNELBASE+0x00014598)
ExceptionCode: cafebabe
ExceptionFlags: 00000000
NumberParameters: 0

CONTEXT: 00000000 -- (.cxr 0x0;r)
eax=00000000 ebx=05262c20 ecx=00000000 edx=00000000 esi=05262bd8 edi=05262be8
eip=76fad28c esp=0734a34c ebp=0734a358 iopl=0 nv up ei pl nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
ntdll+0x3d28c:
76fad28c c20800 ret 8

DEFAULT_BUCKET_ID: WRONG_SYMBOLS

PROCESS_NAME: vmplayer.exe

ADDITIONAL_DEBUG_TEXT:
You can run '.symfix; .reload' to try to fix the symbol path and load symbols.

FAULTING_MODULE: 76f70000 ntdll

DEBUG_FLR_IMAGE_TIMESTAMP: 558b015c

ERROR_CODE: (NTSTATUS) 0xcafebabe - <Unable to get error code text>

EXCEPTION_CODE: (NTSTATUS) 0xcafebabe - <Unable to get error code text>

APP: vmplayer.exe

ANALYSIS_VERSION: 6.3.9600.17336 (debuggers(dbg).150226-1500) amd64fre

LAST_CONTROL_TRANSFER: from 6e2ed56a to 6e2ca092

PRIMARY_PROBLEM_CLASS: WRONG_SYMBOLS

BUGCHECK_STR: APPLICATION_FAULT_WRONG_SYMBOLS

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
0734b0d0 6e2ed56a 0734f83b 04693798 5f544f4e vmwarebase!Ordinal478+0xc12
0734b4e0 6e2ed5b0 6e58c6fc 0734b4fc 0734f84c vmwarebase!Ordinal1473+0xea
0734b4f0 6e373e96 6e58c6fc 6e5d1aa4 00000f2e vmwarebase!Ordinal3+0x10
0734f84c 76807c04 04693798 76807be0 614f3b9d vmwarebase!Ordinal1438+0x2fa6
0734f860 76fcad1f 04693798 60d8b8da 00000000 kernel32+0x17c04
0734f8a8 76fcacea ffffffff 76fb021c 00000000 ntdll+0x5ad1f
0734f8b8 00000000 6e373bf0 04693798 00000000 ntdll+0x5acea

FOLLOWUP_IP:
vmwarebase!Ordinal478+c12
6e2ca092 8f8570fdffff pop dword ptr [ebp-290h]

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: vmwarebase!Ordinal478+c12

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: vmwarebase

IMAGE_NAME: vmwarebase.DLL

STACK_COMMAND: ~14s; .ecxr ; kb

BUCKET_ID: WRONG_SYMBOLS

FAILURE_BUCKET_ID: WRONG_SYMBOLS_cafebabe_vmwarebase.DLL!Ordinal478

ANALYSIS_SOURCE: UM

FAILURE_ID_HASH_STRING: um:wrong_symbols_cafebabe_vmwarebase.dll!ordinal478

FAILURE_ID_HASH: {e43078e2-dbb2-d9e8-8a03-1b6323ba8806}

Followup: MachineOwner
---------

0:014> .symfix; .reload
................................................................
................................................................
.
0:014> !analyze -v
*******************************************************************************
* *
* Exception Analysis *
* *
*******************************************************************************

*** ERROR: Symbol file could not be found. Defaulted to export symbols for vmplayer.exe -
*** ERROR: Symbol file could not be found. Defaulted to export symbols for nuragoLSPService.DLL -

FAULTING_IP:
KERNELBASE!RaiseException+48
76a14598 8b4c2454 mov ecx,dword ptr [esp+54h]

EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 76a14598 (KERNELBASE!RaiseException+0x00000048)
ExceptionCode: cafebabe
ExceptionFlags: 00000000
NumberParameters: 0

CONTEXT: 00000000 -- (.cxr 0x0;r)
eax=00000000 ebx=05262c20 ecx=00000000 edx=00000000 esi=05262bd8 edi=05262be8
eip=76fad28c esp=0734a34c ebp=0734a358 iopl=0 nv up ei pl nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
ntdll!NtGetContextThread+0xc:
76fad28c c20800 ret 8

DEFAULT_BUCKET_ID: APPLICATION_FAULT

PROCESS_NAME: vmplayer.exe

ERROR_CODE: (NTSTATUS) 0xcafebabe - <Unable to get error code text>

EXCEPTION_CODE: (NTSTATUS) 0xcafebabe - <Unable to get error code text>

APPLICATION_VERIFIER_FLAGS: 0

APP: vmplayer.exe

ANALYSIS_VERSION: 6.3.9600.17336 (debuggers(dbg).150226-1500) amd64fre

FAULTING_THREAD: 00002818

PRIMARY_PROBLEM_CLASS: APPLICATION_FAULT

BUGCHECK_STR: APPLICATION_FAULT_APPLICATION_FAULT

LAST_CONTROL_TRANSFER: from 6e2ed56a to 6e2ca092

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
0734b0d0 6e2ed56a 0734f83b 04693798 5f544f4e vmwarebase!Ordinal478+0xc12
0734b4e0 6e2ed5b0 6e58c6fc 0734b4fc 0734f84c vmwarebase!Ordinal1473+0xea
0734b4f0 6e373e96 6e58c6fc 6e5d1aa4 00000f2e vmwarebase!Ordinal3+0x10
0734f84c 76807c04 04693798 76807be0 614f3b9d vmwarebase!Ordinal1438+0x2fa6
0734f860 76fcad1f 04693798 60d8b8da 00000000 kernel32!BaseThreadInitThunk+0x24
0734f8a8 76fcacea ffffffff 76fb021c 00000000 ntdll!__RtlUserThreadStart+0x2f
0734f8b8 00000000 6e373bf0 04693798 00000000 ntdll!_RtlUserThreadStart+0x1b

FOLLOWUP_IP:
vmwarebase!Ordinal478+c12
6e2ca092 8f8570fdffff pop dword ptr [ebp-290h]

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: vmwarebase!Ordinal478+c12

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: vmwarebase

IMAGE_NAME: vmwarebase.DLL

DEBUG_FLR_IMAGE_TIMESTAMP: 558b015c

STACK_COMMAND: ~14s; .ecxr ; kb

FAILURE_BUCKET_ID: APPLICATION_FAULT_cafebabe_vmwarebase.DLL!Ordinal478

BUCKET_ID: APPLICATION_FAULT_APPLICATION_FAULT_vmwarebase!Ordinal478+c12

ANALYSIS_SOURCE: UM

FAILURE_ID_HASH_STRING: um:application_fault_cafebabe_vmwarebase.dll!ordinal478

FAILURE_ID_HASH: {9a30121c-2058-3ec3-2830-959a8e02a5af}

Followup: MachineOwner
---------

I hope that helps,

Tyson.

2015-08-01 21:20 GMT+01:00 Tyson Key <tyson.key@xxxxxxxxx>:
As for the loss of connectivity, Event Viewer just says:

Details about network adapter diagnosis:

Network adapter Wi-Fi driver information:

Description . . . . . . . . . . : Qualcomm Atheros AR9485WB-EG Wireless Network Adapter
Manufacturer . . . . . . . . . : Qualcomm Atheros Communications Inc.
Provider . . . . . . . . . . . : Qualcomm Atheros Communications Inc.
Version . . . . . . . . . . . : 10.0.0.242
Inf File Name . . . . . . . . . : C:\WINDOWS\INF\oem14.inf
Inf File Date . . . . . . . . . : Friday, March 29, 2013 3:07:20 AM
Section Name . . . . . . . . . : ATHR_DEV_OS61_321817AA.ndi
Hardware ID . . . . . . . . . . : pci\ven_168c&dev_0032&subsys_321817aa
Instance Status Flags . . . . . : 0x180200a
Device Manager Status Code . . : 0
IfType . . . . . . . . . . . . : 71
Physical Media Type . . . . . . : 9

Details about wireless connectivity diagnosis:

Information for connection being diagnosed
Interface GUID: 125860e2-8019-475a-806c-2d553e9e8c8c
Interface name: Qualcomm Atheros AR9485WB-EG Wireless Network Adapter
Interface type: Native WiFi

Connection incident diagnosed
Auto Configuration ID: 1
Connection ID: 1

Connection status summary
Connection started at: 2015-08-01 20:44:24-417
Profile match: Success
Pre-Association: Success
Association: Success
Security and Authentication: Success

List of visible access point(s): 6 item(s) total, 6 item(s) displayed
BSSID BSS Type PHY Signal(dB) Chnl/freq SSID
-------------------------------------------------------------------------
54-A5-1B-FA-0C-B0 Infra <unknown> -91 1 TALKTALK-FA0CA8
58-98-35-C1-56-4B Infra <unknown> -93 1 JohnLewisWirelessC1564B
C4-3D-C7-BF-6F-8E Infra g -70 6 DarkStar
80-3F-5D-97-02-08 Infra g -31 6 DarkStar
FC-75-16-AE-C3-A4 Infra <unknown> -91 11 TALKTALK-AEC3A4
60-E7-01-A6-12-F8 Infra <unknown> -91 2 TALKTALKA612F2

Connection History

Information for Auto Configuration ID 1

List of visible networks: 5 item(s) total, 5 item(s) displayed
BSS Type PHY Security Signal(RSSI) Compatible SSID
------------------------------------------------------------------------------
Infra <unknown> Yes 12 Yes TALKTALK-FA0CA8
Infra <unknown> Yes 8 Yes JohnLewisWirelessC1564B
Infra g No 100 Yes DarkStar
Infra <unknown> Yes 12 Yes TALKTALK-AEC3A4
Infra <unknown> Yes 12 Yes TALKTALKA612F2

List of preferred networks: 4 item(s)
Profile: Canon_ij_Setup
SSID: Canon_ij_Setup
SSID length: 14
Connection mode: Infra
Security: No
Set by group policy: No
Connect even if network is not broadcasting: No
Connectable: No
Reason: 0x00028001
Profile: uobroamnet
SSID: uobroamnet
SSID length: 10
Connection mode: Infra
Security: No
Set by group policy: No
Connect even if network is not broadcasting: No
Connectable: No
Reason: 0x00028001
Profile: NETGEAR
SSID: NETGEAR
SSID length: 7
Connection mode: Infra
Security: No
Set by group policy: No
Connect even if network is not broadcasting: No
Connectable: No
Reason: 0x00028001
Profile: DarkStar
SSID: DarkStar
SSID length: 8
Connection mode: Infra
Security: No
Set by group policy: No
Connect even if network is not broadcasting: No
Connectable: Yes

Information for Connection ID 1
Connection started at: 2015-08-01 20:44:24-417
Auto Configuration ID: 1
Profile: DarkStar
SSID: DarkStar
SSID length: 8
Connection mode: Infra
Security: No
Pre-Association and Association
Connectivity settings provided by hardware manufacturer (IHV): No
Security settings provided by hardware manufacturer (IHV): No
Profile matches network requirements: Success
Pre-association status: Success
Association status: Success
Last AP: 80-3f-5d-97-02-08
Security and Authentication
Configured security type: Open
Configured encryption type: None
802.1X protocol: No
Key exchange initiated: Yes
Unicast key received: No
Multicast key received: No
Number of security packets received: 0
Number of security packets sent: 0
Security attempt status: Success
Connectivity
Packet statistics
Ndis Rx: 761
Ndis Tx: 1050
Unicast decrypt success: 0
Multicast decrypt success: 0
Unicast decrypt failure: 0
Multicast decrypt failure: 0
Rx success: 860
Rx failure: 36
Tx success: 1442
Tx failure: 0
Tx retry: 199
Tx multiple retry: 0
Tx max lifetime exceeded: 0
Tx ACK failure: 199
Roaming history: 0 item(s)

Details about wireless connectivity diagnosis:

For complete information about this session see the wireless connectivity information event.

Helper Class: Auto Configuration
Initialize status: Success

Information for connection being diagnosed
Interface GUID: 125860e2-8019-475a-806c-2d553e9e8c8c
Interface name: Qualcomm Atheros AR9485WB-EG Wireless Network Adapter
Interface type: Native WiFi

Result of diagnosis: There may be problem

Time to start re-introducing variables, I think...

After I re-enabled the NPCap Loopback Interface, I started VMware Player, to see if I could reproduce BAD_POOL_CALLER, but as of 09:04pm, there's no crash.

Bizarrely, starting VMware Player resulted in:

I don't know if this is related to NPCap, though - but I could reproduce it, after re-launching Player. Curiously, I was able to begin starting a VM, before seeing the error again.

Judging from the log file, it's trying to create a new file, somewhere, where it supposedly doesn't have permission to write to (C:\ProgramData\VMware); and it also produced a core dump file, whilst I'll examine, shortly. However, Wireshark didn't crash, and there's still no sign of a BSoD, despite capturing over 36000 packets, whilst composing this e-mail.

I think this is a new record for stability, so far.

Tyson.

2015-08-01 20:50 GMT+01:00 Tyson Key <tyson.key@xxxxxxxxx>:
...and if I start Wireshark in "Administrator Mode", without running under the debugger (it doesn't detect any interfaces, otherwise - but I don't know if it'll suddenly try to invoke NPF, and crash my machine, yet), it lists interfaces, and I can capture from them.

After waiting about 5 minutes, staring at the pretty interface activity graphs on the Welcome screen, my WLAN connection suddenly fails (the interface is marked as "Limited"):

C:\Users\tyson_000>ping google.com
Ping request could not find host google.com. Please check the name and try again
.

C:\Users\tyson_000>ping 192.168.1.1

Pinging 192.168.1.1 with 32 bytes of data:
Request timed out.
Reply from 192.168.1.4: Destination host unreachable.
Request timed out.
Request timed out.

Ping statistics for 192.168.1.1:
Packets: Sent = 4, Received = 1, Lost = 3 (75% loss)

If I try to disconnect, and reconnect, I see "Connection to the network is taking longer than usual", and I can see broadcast traffic, in Wireshark - but not send/receive unicast traffic; and in order to regain connectivity, I have to disable, and then re-enable my WLAN interface, and then run a connection diagnosis, in order to reset routing.

I never thought that I'd say so, but annoyingly, it hasn't BSoD'd at all, so far - which feels like there's a Heisenbug at play. :(

Tyson.

2015-08-01 20:26 GMT+01:00 Tyson Key <tyson.key@xxxxxxxxx>:
Hmm, this is interesting...

When I removed the old WinPCap, and installed the new NPCap, and then started Wireshark under WinDBG, immediately after, it didn't crash - but at the same time, it didn't detect any interfaces, either.

However, when I rebooted, and tried to start Wireshark under WinDBG, I was able to capture packets from my WLAN adapter (using the Qt UI), and then stop capturing, and then quit the Qt UI, and start the GTK one (under WDBG), and capture from all interfaces, including the NPCap Loopback - at the cost of my Internet connection being knocked out, for some unknown reason:

Pinging 192.168.1.1 with 32 bytes of data:
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.

Ping statistics for 192.168.1.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)

In both cases, I didn't receive any BSoD, or general signs of slowness, or instability (although I didn't stress things hard, and only captured a total of about 3000 packets). (I haven't tried capturing without running Wireshark in the debugger, yet).

This is what gets loaded:

ModLoad: 00007ff8`5acc0000 00007ff8`5ace0000 C:\WINDOWS\SYSTEM32\CRYPTSP.dll
ModLoad: 00007ff8`5a8e0000 00007ff8`5a916000 C:\WINDOWS\system32\rsaenh.dll
ModLoad: 00007ff8`5af60000 00007ff8`5af86000 C:\WINDOWS\SYSTEM32\bcrypt.dll
Application "\??\C:\Program Files\Wireshark\gspawn-win64-helper.exe" found in cache
Application "\??\C:\Program Files\Wireshark\dumpcap.exe" found in cache
Application "\??\C:\Program Files\Wireshark\dumpcap.exe" found in cache
Application "\??\C:\Program Files\Wireshark\dumpcap.exe" found in cache
Application "\??\C:\Program Files\Wireshark\dumpcap.exe" found in cache
Application "\??\C:\Program Files\Wireshark\dumpcap.exe" found in cache
Application "\??\C:\Program Files\Wireshark\dumpcap.exe" found in cache
Application "\??\C:\Program Files\Wireshark\dumpcap.exe" found in cache
Application "\??\C:\Program Files\Wireshark\dumpcap.exe" found in cache
Application "\??\C:\Program Files\Wireshark\dumpcap.exe" found in cache
ModLoad: 00007ff8`5ad20000 00007ff8`5ad2c000 C:\WINDOWS\SYSTEM32\Secur32.dll
ModLoad: 00007ff8`5b270000 00007ff8`5b29e000 C:\WINDOWS\SYSTEM32\SSPICLI.DLL
ModLoad: 00007ff8`58d70000 00007ff8`58d7c000 C:\WINDOWS\SYSTEM32\ondemandconnroutehelper.dll
ModLoad: 00007ff8`53650000 00007ff8`53719000 C:\WINDOWS\SYSTEM32\winhttp.dll
ModLoad: 00007ff8`5a440000 00007ff8`5a4a2000 C:\windows\system32\nuragoLSPService64.DLL
ModLoad: 00007ff8`5ac60000 00007ff8`5acb9000 C:\WINDOWS\SYSTEM32\MSWSOCK.dll
ModLoad: 00007ff8`55e90000 00007ff8`55ea6000 C:\WINDOWS\SYSTEM32\dhcpcsvc6.DLL
ModLoad: 00007ff8`560a0000 00007ff8`560ba000 C:\WINDOWS\SYSTEM32\dhcpcsvc.DLL
ModLoad: 00007ff8`54e10000 00007ff8`54f95000 C:\WINDOWS\SYSTEM32\urlmon.dll
ModLoad: 00007ff8`52f70000 00007ff8`52f88000 C:\windows\system32\wlidnsp.dll
ModLoad: 00007ff8`59fd0000 00007ff8`59fda000 C:\WINDOWS\SYSTEM32\DPAPI.DLL
ModLoad: 00000000`65d50000 00000000`65d76000 C:\Program Files\Bonjour\mdnsNSP.dll
ModLoad: 00007ff8`52f60000 00007ff8`52f6a000 C:\Windows\System32\rasadhlp.dll
(1ffc.2544): C++ EH exception - code e06d7363 (first chance)
(1ffc.2544): C++ EH exception - code e06d7363 (first chance)
(1ffc.2544): C++ EH exception - code e06d7363 (first chance)

Unsure of why the Nurago/Gacela LSP is still being loaded, despite supposedly no longer being installed, though. In order to restore network connectivity, I had to disable the "NPcap Loopback Adapter", and a vestigial "KM-TEST Loopback Adaptor", and reboot my PC, though.

Tyson.

2015-08-01 17:22 GMT+01:00 Tyson Key <tyson.key@xxxxxxxxx>:
Also found this, in a dumpcap MiniDump:

Microsoft (R) Windows Debugger Version 6.3.9600.17336 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [C:\MiniDumps\072715-31968-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred SRV*C:\Symbols\*http://msdl.microsoft.com/download/symbols
Symbol search path is: SRV*C:\Symbols\*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 8 Kernel Version 9600 MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 9600.17736.amd64fre.winblue_r9.150322-1500
Machine Name:
Kernel base = 0xfffff801`0668c000 PsLoadedModuleList = 0xfffff801`06965850
Debug session time: Mon Jul 27 19:02:32.113 2015 (UTC + 1:00)
System Uptime: 0 days 0:15:05.990
Loading Kernel Symbols
.

Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads that take too long.
Run !sym noisy before .reload to track down problems loading symbols.

..............................................................
................................................................
................................................................
......
Loading User Symbols
Loading unloaded module list
.......................
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 3B, {c0000005, fffff8011be5d485, ffffd0002324e980, 0}

*** WARNING: Unable to verify timestamp for npf.sys
*** ERROR: Module load completed but symbols could not be loaded for npf.sys
Probably caused by : npf.sys ( npf+26b9 )

Followup: MachineOwner
---------

3: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

SYSTEM_SERVICE_EXCEPTION (3b)
An exception happened while executing a system service routine.
Arguments:
Arg1: 00000000c0000005, Exception code that caused the bugcheck
Arg2: fffff8011be5d485, Address of the instruction which caused the bugcheck
Arg3: ffffd0002324e980, Address of the context record for the exception that caused the bugcheck
Arg4: 0000000000000000, zero.

Debugging Details:
------------------

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

FAULTING_IP:
ndis!NdisFOidRequest+79
fffff801`1be5d485 4883b80001000000 cmp qword ptr [rax+100h],0

CONTEXT: ffffd0002324e980 -- (.cxr 0xffffd0002324e980;r)
rax=0000000000026799 rbx=ffffe00015dd60c0 rcx=ffffe00017b809e0
rdx=ffffe00015dd60c0 rsi=00000000c0000001 rdi=ffffe00017b809e0
rip=fffff8011be5d485 rsp=ffffd0002324f3b0 rbp=ffffe00015dd6070
r8=0000000000000000 r9=0000000000000000 r10=0000000000000801
r11=ffffd0002324f420 r12=ffffe000161aac90 r13=ffffe000174edd90
r14=ffffe00015dd60c0 r15=ffffe00015dd6078
iopl=0 nv up ei pl zr na po nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010246
ndis!NdisFOidRequest+0x79:
fffff801`1be5d485 4883b80001000000 cmp qword ptr [rax+100h],0 ds:002b:00000000`00026899=????????????????
Last set context:
rax=0000000000026799 rbx=ffffe00015dd60c0 rcx=ffffe00017b809e0
rdx=ffffe00015dd60c0 rsi=00000000c0000001 rdi=ffffe00017b809e0
rip=fffff8011be5d485 rsp=ffffd0002324f3b0 rbp=ffffe00015dd6070
r8=0000000000000000 r9=0000000000000000 r10=0000000000000801
r11=ffffd0002324f420 r12=ffffe000161aac90 r13=ffffe000174edd90
r14=ffffe00015dd60c0 r15=ffffe00015dd6078
iopl=0 nv up ei pl zr na po nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010246
ndis!NdisFOidRequest+0x79:
fffff801`1be5d485 4883b80001000000 cmp qword ptr [rax+100h],0 ds:002b:00000000`00026899=????????????????
Resetting default scope

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: 0x3B

PROCESS_NAME: dumpcap.exe

CURRENT_IRQL: 0

ANALYSIS_VERSION: 6.3.9600.17336 (debuggers(dbg).150226-1500) amd64fre

LAST_CONTROL_TRANSFER: from fffff8011cb606b9 to fffff8011be5d485

STACK_TEXT:
ffffd000`2324f3b0 fffff801`1cb606b9 : ffffe000`15dd6098 ffffe000`15dd6000 ffffe000`15dd6098 ffffe000`15dd6000 : ndis!NdisFOidRequest+0x79
ffffd000`2324f470 ffffe000`15dd6098 : ffffe000`15dd6000 ffffe000`15dd6098 ffffe000`15dd6000 ffffe000`161aad28 : npf+0x26b9
ffffd000`2324f478 ffffe000`15dd6000 : ffffe000`15dd6098 ffffe000`15dd6000 ffffe000`161aad28 ffffe000`1a182210 : 0xffffe000`15dd6098
ffffd000`2324f480 ffffe000`15dd6098 : ffffe000`15dd6000 ffffe000`161aad28 ffffe000`1a182210 ffffe000`161aac90 : 0xffffe000`15dd6000
ffffd000`2324f488 ffffe000`15dd6000 : ffffe000`161aad28 ffffe000`1a182210 ffffe000`161aac90 fffff801`1cb609c0 : 0xffffe000`15dd6098
ffffd000`2324f490 ffffe000`161aad28 : ffffe000`1a182210 ffffe000`161aac90 fffff801`1cb609c0 ffffe000`16c102e0 : 0xffffe000`15dd6000
ffffd000`2324f498 ffffe000`1a182210 : ffffe000`161aac90 fffff801`1cb609c0 ffffe000`16c102e0 ffffe000`16c103b0 : 0xffffe000`161aad28
ffffd000`2324f4a0 ffffe000`161aac90 : fffff801`1cb609c0 ffffe000`16c102e0 ffffe000`16c103b0 ffffe000`15dd6000 : 0xffffe000`1a182210
ffffd000`2324f4a8 fffff801`1cb609c0 : ffffe000`16c102e0 ffffe000`16c103b0 ffffe000`15dd6000 ffffe000`174edee0 : 0xffffe000`161aac90
ffffd000`2324f4b0 ffffe000`16c102e0 : ffffe000`16c103b0 ffffe000`15dd6000 ffffe000`174edee0 ffffe000`16c102e0 : npf+0x29c0
ffffd000`2324f4b8 ffffe000`16c103b0 : ffffe000`15dd6000 ffffe000`174edee0 ffffe000`16c102e0 fffff801`06aaedd1 : 0xffffe000`16c102e0
ffffd000`2324f4c0 ffffe000`15dd6000 : ffffe000`174edee0 ffffe000`16c102e0 fffff801`06aaedd1 00000000`000000a5 : 0xffffe000`16c103b0
ffffd000`2324f4c8 ffffe000`174edee0 : ffffe000`16c102e0 fffff801`06aaedd1 00000000`000000a5 ffffd000`2324f7e1 : 0xffffe000`15dd6000
ffffd000`2324f4d0 ffffe000`16c102e0 : fffff801`06aaedd1 00000000`000000a5 ffffd000`2324f7e1 00000000`00000000 : 0xffffe000`174edee0
ffffd000`2324f4d8 fffff801`06aaedd1 : 00000000`000000a5 ffffd000`2324f7e1 00000000`00000000 00000000`00000040 : 0xffffe000`16c102e0
ffffd000`2324f4e0 fffff801`06b35dc4 : 00000000`00000000 00000000`00000000 ffffe000`174edd60 ffffe000`174edd60 : nt!IopParseDevice+0x6c1
ffffd000`2324f700 fffff801`06ac36b3 : 00000000`00000000 ffffd000`2324f8a8 00000000`00000040 ffffe000`153eca90 : nt!ObpLookupObjectName+0x784
ffffd000`2324f830 fffff801`06adc4db : 00000000`00000001 ffffe000`1a1822a8 00000000`00000001 00000000`00000020 : nt!ObOpenObjectByName+0x1e3
ffffd000`2324f960 fffff801`06adc15c : 00000017`feefcbb8 00000000`c0100080 00000017`feefcc10 ffffe000`1646e080 : nt!IopCreateFile+0x36b
ffffd000`2324fa00 fffff801`067e84b3 : ffffe000`1a537080 ffffd000`2324fb80 ffffd000`2324faa8 00000017`feefcb60 : nt!NtCreateFile+0x78
ffffd000`2324fa90 00007ff8`1110171a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000017`feefcb38 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ff8`1110171a

FOLLOWUP_IP:
npf+26b9
fffff801`1cb606b9 ?? ???

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: npf+26b9

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: npf

IMAGE_NAME: npf.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 55b5ffcd

STACK_COMMAND: .cxr 0xffffd0002324e980 ; kb

FAILURE_BUCKET_ID: 0x3B_npf+26b9

BUCKET_ID: 0x3B_npf+26b9

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:0x3b_npf+26b9

FAILURE_ID_HASH: {3d7b38a9-fc4b-1ac1-803d-31b7fb0e6e7f}

Followup: MachineOwner
---------

2015-08-01 16:07 GMT+01:00 Tyson Key <tyson.key@xxxxxxxxx>:
Hi Yang,

Not sure if these are any use, since I'm still downloading various symbols, but I've just started looking at some MiniDumps, and spotted these:

Microsoft (R) Windows Debugger Version 6.3.9600.17336 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [C:\Windows\Minidump\072715-48062-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred SRV*C:\Symbols\*http://msdl.microsoft.com/download/symbols
Symbol search path is: SRV*C:\Symbols\*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 8 Kernel Version 9600 MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 9600.17736.amd64fre.winblue_r9.150322-1500
Machine Name:
Kernel base = 0xfffff801`03606000 PsLoadedModuleList = 0xfffff801`038df850
Debug session time: Mon Jul 27 17:00:25.098 2015 (UTC + 1:00)
System Uptime: 0 days 0:49:51.971
Loading Kernel Symbols
.

Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads that take too long.
Run !sym noisy before .reload to track down problems loading symbols.

..............................................................
................................................................
................................................................
......
Loading User Symbols
Loading unloaded module list
......................
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck C2, {7, 1200, 0, ffffe0004bc1b4c8}

GetPointerFromAddress: unable to read from fffff80103969138
unable to get nt!MmNonPagedPoolStart
unable to get nt!MmSizeOfNonPagedPoolInBytes
Probably caused by : NETIO.SYS ( NETIO!NetioCompleteCloneNetBufferListChain+1508d )

Followup: MachineOwner
---------

0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

BAD_POOL_CALLER (c2)
The current thread is making a bad pool request. Typically this is at a bad IRQL level or double freeing the same allocation, etc.
Arguments:
Arg1: 0000000000000007, Attempt to free pool which was already freed
Arg2: 0000000000001200, (reserved)
Arg3: 0000000000000000, Memory contents of the pool block
Arg4: ffffe0004bc1b4c8, Address of the block of pool being deallocated

Debugging Details:
------------------

POOL_ADDRESS: ffffe0004bc1b4c8

FREED_POOL_TAG: NDnd

BUGCHECK_STR: 0xc2_7_NDnd

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

PROCESS_NAME: Asset-uPNP.exe

CURRENT_IRQL: 2

ANALYSIS_VERSION: 6.3.9600.17336 (debuggers(dbg).150226-1500) amd64fre

LAST_CONTROL_TRANSFER: from fffff801038aaff2 to fffff80103756ca0

STACK_TEXT:
ffffd000`5e10ef88 fffff801`038aaff2 : 00000000`000000c2 00000000`00000007 00000000`00001200 00000000`00000000 : nt!KeBugCheckEx
ffffd000`5e10ef90 fffff800`7482f83d : 00000000`00000000 ffffe000`47728040 000008fe`00000010 00000014`00000000 : nt!ExAllocatePoolWithTag+0x1102
ffffd000`5e10f080 fffff800`748013f1 : 00000000`00000000 ffffe000`46f0a250 00000000`00000000 00000000`00000000 : NETIO!NetioCompleteCloneNetBufferListChain+0x1508d
ffffd000`5e10f0f0 fffff800`74d28c18 : fffff800`74866228 00000000`00000001 00000000`00000000 00000000`00000000 : NETIO!NetioDereferenceNetBufferListChain+0x2d1
ffffd000`5e10f190 fffff800`74cfe18c : ffffe000`4b554b7c 00000000`000490ce 00000000`00000000 00000000`00000000 : tcpip!TcpFlushDelay+0x88
ffffd000`5e10f240 fffff800`74d33f9f : ffffe000`476c8940 ffffd000`5e100d66 ffffd000`5e1087c2 ffffe000`477287c2 : tcpip!TcpPreValidatedReceive+0x3cc
ffffd000`5e10f340 fffff800`74d30143 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : tcpip!IppDeliverListToProtocol+0x4f
ffffd000`5e10f400 fffff800`74d2e525 : 00000000`00000000 00000000`00000000 00000000`00000000 ffffd000`5e10f508 : tcpip!IppProcessDeliverList+0x63
ffffd000`5e10f4a0 fffff800`74ce6c9d : 00000000`00000000 00000000`00000000 00000000`00000000 ffffd000`5e10f6b8 : tcpip!IppReceiveHeaderBatch+0x235
ffffd000`5e10f5d0 fffff800`74ce61cc : ffffd000`5e10f6e0 00000000`00000000 ffffe000`49cc7040 ffffd000`5e10f820 : tcpip!IppLoopbackIndicatePackets+0x39d
ffffd000`5e10f6b0 fffff800`74d03eb8 : ffffe000`4cd20190 346dc5d6`38865900 ffffd000`5e10f8e0 00000000`00000000 : tcpip!IppLoopbackEnqueue+0x3dc
ffffd000`5e10f7e0 fffff800`74d03389 : fffff800`74e7e180 00000000`00000000 00000000`00000000 00000000`00000000 : tcpip!IppDispatchSendPacketHelper+0x398
ffffd000`5e10f970 fffff800`74d0191e : ffff0014`00000001 ffffe000`4769bb28 00000000`00000002 ffffd000`5e10fdc0 : tcpip!IppPacketizeDatagrams+0x2d9
ffffd000`5e10fb10 fffff800`74d06ab7 : fffff800`74cc74f0 00000000`00000007 fffff800`74e7e180 ffffe000`4ce29010 : tcpip!IppSendDatagramsCommon+0x49e
ffffd000`5e10fcf0 fffff800`74cfc435 : ffffd000`5e1100d2 00000000`00000000 ffffe000`48afd280 ffffd000`5e1103f0 : tcpip!TcpTcbSend+0x55b
ffffd000`5e110040 fffff800`74cfc07c : 00000000`000490ce ffffe000`4ce29010 ffffd000`5e1100d1 ffffd000`5e110300 : tcpip!TcpEnqueueTcbSendOlmNotifySendComplete+0xa5
ffffd000`5e110070 fffff800`74cfc538 : 00000000`00000000 00000000`00000000 ffffe000`4b563500 00000000`00000000 : tcpip!TcpEnqueueTcbSend+0x2ac
ffffd000`5e110170 fffff801`03678703 : 00000000`00000000 00000000`00000001 00000000`00000000 00000000`00000000 : tcpip!TcpTlConnectionSendCalloutRoutine+0x28
ffffd000`5e1101f0 fffff800`74cfc7f6 : fffff800`74cfc510 ffffd000`5e110310 ffffe000`4bf7a600 fffff800`7572d7ab : nt!KeExpandKernelStackAndCalloutInternal+0xf3
ffffd000`5e1102e0 fffff800`75747b97 : ffffe000`4b563560 ffffd000`5e110b80 00000000`00000a71 00000000`000000b8 : tcpip!TcpTlConnectionSend+0x76
ffffd000`5e110350 fffff800`7572c450 : ffffe000`4bd1cc30 00000000`00000000 00000000`00000000 00000000`00000001 : afd!AfdFastConnectionSend+0x387
ffffd000`5e110510 fffff801`03a2b27c : 00000000`00000000 ffffe000`470358d0 ffffe000`478442e0 00000000`00000001 : afd!AfdFastIoDeviceControl+0x440
ffffd000`5e110880 fffff801`03a2ad22 : ffffe000`4cb3f880 0000000c`001f0003 00000000`00000001 00000000`00000000 : nt!IopXxxControlFile+0x54c
ffffd000`5e110a20 fffff801`037624b3 : fffff6fb`7dbed000 fffff6fb`7da00000 fffff6fb`40000098 fffff680`00013438 : nt!NtDeviceIoControlFile+0x56
ffffd000`5e110a90 00000000`76f32352 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`01ecf128 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x76f32352

STACK_COMMAND: kb

FOLLOWUP_IP:
NETIO!NetioCompleteCloneNetBufferListChain+1508d
fffff800`7482f83d 90 nop

SYMBOL_STACK_INDEX: 2

SYMBOL_NAME: NETIO!NetioCompleteCloneNetBufferListChain+1508d

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: NETIO

IMAGE_NAME: NETIO.SYS

DEBUG_FLR_IMAGE_TIMESTAMP: 540ebbe6

IMAGE_VERSION: 6.3.9600.17337

BUCKET_ID_FUNC_OFFSET: 1508d

FAILURE_BUCKET_ID: 0xc2_7_NDnd_NETIO!NetioCompleteCloneNetBufferListChain

BUCKET_ID: 0xc2_7_NDnd_NETIO!NetioCompleteCloneNetBufferListChain

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:0xc2_7_ndnd_netio!netiocompleteclonenetbufferlistchain

FAILURE_ID_HASH: {ec09700b-3916-f849-b5d5-75c2ba7b02db}

Followup: MachineOwner
---------

Microsoft (R) Windows Debugger Version 6.3.9600.17336 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [C:\Windows\Minidump\072815-328875-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred SRV*C:\Symbols\*http://msdl.microsoft.com/download/symbols
Symbol search path is: SRV*C:\Symbols\*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 8 Kernel Version 9600 MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 9600.17736.amd64fre.winblue_r9.150322-1500
Machine Name:
Kernel base = 0xfffff800`0ce07000 PsLoadedModuleList = 0xfffff800`0d0e0850
Debug session time: Tue Jul 28 16:30:31.391 2015 (UTC + 1:00)
System Uptime: 0 days 0:07:03.265
Loading Kernel Symbols
.

Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads that take too long.
Run !sym noisy before .reload to track down problems loading symbols.

..............................................................
................................................................
..............................................................
Loading User Symbols
Loading unloaded module list
....................
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck C2, {7, 1200, 117ec1, ffffe0015aeeaec8}

GetPointerFromAddress: unable to read from fffff8000d16a138
unable to get nt!MmNonPagedPoolStart
unable to get nt!MmSizeOfNonPagedPoolInBytes
Probably caused by : NETIO.SYS ( NETIO!NetioCompleteCloneNetBufferListChain+1508d )

Followup: MachineOwner
---------

2: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

BAD_POOL_CALLER (c2)
The current thread is making a bad pool request. Typically this is at a bad IRQL level or double freeing the same allocation, etc.
Arguments:
Arg1: 0000000000000007, Attempt to free pool which was already freed
Arg2: 0000000000001200, (reserved)
Arg3: 0000000000117ec1, Memory contents of the pool block
Arg4: ffffe0015aeeaec8, Address of the block of pool being deallocated

Debugging Details:
------------------

POOL_ADDRESS: ffffe0015aeeaec8

FREED_POOL_TAG: NDnd

BUGCHECK_STR: 0xc2_7_NDnd

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

PROCESS_NAME: svchost.exe

CURRENT_IRQL: 2

ANALYSIS_VERSION: 6.3.9600.17336 (debuggers(dbg).150226-1500) amd64fre

LAST_CONTROL_TRANSFER: from fffff8000d0abff2 to fffff8000cf57ca0

STACK_TEXT:
ffffd000`9bba4ba8 fffff800`0d0abff2 : 00000000`000000c2 00000000`00000007 00000000`00001200 00000000`00117ec1 : nt!KeBugCheckEx
ffffd000`9bba4bb0 fffff801`14a2f83d : 00000000`00000000 ffffe001`5a593040 000008fe`00000010 00000014`00000011 : nt!ExAllocatePoolWithTag+0x1102
ffffd000`9bba4ca0 fffff801`14a013f1 : 00000000`00000000 ffffe001`59b5b600 00000000`00000000 00000000`00000000 : NETIO!NetioCompleteCloneNetBufferListChain+0x1508d
ffffd000`9bba4d10 fffff801`14d2bc18 : fffff801`14a66228 00000000`00000001 00000000`00000000 00000000`00000000 : NETIO!NetioDereferenceNetBufferListChain+0x2d1
ffffd000`9bba4db0 fffff801`14d0118c : ffffe001`5de21fcc 00000000`0000a567 00000000`00000000 00000000`00000000 : tcpip!TcpFlushDelay+0x88
ffffd000`9bba4e60 fffff801`14d36f9f : ffffe001`5a527d80 ffffd000`9bba350b ffffd000`9bba81c1 ffffe001`5a4f81c1 : tcpip!TcpPreValidatedReceive+0x3cc
ffffd000`9bba4f60 fffff801`14d33143 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : tcpip!IppDeliverListToProtocol+0x4f
ffffd000`9bba5020 fffff801`14d31525 : 00000000`00000000 00000000`00000000 00000000`00000000 ffffd000`9bba5128 : tcpip!IppProcessDeliverList+0x63
ffffd000`9bba50c0 fffff801`14ce9c9d : 00000000`00000000 00000000`00000000 00000000`00000000 ffffd000`9bba52d8 : tcpip!IppReceiveHeaderBatch+0x235
ffffd000`9bba51f0 fffff801`14ce91cc : ffffd000`9bba5300 00000000`00000000 ffffe001`5cdfa540 ffffd000`9bba5440 : tcpip!IppLoopbackIndicatePackets+0x39d
ffffd000`9bba52d0 fffff801`14d06eb8 : ffffe001`59e84600 346dc5d6`38865900 ffffd000`9bba5500 00000000`00000000 : tcpip!IppLoopbackEnqueue+0x3dc
ffffd000`9bba5400 fffff801`14d06389 : fffff801`14e81180 00000000`00000000 00000000`00000000 00000000`00000000 : tcpip!IppDispatchSendPacketHelper+0x398
ffffd000`9bba5590 fffff801`14d0491e : ffff0014`00000001 ffffe001`5a4bc568 00000000`00000002 ffffd000`9bba59e0 : tcpip!IppPacketizeDatagrams+0x2d9
ffffd000`9bba5730 fffff801`14d09ab7 : fffff801`14cca4f0 00000000`00000007 fffff801`14e81180 ffffe001`5c76f8c0 : tcpip!IppSendDatagramsCommon+0x49e
ffffd000`9bba5910 fffff801`14cff435 : ffffd000`9bba5cf2 00000000`00000000 ffffe001`5caff550 ffffd000`9bba5f90 : tcpip!TcpTcbSend+0x55b
ffffd000`9bba5c60 fffff801`14cff07c : 00000000`0000a567 ffffe001`5c76f8c0 ffffd000`9bba5cf1 ffffd000`9bba5f00 : tcpip!TcpEnqueueTcbSendOlmNotifySendComplete+0xa5
ffffd000`9bba5c90 fffff801`14cff538 : ffffc001`5b0b1b02 00000000`00000000 ffffe001`5dbf5100 00000000`0ce5a000 : tcpip!TcpEnqueueTcbSend+0x2ac
ffffd000`9bba5d90 fffff800`0ce79703 : ffffe001`5dbf51e0 fffff801`14cff7f6 fffff801`14cff510 ffffd000`9bba5e50 : tcpip!TcpTlConnectionSendCalloutRoutine+0x28
ffffd000`9bba5e10 fffff801`14cff7f6 : fffff801`14cff510 ffffd000`9bba5f30 ffffc001`5b0b1e00 00000000`00000000 : nt!KeExpandKernelStackAndCalloutInternal+0xf3
ffffd000`9bba5f00 fffff801`15402ecf : ffffe001`5dbf51e0 ffffe001`59f3c4c0 00000000`00000000 ffffe001`5db660c0 : tcpip!TcpTlConnectionSend+0x76
ffffd000`9bba5f70 fffff801`184e7860 : ffffe001`5c7b9cb0 00000000`00000002 ffffe001`5db660c0 ffffe001`5c75b050 : afd!WskProIRPSend+0xbf
ffffd000`9bba5fe0 fffff801`184e647c : 00000000`ffffffff ffffe001`59fc96f8 00000580`00000000 fffffa80`001ca790 : HTTP!UxTlInitiateSend+0x1e0
ffffd000`9bba60a0 fffff801`1855b0ea : ffffe001`59fc96f8 00000000`00000000 00000000`00000001 00000000`00000000 : HTTP!UxpTpFastTransmit+0x19c
ffffd000`9bba6140 fffff801`184e7cad : ffffe001`59fc9420 fffff801`184e64ff 00000000`00000000 ffffe001`58ef53b0 : HTTP!UxTpTransmitPacket+0xba
ffffd000`9bba61e0 fffff801`18559bbf : 00000000`00000000 00000000`00000000 fffff801`18536ae0 ffffe001`58ef53b0 : HTTP!UlSendData+0xdd
ffffd000`9bba6270 fffff801`18574a7f : 00000000`00000000 fffff801`18536ae0 ffffe001`5a211850 ffffe001`5a211850 : HTTP!UlFastSendHttpResponse+0x1765
ffffd000`9bba6500 fffff801`184e42b8 : 00000000`00124043 fffff801`1854c180 00000000`00000020 ffffe001`5a2119f8 : HTTP!UlSendEntityBodyIoctl+0xd2f
ffffd000`9bba6840 fffff800`0d22c77f : 00000000`00000000 ffffd000`9bba6b80 ffffe001`5a211850 00000000`00000004 : HTTP!UlDeviceControl+0x78
ffffd000`9bba6880 fffff800`0d22bd22 : ffffd000`9bba6a38 00000000`00000000 00000000`00000000 00000000`00000000 : nt!IopXxxControlFile+0xa4f
ffffd000`9bba6a20 fffff800`0cf634b3 : ffffe001`58edf080 00000000`001f0003 00000031`01acf0f8 00000000`00000001 : nt!NtDeviceIoControlFile+0x56
ffffd000`9bba6a90 00007ff8`24c3123a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000031`01ace928 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ff8`24c3123a

STACK_COMMAND: kb

FOLLOWUP_IP:
NETIO!NetioCompleteCloneNetBufferListChain+1508d
fffff801`14a2f83d 90 nop

SYMBOL_STACK_INDEX: 2

SYMBOL_NAME: NETIO!NetioCompleteCloneNetBufferListChain+1508d

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: NETIO

IMAGE_NAME: NETIO.SYS

DEBUG_FLR_IMAGE_TIMESTAMP: 540ebbe6

IMAGE_VERSION: 6.3.9600.17337

BUCKET_ID_FUNC_OFFSET: 1508d

FAILURE_BUCKET_ID: 0xc2_7_NDnd_NETIO!NetioCompleteCloneNetBufferListChain

BUCKET_ID: 0xc2_7_NDnd_NETIO!NetioCompleteCloneNetBufferListChain

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:0xc2_7_ndnd_netio!netiocompleteclonenetbufferlistchain

FAILURE_ID_HASH: {ec09700b-3916-f849-b5d5-75c2ba7b02db}

Followup: MachineOwner
---------

However, they seem to correlate with your debugging from earlier...

Tyson.

2015-08-01 14:30 GMT+01:00 Tyson Key <tyson.key@xxxxxxxxx>:
Hi Yang,

Thanks for looking at this. I've just enabled full memory dumps, after reading https://support.microsoft.com/en-us/kb/969028 - but I'll need to do the Right Ctrl + Scroll Lock X2 trick at a time when I can afford to lose state data.

I've got the Windows SDK installed (but not the WinDBG?), if I remember correctly - but I'll install the symbols, and WDK, when I get time. In the meantime, since I've got a %SystemRoot%\MEMORY.DMP file from some crash, but don't know how big it is (since I now have 6GB of RAM, and probably only had 4GB, when it was generated - assuming that "automatic" dumps are "full" dumps), I guess that I've got something to practice post-mortem on...

Tyson.

2015-08-01 4:18 GMT+01:00 Yang Luo <hsluoyb@xxxxxxxxx>:
Hi Tyson,

I think I have reproduced the BAD_POOL_CALLER error, the step is: 1) reboot the system, 2) start Wireshark UI, 3) Open VMware Workstation. As you installed VMware Player, maybe it's the same reason. I will look into this later. And I found that a full dump file (memory.dmp) has more useful information (the error position in Npcap driver) than a minidump, so if you can provide full dumps, it will be better. A simpler way is you open the full dump file by yourself using WinDBG (with suitable symbols) and type in "!analyze -v", and then paste the output in this thread, so you don't need to upload such a big dump file.

Get WinDBG:
https://msdn.microsoft.com/en-us/windows/hardware/hh852365.aspx?f=255&MSPPError=-2147217396

Get Windows symbols:
https://msdn.microsoft.com/en-us/windows/hardware/gg463028.aspx

Cheers,
Yang

On Tue, Jul 28, 2015 at 11:09 PM, Tyson Key <tyson.key@xxxxxxxxx> wrote:
Aah, I had a look at "Programs, and Features", and it says that the AppEx thing is "AMD Quick Stream" 3.4.4.0, published by AppEx Networks, of Beijing (http://www.appexnetworks.com.cn/). I found a marketing document regarding it at http://support.amd.com/en-us/kb-articles/Pages/AMDQuickStreamTechnology.aspx.

Tyson.

2015-07-28 16:03 GMT+01:00 Tyson Key <tyson.key@xxxxxxxxx>:
Hi Yang,

Thanks for looking at these dumps.

Yup, I think I enabled the verifier, a few months ago, whilst trying to debug some other issue (probably related to the AppEx thing), and I forgot that I kept it enabled.

As for the dumpcap arguments, I just let Wireshark invoke it, through the GUI - so the arguments are whatever it spits out by default, to set up various pipes. I'd have to surgically remove NPCap, and replace it with regular WinPCap, and then try to trace Wireshark Qt/GTK, to learn the arguments (or see if "tasklist /V", or some other utility reveals them). I'd expect that they'd look similar to the ones issued under Linux, modulo device names, though.

I'm kinda surprised that Asset is responsible for some of the crashes, to be honest. Sure, it does funny things with multicasting, as a UPnP server implementation, but it's usually pretty reliable, in general operation. Might be worth me reporting a bug to Illustrate, when I get chance; and I'll see what happens if I uninstall it, in the meantime.

As for AppEx, I'm pretty sure that I removed its driver from all of my interfaces, but I wouldn't be surprised if there's not something vestigial. Going to see if I can fully cleanse it from my system, since it was an OEM-supplied product, and not something that I opted to install. (And I've had BSoDs from it before, whilst trying to diagnose some WLAN problems). I think it's supposed to be some sort of "game/multimedia quality-of-service optimisation" tool.

Take care,

Tyson.

2015-07-28 12:41 GMT+01:00 Yang Luo <hsluoyb@xxxxxxxxx>:
Hi Tyson,

I have analyzed the five dumps you provided:

1) 072715-32078-01.dmp
This dump is caused by nt!VerifierBugCheckIfAppropriate+0x3c code from process svchost.exe, and it seems to be that you switched on Verifier function for your system. I think there's no relationship with Npcap.

2) 072715-31968-01.dmp and 072715-32468-01.dmp
this dump provides BSoD about SYSTEM_SERVICE_EXCEPTION. It is caused by ndis!NdisFOidRequest+62 code from process dumpcap.exe. As Npcap uses NdisFOidRequest calls, I think it's possibly a bug. I'd like to know how you used dumpcap.exe, like parameters?

3) 072715-33859-01.dmp and 072715-48062-01.dmp
It is caused by Asset-uPNP.exe, from Asset audio server software provided by illustrate. I think maybe you would like to disable or uninstall it first, to see if the fault still happens. WinDbg also reports that OVERLAPPED_MODULE: Address regions for 'nwifi' and 'appexDrv.sys' overlap. 'appexDrv.sys''s description is " "AppEx Accelerator LWF/WFP Driver L.E."". nwifi.sys seems to be a Microsoft built-in component, and AppEx Networks Accelerator seems to be a VPN software, unfortunately, I didn't find a download link. But this is maybe not the main cause, whatever you can try to shutdown it to see if there's any change.

072715-48062-01.dmp's report is pasted here:

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck C2, {7, 1200, 0, ffffe0008d01cbf8}

fffff80059152240: Unable to get special pool info
fffff80059152240: Unable to get special pool info
unable to get nt!MmPoolCodeStart
unable to get nt!MmPoolCodeEnd
Probably caused by : NETIO.SYS ( NETIO!NetioCompleteCloneNetBufferListChain+1508d )

Followup: MachineOwner
---------

0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

BAD_POOL_CALLER (c2)
The current thread is making a bad pool request. Typically this is at a bad IRQL level or double freeing the same allocation, etc.
Arguments:
Arg1: 0000000000000007, Attempt to free pool which was already freed
Arg2: 0000000000001200, (reserved)
Arg3: 0000000000000000, Memory contents of the pool block
Arg4: ffffe0008d01cbf8, Address of the block of pool being deallocated

Debugging Details:
------------------

OVERLAPPED_MODULE: Address regions for 'nwifi' and 'appexDrv.sys' overlap

POOL_ADDRESS: ffffe0008d01cbf8

FREED_POOL_TAG: NDnd

BUGCHECK_STR: 0xc2_7_NDnd

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

PROCESS_NAME: Asset-uPNP.exe

CURRENT_IRQL: 2

LAST_CONTROL_TRANSFER: from fffff8005912fff2 to fffff80058fdbca0

STACK_TEXT:
ffffd000`27118f88 fffff800`5912fff2 : 00000000`000000c2 00000000`00000007 00000000`00001200 00000000`00000000 : nt!KeBugCheckEx
ffffd000`27118f90 fffff800`3763083d : 00000000`00000000 ffffe000`8d596040 000008fe`00000010 00000014`00000000 : nt!ExAllocatePoolWithTag+0x1102
ffffd000`27119080 fffff800`376023f1 : 00000000`00000000 ffffe000`8ceb3740 00000000`00000000 00000000`00000000 : NETIO!NetioCompleteCloneNetBufferListChain+0x1508d
ffffd000`271190f0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : NETIO!NetioDereferenceNetBufferListChain+0x2d1

STACK_COMMAND: kb

FOLLOWUP_IP:
NETIO!NetioCompleteCloneNetBufferListChain+1508d
fffff800`3763083d 90 nop

SYMBOL_STACK_INDEX: 2

SYMBOL_NAME: NETIO!NetioCompleteCloneNetBufferListChain+1508d

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: NETIO

IMAGE_NAME: NETIO.SYS

DEBUG_FLR_IMAGE_TIMESTAMP: 540ebbe6

FAILURE_BUCKET_ID: X64_0xc2_7_NDnd_NETIO!NetioCompleteCloneNetBufferListChain+1508d

BUCKET_ID: X64_0xc2_7_NDnd_NETIO!NetioCompleteCloneNetBufferListChain+1508d

Followup: MachineOwner
---------

On Tue, Jul 28, 2015 at 3:12 PM, Tyson Key <tyson.key@xxxxxxxxx> wrote:
I just uploaded my MiniDumps to https://dl.dropboxusercontent.com/u/670345/MiniDump.rar, if it makes debugging this easier.

Tyson.

2015-07-28 8:08 GMT+01:00 Tyson Key <tyson.key@xxxxxxxxx>:
Hi Yang,

Thanks for looking into this.

I can't remember when/how I installed Win10PCap (guessing that I briefly had a look, but couldn't get it to do anything on my machine, and just removed it), but I'm using VMware Player 6.0.7 build-2844087 (haven't got Workstation/Server installed); and I tried a dance of upgrading/downgrading/upgrading my AR9485WB-EG WLAN driver (first by downloading the package from http://support.lenovo.com/us/en/downloads/ds032333, to take me from 10.0.0.242, to 10.0.0.75; and then using Device Manager's driver update function, to take me to 3.0.1.155 (which I'm guessing is probably older than 242 - I'm just guessing from the sketchy build dates) - which gave me a different type of BSoD, initially, after starting Wireshark, but let me capture traffic for a little while, after rebooting.

Here's all of the MiniDump summaries that I could find:

==================================================
Dump File : 072715-31968-01.dmp
Crash Time : 27/07/2015 07:02:32 pm
Bug Check String : SYSTEM_SERVICE_EXCEPTION
Bug Check Code : 0x0000003b
Parameter 1 : 00000000`c0000005
Parameter 2 : fffff801`1be5d485
Parameter 3 : ffffd000`2324e980
Parameter 4 : 00000000`00000000
Caused By Driver : ntoskrnl.exe
Caused By Address : ntoskrnl.exe+150ca0
File Description : NT Kernel & System
Product Name : Microsoft® Windows® Operating System
Company : Microsoft Corporation
File Version : 6.3.9600.17736 (winblue_r9.150322-1500)
Processor : x64
Crash Address : ntoskrnl.exe+150ca0
Stack Address 1 :
Stack Address 2 :
Stack Address 3 :
Computer Name :
Full Path : C:\WINDOWS\Minidump\072715-31968-01.dmp
Processors Count : 4
Major Version : 15
Minor Version : 9600
Dump File Size : 281,520
Dump File Time : 27/07/2015 07:03:33 pm
==================================================

==================================================
Dump File : 072715-32078-01.dmp
Crash Time : 27/07/2015 06:47:01 pm
Bug Check String : BAD_POOL_CALLER
Bug Check Code : 0x000000c2
Parameter 1 : 00000000`00000099
Parameter 2 : ffffe000`7d4b31b8
Parameter 3 : 00000000`00000000
Parameter 4 : 00000000`00000000
Caused By Driver : tcpip.sys
Caused By Address : tcpip.sys+42856
File Description : TCP/IP Driver
Product Name : Microsoft® Windows® Operating System
Company : Microsoft Corporation
File Version : 6.3.9600.16384 (winblue_rtm.130821-1623)
Processor : x64
Crash Address : ntoskrnl.exe+150ca0
Stack Address 1 :
Stack Address 2 :
Stack Address 3 :
Computer Name :
Full Path : C:\WINDOWS\Minidump\072715-32078-01.dmp
Processors Count : 4
Major Version : 15
Minor Version : 9600
Dump File Size : 281,520
Dump File Time : 27/07/2015 06:48:04 pm
==================================================

==================================================
Dump File : 072715-32468-01.dmp
Crash Time : 27/07/2015 06:34:37 pm
Bug Check String : SYSTEM_SERVICE_EXCEPTION
Bug Check Code : 0x0000003b
Parameter 1 : 00000000`c0000005
Parameter 2 : fffff801`962a446e
Parameter 3 : ffffd001`1bd0f980
Parameter 4 : 00000000`00000000
Caused By Driver : ndis.sys
Caused By Address : ndis.sys+546e
File Description : Network Driver Interface Specification (NDIS)
Product Name : Microsoft® Windows® Operating System
Company : Microsoft Corporation
File Version : 6.3.9600.16384 (winblue_rtm.130821-1623)
Processor : x64
Crash Address : ntoskrnl.exe+150ca0
Stack Address 1 :
Stack Address 2 :
Stack Address 3 :
Computer Name :
Full Path : C:\WINDOWS\Minidump\072715-32468-01.dmp
Processors Count : 4
Major Version : 15
Minor Version : 9600
Dump File Size : 281,520
Dump File Time : 27/07/2015 06:35:48 pm
==================================================

==================================================
Dump File : 072715-33859-01.dmp
Crash Time : 27/07/2015 05:11:25 pm
Bug Check String : BAD_POOL_CALLER
Bug Check Code : 0x000000c2
Parameter 1 : 00000000`00000007
Parameter 2 : 00000000`00001200
Parameter 3 : 00000000`00000000
Parameter 4 : ffffe000`8d01cbf8
Caused By Driver : ntoskrnl.exe
Caused By Address : ntoskrnl.exe+150ca0
File Description : NT Kernel & System
Product Name : Microsoft® Windows® Operating System
Company : Microsoft Corporation
File Version : 6.3.9600.17736 (winblue_r9.150322-1500)
Processor : x64
Crash Address : ntoskrnl.exe+150ca0
Stack Address 1 :
Stack Address 2 :
Stack Address 3 :
Computer Name :
Full Path : C:\WINDOWS\Minidump\072715-33859-01.dmp
Processors Count : 4
Major Version : 15
Minor Version : 9600
Dump File Size : 281,520
Dump File Time : 27/07/2015 05:12:34 pm
==================================================

==================================================
Dump File : 072715-48062-01.dmp
Crash Time : 27/07/2015 05:00:25 pm
Bug Check String : BAD_POOL_CALLER
Bug Check Code : 0x000000c2
Parameter 1 : 00000000`00000007
Parameter 2 : 00000000`00001200
Parameter 3 : 00000000`00000000
Parameter 4 : ffffe000`4bc1b4c8
Caused By Driver : ntoskrnl.exe
Caused By Address : ntoskrnl.exe+150ca0
File Description : NT Kernel & System
Product Name : Microsoft® Windows® Operating System
Company : Microsoft Corporation
File Version : 6.3.9600.17736 (winblue_r9.150322-1500)
Processor : x64
Crash Address : ntoskrnl.exe+150ca0
Stack Address 1 :
Stack Address 2 :
Stack Address 3 :
Computer Name :
Full Path : C:\WINDOWS\Minidump\072715-48062-01.dmp
Processors Count : 4
Major Version : 15
Minor Version : 9600
Dump File Size : 281,520
Dump File Time : 27/07/2015 05:01:58 pm
==================================================

Frustratingly, since there are so many variables involved (unscientific method!), it seems like I'm playing a Jenga game with trying to make this work, since if I remove, or change something, it works for a little while, and then crashes in a creative, new way. (And I don't want to reinstall everything, since I don't have a disk big enough to back everything up). :(

I've uploaded a copy of the Nurago Web Meter to https://dl.dropboxusercontent.com/u/670345/nurago%20web%20meter.exe, and I seem to also have an older installer for it in my "Downloads" directory, which may exercise the LSP architecture of WinSock differently.

The SYSTEM_SERVICE_EXCEPTION error is interesting, as it is one of the few that reveals a problem in WinSock/NDIS...

I would try it in a virtual machine - but it wouldn't get us any closer to diagnosing why it fails to work, with my not-so-unique configuration.

Tyson.

2015-07-28 7:27 GMT+01:00 Yang Luo <hsluoyb@xxxxxxxxx>:

On Mon, Jul 27, 2015 at 10:42 PM, Tyson Key <tyson.key@xxxxxxxxx> wrote:
After rebooting from uninstalling MS NetMon, I restarted Wireshark, and got the usual "NPF service not running; no interfaces available" note. This persists, even if I try "NPFInstall -r", and Wireshark still claims that no interfaces are available.

"NPFInstall -r" isn't used in Npcap. "NPF service not running; no interfaces available" is a common problem for Npcap previous versions. And I think it should disappear if you have uninstalled previous versions totally.

Eventually, after uninstalling NPCap, removing all of the loopback interfaces, and running CCleaner to remove any residual registry data, and then rebooting yet again, I could start Wireshark, and list the installed interfaces - but unsurprisingly, a few moments later, I received another BSoD.

If it helps, my Wireshark version is:

Version 1.99.8-492-g3f0f49d (v1.99.8rc0-492-g3f0f49d from master)

Copyright 1998-2015 Gerald Combs <gerald@xxxxxxxxxxxxx> and contributors.
License GPLv2+: GNU GPL version 2 or later <http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (64-bit) with GTK+ 2.24.23, with Cairo 1.12.16, with Pango 1.36.8, with
WinPcap (unknown), with libz 1.2.8, with GLib 2.42.0, with SMI 0.4.8, with
c-ares 1.9.1, with Lua 5.2, with GnuTLS 3.2.15, with Gcrypt 1.6.2, with MIT
Kerberos, with GeoIP, with PortAudio V19-devel (built Jul 22 2015), with
AirPcap.

Running on 64-bit Windows 8.1, build 9600, with locale English_United
Kingdom.1252, with Npcap version 0.01 (packet.dll version 0.03), based on
WinPcap version 4.1.3 (packet.dll version 4.1.0.3001), based on libpcap version
1.0 branch 1_0_rel0b (20091008), with GnuTLS 3.2.15, with Gcrypt 1.6.2, without
AirPcap.
AMD A6-5200 APU with Radeon(TM) HD Graphics (with SSE4.2), with 5577MB of
physical memory.

Built using Microsoft Visual C++ 12.0 build 31101

Wireshark is Open Source Software released under the GNU General Public License.

Check the man page and http://www.wireshark.org for more information.

I used Wireshark latest stable version: Version 1.12.6 (v1.12.6-0-gee1fce6 from master-1.12). But I don't think it makes a difference by using stable version or development version, as its WinPcap related low-level code rarely changed between these two versions.

Other than NetMon (which I've removed), the only other things that I think could be causing a conflict are either the VMware host-only networking filters; the networking components included with whatever Bluetooth stack Lenovo shipped; the massive pile of hacks installed by the Gacela component of "Nurago Web Meter", or my Atheros WLAN drivers (which caused Acrylic Wi-Fi's NDIS filters to crash, when I briefly had that installed, a while ago).

What version VMware are you using? Workstation or just Player? I used VMware Workstation 11.1.2 build-2780323 on my host, but I didn't install it on my test VM yet.

Cheers,
Yang

___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

--
Fight Internet Censorship! http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon | 00447934365844

--
Fight Internet Censorship! http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon | 00447934365844

___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

--
Fight Internet Censorship! http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon | 00447934365844

--
Fight Internet Censorship! http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon | 00447934365844

___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

--
Fight Internet Censorship! http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon | 00447934365844

--
Fight Internet Censorship! http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon | 00447934365844

--
Fight Internet Censorship! http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon | 00447934365844

--
Fight Internet Censorship! http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon | 00447934365844

--
Fight Internet Censorship! http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon | 00447934365844

--
Fight Internet Censorship! http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon | 00447934365844

--
Fight Internet Censorship! http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon | 00447934365844

--
Fight Internet Censorship! http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon | 00447934365844

--
Fight Internet Censorship! http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon | 00447934365844

Fight Internet Censorship! http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon | 00447934365844

Follow-Ups:
- Re: [Wireshark-dev] Npcap 0.03 call for test
  - From: Yang Luo

References:
- Re: [Wireshark-dev] Npcap 0.03 call for test
  - From: Yang Luo
- Re: [Wireshark-dev] Npcap 0.03 call for test
  - From: Tyson Key
- Re: [Wireshark-dev] Npcap 0.03 call for test
  - From: Tyson Key
- Re: [Wireshark-dev] Npcap 0.03 call for test
  - From: Tyson Key
- Re: [Wireshark-dev] Npcap 0.03 call for test
  - From: Tyson Key
- Re: [Wireshark-dev] Npcap 0.03 call for test
  - From: Tyson Key
- Re: [Wireshark-dev] Npcap 0.03 call for test
  - From: Tyson Key
- Re: [Wireshark-dev] Npcap 0.03 call for test
  - From: Tyson Key
- Re: [Wireshark-dev] Npcap 0.03 call for test
  - From: Tyson Key
- Re: [Wireshark-dev] Npcap 0.03 call for test
  - From: Tyson Key

Prev by Date: Re: [Wireshark-dev] Npcap 0.03 call for test
Next by Date: Re: [Wireshark-dev] Npcap 0.03 call for test
Previous by thread: Re: [Wireshark-dev] Npcap 0.03 call for test
Next by thread: Re: [Wireshark-dev] Npcap 0.03 call for test
Index(es):
- Date
- Thread