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 20:26:17 +0100

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 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

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)

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

Follow-Ups:
- Re: [Wireshark-dev] Npcap 0.03 call for test
  - From: Tyson Key

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

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