[Winpcap-bugs] WinPcap 4.1.1 - BSOD

Boaz Brickner boaz.brickner at gmail.com
Thu Nov 12 15:05:41 PST 2009


Hi,

I've just uploaded a 45 MB zip file containing the kernel dump.
I hope this helps.

Boaz.

On Thu, Nov 12, 2009 at 23:45, Gianluca Varenni <
gianluca.varenni at cacetech.com> wrote:

>  Would it be possible for you to enable kernel crash dumps and try to
> crash your machine as well?
>
> Have a nice day
> GV
>
> ----- Original Message -----
> *From:* Boaz Brickner <boaz.brickner at gmail.com>
> *To:* Gianluca Varenni <gianluca.varenni at cacetech.com>
> *Cc:* winpcap-bugs at winpcap.org
> *Sent:* Thursday, November 12, 2009 1:41 PM
> *Subject:* Re: [Winpcap-bugs] WinPcap 4.1.1 - BSOD
>
> Hi,
>
> I've uploaded 2 Windows XP mini dumps to
> ftp://www.winpcap.org/pub/incoming/ and I hope it got there.
> There are also 6 Windows 7 mini dumps publicly available in
> http://www.sevenforums.com/crashes-debugging/37276-bsod-windows-7-professional-64-bit.html
>
> Thank you,
>
> Boaz.
>
> On Thu, Nov 12, 2009 at 22:22, Gianluca Varenni <
> gianluca.varenni at cacetech.com> wrote:
>
>>  I analyzed the stack trace that you sent below, and it's definitely a
>> NULL pointer dereference, that should not happen (in the sense that such
>> pointer should not be null, it comes from the OS itself). In order to
>> further investigate the problem, however, I need to have a kernel memory
>> dump, so that I can get a look at the variables on the stack...
>>
>>
>> Have a nice day
>> GV
>>
>>
>>  ----- Original Message -----
>> *From:* Boaz Brickner <boaz.brickner at gmail.com>
>> *To:* winpcap-bugs at winpcap.org
>> *Sent:* Thursday, November 12, 2009 11:03 AM
>> *Subject:* [Winpcap-bugs] WinPcap 4.1.1 - BSOD
>>
>>   Hi,
>>
>> I'm working on a new wrapper for WinPcap in .Net call Pcap.Net.
>> I've recently tried to upgrade Pcap.Net project (
>> http://pcapdotnet.codeplex.com) to WinPcap 4.1.1 to support Windows 7
>> (I've used WinPcap 4.0.2 before).
>>
>> When I run my different unit tests that use all kinds of WinPcap's
>> features while using my network drive, I'm getting a Blue Screen Of Death
>> (BSOD) - Windows Crash.
>> I've managed to get BSOD both on Windows 7 Professional 64 bit and on
>> Windows XP SP3 32 bit (two different computer systems).
>> Before I've upgraded to WinPcap 4.1.1 I've never got a BSOD (Windows XP
>> SP3).
>>
>> *It seems this BSOD is caused by WinPcap's npf driver.*
>>
>> At first I thought this problem is caused by Windows 7 or a combination of
>> Windows 7 and WinPcap.
>> After I've seen that this problem also appears on my Windows XP that never
>> experienced this problem before, I believe this is not the case and it is
>> caused by WinPcap 4.1.1 alone.
>>
>> Since a full reboot is needed after the BSOD appears, I'm having a hard
>> time figuring out what exactly causes this problem.
>>
>> If you want to try and recreate this problem you are welcome to use
>> WinPcap 4.1.1 and download the latest source from Pcap.Net project site
>> (changeset 30721):
>>
>> http://pcapdotnet.codeplex.com/SourceControl/ListDownloadableCommits.aspx
>>
>> If you're having troubles compiling and running the unit tests using
>> Visual Studio Team Suite 2008 SP1, you are welcome to contact me and I'll
>> try to help you with it. Sometimes more than one run of all the unit tests
>> may be needed to cause the crash and you might need to do use your network
>> drive (by downloading a file for example) to make the BSOD appear.
>>
>>
>> Also see my post on Windows 7 forums:
>>
>> http://www.sevenforums.com/crashes-debugging/37276-bsod-windows-7-professional-64-bit.html
>>
>> *
>> Details from Windows 7 mini dump (note that npf.sys is specifically
>> referenced):*
>>
>> IRQL_NOT_LESS_OR_EQUAL (a)
>> 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 a kernel debugger is available get the stack backtrace.
>> Arguments:
>> Arg1: 0000000000003178, memory referenced
>> Arg2: 0000000000000002, IRQL
>> Arg3: 0000000000000001, bitfield :
>>     bit 0 : value 0 = read operation, 1 = write operation
>>     bit 3 : value 0 = not an execute operation, 1 = execute operation
>> (only on chips which support this level of status)
>> Arg4: fffff80003eccb75, address which referenced memory
>>
>> Debugging Details:
>> ------------------
>>
>>
>> WRITE_ADDRESS: GetPointerFromAddress: unable to read from fffff800040fa0e0
>>  0000000000003178
>>
>> CURRENT_IRQL:  2
>>
>> FAULTING_IP:
>> nt!KeAcquireSpinLockRaiseToDpc+55
>> fffff800`03eccb75 f0480fba2900    lock bts qword ptr [rcx],0
>>
>> CUSTOMER_CRASH_COUNT:  1
>>
>> DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT
>>
>> BUGCHECK_STR:  0xA
>>
>> PROCESS_NAME:  VSTestHost.exe
>>
>> TRAP_FRAME:  fffff8800909b7b0 -- (.trap 0xfffff8800909b7b0)
>> NOTE: The trap frame does not contain all registers.
>> Some register values may be zeroed or incorrect.
>> rax=0000000000000002 rbx=0000000000000000 rcx=0000000000003178
>> rdx=0000000000000085 rsi=0000000000000000 rdi=0000000000000000
>> rip=fffff80003eccb75 rsp=fffff8800909b940 rbp=0000000000003178
>>  r8=0000000000000065  r9=0000000000000000 r10=0000000000000000
>> r11=fffff8800909b980 r12=0000000000000000 r13=0000000000000000
>> r14=0000000000000000 r15=0000000000000000
>> iopl=0         nv up ei pl nz na po nc
>> nt!KeAcquireSpinLockRaiseToDpc+0x55:
>> fffff800`03eccb75 f0480fba2900    lock bts qword ptr [rcx],0
>> ds:00000000`00003178=????????????????
>> Resetting default scope
>>
>> LAST_CONTROL_TRANSFER:  from fffff80003ec3469 to fffff80003ec3f00
>>
>> STACK_TEXT:
>> fffff880`0909b668 fffff800`03ec3469 : 00000000`0000000a 00000000`00003178
>> 00000000`00000002 00000000`00000001 : nt!KeBugCheckEx
>> fffff880`0909b670 fffff800`03ec20e0 : 00000000`00000000 00000000`00000000
>> 00000000`00000000 fffff800`03eca1a2 : nt!KiBugCheckDispatch+0x69
>> fffff880`0909b7b0 fffff800`03eccb75 : fffffa80`03e5c3f0 00000000`08004870
>> 00000000`00000001 fffffa80`06a57900 : nt!KiPageFault+0x260
>> fffff880`0909b940 fffff880`05c02ef5 : fffffa80`0677d990 00000000`00000000
>> fffffa80`0677d8c0 00000000`00000000 : nt!KeAcquireSpinLockRaiseToDpc+0x55
>> fffff880`0909b990 fffffa80`0677d990 : 00000000`00000000 fffffa80`0677d8c0
>> 00000000`00000000 fffffa80`0677d8c0 : npf+0x2ef5
>> fffff880`0909b998 00000000`00000000 : fffffa80`0677d8c0 00000000`00000000
>> fffffa80`0677d8c0 fffff880`05c03edf : 0xfffffa80`0677d990
>>
>>
>> STACK_COMMAND:  kb
>>
>> FOLLOWUP_IP:
>> npf+2ef5
>> fffff880`05c02ef5 ??              ???
>>
>> SYMBOL_STACK_INDEX:  4
>>
>> SYMBOL_NAME:  npf+2ef5
>>
>> FOLLOWUP_NAME:  MachineOwner
>>
>> *MODULE_NAME: npf
>>
>> IMAGE_NAME:  npf.sys*
>>
>> DEBUG_FLR_IMAGE_TIMESTAMP:  4addfab3
>>
>> FAILURE_BUCKET_ID:  X64_0xA_npf+2ef5
>>
>>
>>  ------------------------------
>>
>> _______________________________________________
>> Winpcap-bugs mailing list
>> Winpcap-bugs at winpcap.org
>> https://www.winpcap.org/mailman/listinfo/winpcap-bugs
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.winpcap.org/pipermail/winpcap-bugs/attachments/20091113/b3d537a4/attachment.htm 


More information about the Winpcap-bugs mailing list