Hi Pascal, I followed your steps, but unfortunately didn't reproduce the BSoD. Here's my steps on my Win8.1 x64 VMware VM ( with Intel VT enabled, so it should behave the same as a physical machine):
1) Installed VirtualBox 5.0.0 r101573, just opened the UI once, didn't create any VMs. 2) Reinstalled Npcap 0.03 r3 3) Installed Wireshark-win64-1.99.9-58-g08e80b1.exe (without installing WinPcap 4.1.3) from https://www.wireshark.org/download/automated/ 4) reboot 5) Launch Wireshark (also tried Wireshark Legacy), but there's no crashes. This is so weird. Cheers, Yang On Tue, Aug 4, 2015 at 12:48 AM, Pascal Quantin <pascal.quan...@gmail.com> wrote: > > > 2015-08-03 17:57 GMT+02:00 Yang Luo <hslu...@gmail.com>: > >> Hi Pascal, >> >> Thanks for testing. The output of your dump is pasted below. It seems >> that NdisFOidRequest call fails in Npcap's NPF_GetDeviceMTU routine. It is >> in the same position with the previous SYSTEM_SERVICE_EXCEPTION BSoD. So >> I think they may belong to the same bug. However, I didn't find what's >> wrong with this code (go to this link if anyone is interested with the >> code: >> https://github.com/nmap/npcap/blob/master/packetWin7/npf/npf/Openclos.c, >> Line: 570). WinDbg said "*An attempt was made to access a pageable (or >> completely invalid) address at an interrupt request level (IRQL) that is >> too high.*" But actually all arguments of NdisFOidRequest are from the >> OPEN_INSTANCE struct and this struct is allocated in a NonPaged pool, so >> it's hard to understand its reason. >> >> Another way is to reproduce this BSoD. I didn't encounter this BSoD >> before, from the dump I only recognized that you installed VirtualBox. It >> will be very helpful if you can provide the reproduce steps. >> > > Yes I have Virtualbox 5.0 installed (which allows me to run a Windows 10 > RTM machine on which Npcap does not crash (I could even capture some > loopbak traffic and find - and fix - a bug in Wireshark: > https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11412). > To reproduce the crash on this machine, it is as simple as: > - installing Npcap > - rebooting the laptop (I did not try without rebooting) > - Launching Wireshark 1.99.9 development build (you can find some nightly > installers here: https://www.wireshark.org/download/automated/ ) > - And bang it crashes immediately during Wireshark initialization > (presumably when dumpcap tries to retrieve interfaces, but I could not > confirm this as my PC reboots immediately) > > >> >> Cheers, >> Yang >> >> Loading User Symbols >> PEB is paged out (Peb.Ldr = 00000000`7efdf018). Type ".hh dbgerr001" for >> details >> Loading unloaded module list >> ......................... >> >> ******************************************************************************* >> * >> * >> * Bugcheck Analysis >> * >> * >> * >> >> ******************************************************************************* >> >> Use !analyze -v to get detailed debugging information. >> >> BugCheck D1, {7fefe838, 2, 0, fffff880010d86c2} >> >> Probably caused by : npf.sys ( npf!NPF_GetDeviceMTU+ad ) >> >> Followup: MachineOwner >> --------- >> >> 6: kd> !analyze -v >> >> ******************************************************************************* >> * >> * >> * Bugcheck Analysis >> * >> * >> * >> >> ******************************************************************************* >> >> DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1) >> An attempt was made to access a pageable (or completely invalid) address >> at an >> interrupt request level (IRQL) that is too high. This is usually >> caused by drivers using improper addresses. >> If kernel debugger is available get stack backtrace. >> Arguments: >> Arg1: 000000007fefe838, memory referenced >> Arg2: 0000000000000002, IRQL >> Arg3: 0000000000000000, value 0 = read operation, 1 = write operation >> Arg4: fffff880010d86c2, address which referenced memory >> >> Debugging Details: >> ------------------ >> >> >> SYSTEM_SKU: LENOVO_MT_20AN_BU_Think_FM_ThinkPad T440p >> >> SYSTEM_VERSION: ThinkPad T440p >> >> BIOS_DATE: 10/21/2014 >> >> BASEBOARD_PRODUCT: 20AN006VFR >> >> BASEBOARD_VERSION: 0B98401 PRO >> >> BUGCHECK_P1: 7fefe838 >> >> BUGCHECK_P2: 2 >> >> BUGCHECK_P3: 0 >> >> BUGCHECK_P4: fffff880010d86c2 >> >> READ_ADDRESS: 000000007fefe838 >> >> CURRENT_IRQL: 2 >> >> FAULTING_IP: >> ndis!ndisFQueueRequestOnNext+a2 >> fffff880`010d86c2 0fb638 movzx edi,byte ptr [rax] >> >> CPU_COUNT: 8 >> >> CPU_MHZ: 95a >> >> CPU_VENDOR: GenuineIntel >> >> CPU_FAMILY: 6 >> >> CPU_MODEL: 3c >> >> CPU_STEPPING: 3 >> >> DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT >> >> BUGCHECK_STR: 0xD1 >> >> PROCESS_NAME: dumpcap.exe >> >> ANALYSIS_VERSION: 10.0.10240.9 amd64fre >> >> TRAP_FRAME: fffff8800e07f2c0 -- (.trap 0xfffff8800e07f2c0) >> NOTE: The trap frame does not contain all registers. >> Some register values may be zeroed or incorrect. >> rax=000000007fefe838 rbx=0000000000000000 rcx=fffffa800a6f8d00 >> rdx=fffffa8016f500c0 rsi=0000000000000000 rdi=0000000000000000 >> rip=fffff880010d86c2 rsp=fffff8800e07f450 rbp=fffff88001138110 >> r8=0000000000000000 r9=0000000000000000 r10=0000000000000000 >> r11=fffff8800e07f448 r12=0000000000000000 r13=0000000000000000 >> r14=0000000000000000 r15=0000000000000000 >> iopl=0 nv up ei ng nz na po nc >> ndis!ndisFQueueRequestOnNext+0xa2: >> fffff880`010d86c2 0fb638 movzx edi,byte ptr [rax] >> ds:00000000`7fefe838=?? >> Resetting default scope >> >> LAST_CONTROL_TRANSFER: from fffff80003080e69 to fffff800030818c0 >> >> STACK_TEXT: >> fffff880`0e07f178 fffff800`03080e69 : 00000000`0000000a 00000000`7fefe838 >> 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx >> fffff880`0e07f180 fffff800`0307fae0 : 00000000`00000002 00000000`00000000 >> 00000000`00000000 00000000`c0000001 : nt!KiBugCheckDispatch+0x69 >> fffff880`0e07f2c0 fffff880`010d86c2 : fffffa80`0a6f8c80 fffff800`03215588 >> fffffa80`0a6f8c80 00000000`c0000001 : nt!KiPageFault+0x260 >> fffff880`0e07f450 fffff880`010d8cf9 : fffff880`0e07f500 fffff880`01138110 >> fffffa80`16f50000 fffff800`0309867f : ndis!ndisFQueueRequestOnNext+0xa2 >> fffff880`0e07f4c0 fffff880`01d8d1d1 : fffffa80`16f50098 fffffa80`16f50000 >> fffffa80`16f50098 00000000`00000000 : ndis!NdisFOidRequest+0xc9 >> fffff880`0e07f5a0 fffff880`01d8d51f : fffffa80`09c9b5b0 fffffa80`16cd5410 >> fffffa80`16cd5340 fffffa80`16f50000 : npf!NPF_GetDeviceMTU+0xad >> [j:\npcap\packetwin7\npf\npf\openclos.c @ 570] >> fffff880`0e07f5e0 fffff800`0337fb4b : 00000000`00000025 00000000`00000040 >> fffffa80`16da8c90 fffffa80`16da8d28 : npf!NPF_OpenAdapter+0xef >> [j:\npcap\packetwin7\npf\npf\openclos.c @ 308] >> fffff880`0e07f610 fffff800`0337bb5e : fffffa80`09c9b460 00000000`00000000 >> fffffa80`13c75750 00000000`00000001 : nt!IopParseDevice+0x14e2 >> fffff880`0e07f770 fffff800`0337c646 : 00000000`00000000 fffff880`0e07f8f0 >> fffff8a0`00000040 fffffa80`06d5d080 : nt!ObpLookupObjectName+0x784 >> fffff880`0e07f870 fffff800`0337df4c : fffffa80`16df4e60 00000000`00000000 >> fffff8a0`07bcc701 00000000`00000000 : nt!ObOpenObjectByName+0x306 >> fffff880`0e07f940 fffff800`03389574 : 00000000`001edbf8 00000000`c0100080 >> 00000000`001ee4c0 00000000`001edc10 : nt!IopCreateFile+0x2bc >> fffff880`0e07f9e0 fffff800`03080b53 : fffffa80`16e81b50 fffff880`0e07fb60 >> fffffa80`16e81b50 fffff800`03377894 : nt!NtCreateFile+0x78 >> fffff880`0e07fa70 00000000`7701e10a : 00000000`00000000 00000000`00000000 >> 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 >> 00000000`001edb88 00000000`00000000 : 00000000`00000000 00000000`00000000 >> 00000000`00000000 00000000`00000000 : 0x7701e10a >> >> >> On Mon, Aug 3, 2015 at 6:35 PM, Pascal Quantin <pascal.quan...@gmail.com> >> wrote: >> >>> Hi Yang >>> >>> 2015-08-03 9:33 GMT+02:00 Yang Luo <hslu...@gmail.com>: >>> > >>> > Hi list, >>> > >>> > I think have fixed the BAD_POOL_CALLER BSoD in Npcap 0.03 r3 version, >>> it turns out to be a memory double-free bug in WFP classifyFn function used >>> for loopback packet capturing. The lastest installer is: >>> https://svn.nmap.org/nmap-exp/yang/NPcap-LWF/npcap-nmap-0.03-r3.exe >>> > >>> > I have tested it under Win 8.1 x64 with VMware Workstation 11 >>> installed and Win10 x64, if you encounter any BSoDs with this version, >>> please let me know. >>> >>> I just gave it a try on the Windows 7 x64 laptop that was crashing last >>> week: >>> - like Tyson my Wifi is no more working when installing Npcap. No issue >>> when using shutting down Wifi and using Ethernet >>> - I still get a BSoD when launching Wireshark. The full and mini memory >>> dumps are available here: >>> https://www.dropbox.com/sh/2oz00ox20kv3oe0/AACFQC83vyKS2dY7bI7hnZBOa?dl=0 >>> >>> Cheers, >>> Pascal. >>> >>> >>> ___________________________________________________________________________ >>> Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> >>> Archives: https://www.wireshark.org/lists/wireshark-dev >>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev >>> mailto:wireshark-dev-requ...@wireshark.org >>> ?subject=unsubscribe >>> >> >> >> >> ___________________________________________________________________________ >> Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> >> Archives: https://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev >> mailto:wireshark-dev-requ...@wireshark.org >> ?subject=unsubscribe >> > > > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
