Crash ion wanarp.sys module

Discussion in 'Windows Vista Drivers' started by Oleg, Aug 15, 2005.

  1. Oleg

    Oleg Guest

    Hi all,

    I'm working on filter driver based on NDIS IM driver from DDK.
    As part of it's functionality it needs to inject sometimes packets -
    sends them in outbound direction. Sometimes packets are sent
    to broadcast. Since I'm not interested to see them again in the inbound
    due to NDIS loopbacking feature I add NDIS_FLAGS_DONT_LOOPBACK
    flag to the sent packet.

    This works fine in Windows XP. However Windows 2000 machine
    completely ignores my request to not loopback and it even crashes during
    packet's processing on protocol side. Same happens on Windows 2003

    2 questions: 1) Why does Windows 2000 ignore the above flag and if it is by
    is there another way to not loopback broadcast packets
    2) Is the crash in wanarp.sys module (the dump analysis is following) is a
    issue or this is a problem in my driver (much more likely)?


    kd> !analyze -v
    * Bugcheck Analysis

    An attempt was made to access a pageable (or completely invalid) address at
    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.
    Arg1: 63707273, memory referenced
    Arg2: 00000002, IRQL
    Arg3: 00000001, value 0 = read operation, 1 = write operation
    Arg4: 8046418d, address which referenced memory

    Debugging Details:

    WRITE_ADDRESS: 63707273


    8046418d 0fc101 xadd [ecx],eax



    LAST_CONTROL_TRANSFER: from f73dc952 to 8046418d

    TRAP_FRAME: be69576c -- (.trap ffffffffbe69576c)
    ErrCode = 00000002
    eax=00000001 ebx=8129a8e8 ecx=63707273 edx=00000004 esi=63707257
    eip=8046418d esp=be6957e0 ebp=be6957f4 iopl=0 nv up ei pl nz na pe
    cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
    8046418d 0fc101 xadd [ecx],eax
    Resetting default scope

    be6957dc f73dc952 0000003f 8117c300 8129a8e8 nt!InterlockedIncrement+0x5
    be6957f4 f73dc8ef 0cabb1e5 8117c300 812021ca wanarp!WanReceiveCommon+0x32
    be69582c bfeb5183 0cabb1e5 00000000 81437b70
    be695884 be18e9ca 8117fb00 be6958a0 00000001
    be6958ac be18ea83 81116000 8117c300 812021d0
    be6958fc be18f78e 81116000 8117c300 810db028 mydriver!MyInboundPacket+0x83
    be695918 bfeb5216 81116000 810e0bc8 00000000
    be69596c bfe06a15 81437b01 be69599c 00000001
    be695990 bfdfda72 813b0c28 810db028 00000001
    be6959bc bfdf730c 813b0c28 00000001 8117c38c ndiswan!NdisWanQueueSend+0x118
    be6959d0 bfead137 813b0c28 be695a24 00000001 ndiswan!MPSendPackets+0x1e
    be6959fc bfeae9e4 00000001 be695a28 00000000 NDIS!ndisMSendPacketsX+0x17d
    be695a0c be195932 8139e348 be695a24 00000001 NDIS!NdisSendPackets+0x10
    be695a30 be19bf62 8139e348 810e0008 0000004d mydriver!drv_send_packet+0xf2
    be695aac be197d2e 81202228 00000002 be695ad4
    be695abc be197649 00000000 848a4430 00000002
    be695ad4 be196c45 811edda8 848a40e4 be695b34 mydriver!drv_config+0x95
    be695b08 be18e592 0012c005 811edda8 00000008 mydriver!drv_ioctl+0xc1
    be695b40 bfe983d6 81201b30 811eb2e8 811eb2e8
    be695b54 bfe98384 81201b30 811eb2e8 81201b30 NDIS!ndisDummyIrpHandler+0x34
    be695c00 8041dded 81201b30 811eb2e8 811eb2e8
    be695c14 804ae806 811eddb0 00000000 811eb2e8 nt!IopfCallDriver+0x35
    be695c28 804af670 81201b30 811eb2e8 8120d188
    be695d00 804a71ec 00000084 00000000 00000000 nt!IopXxxControlFile+0x5e4
    be695d34 80464f84 00000084 00000000 00000000 nt!NtDeviceIoControlFile+0x28
    be695d34 77f88403 00000084 00000000 00000000 nt!KiSystemService+0xc4
    0076e6a4 7c5794e7 00000084 00000000 00000000 ntdll!ZwDeviceIoControlFile+0xb
    0076e708 0041a2a4 00000084 0012c005 0076e9c4 KERNEL32!DeviceIoControl+0xf8
    0076e734 00401db5 0012c005 0076e9c4 00000008 mysrv!myioctl+0x74
    0076ff54 00403269 005658d8 00403658 00135d98 mysrv!myConfiguration+0x89c
    0076ff94 00403564 81199780 ffffffff 0076ffec mysrv!myInit+0x81
    0076ffa4 7c2dcf43 00000001 00135d18 0012f94c mysrv!myMain+0x57
    0076ffc4 00135d10 7ffdc000 ffffff00 0076ffc0
    WARNING: Frame IP not in any known module. Following frames may be wrong.
    0012f94c 00000000 0012f8d8 00000000 0012fc08 0x135d10

    f73dc952 85f6 test esi,esi


    FOLLOWUP_NAME: MachineOwner

    SYMBOL_NAME: wanarp!WanReceiveCommon+32

    MODULE_NAME: wanarp

    IMAGE_NAME: wanarp.sys


    STACK_COMMAND: .trap ffffffffbe69576c ; kb

    FAILURE_BUCKET_ID: 0xA_W_wanarp!WanReceiveCommon+32

    BUCKET_ID: 0xA_W_wanarp!WanReceiveCommon+32

    Followup: MachineOwner
    Oleg, Aug 15, 2005
    1. Advertisements

  2. Loopback logic changed between Windows 2000 and XP and so has the DDK
    sample. What DDK are you taking PASSTHRU from? Please look at the XPSP1
    (or later) version. Building on that, see if this article helps:

    Regarding the crash in WANARP, we would need more detail -- especially a
    stack trace and the output to "!analyse -v"

    Bryan S. Burgin

    This posting is provided "AS IS" with no warranties, and confers no rights.
    Bryan S. Burgin [MSFT], Aug 15, 2005
    1. Advertisements

  3. Oleg

    Oleg Guest

    I'm using PASSTHRU from XP DDK from May 2003
    I will move to the latest XPSP1 DDK.

    See the output to "!analyze -v" in my initial post (it also
    includes a stack trace).

    Thanks for your help
    Oleg, Aug 16, 2005
  4. Oleg

    Oleg Guest

    The reason I'm working with an old DDK is a product I have to support.
    I'm not rushing to update the driver with the latest DDK available - this is
    expensive for organization.

    Besides, what does the MS policy state? Does the fact that newer DDKs are
    mean the older ones are not supported anymore?


    Oleg, Aug 16, 2005
  5. I specified XPSP1 because I knew that that is where and when the change
    that affected LOOPBACK happened. There was no XPSP2 DDK, as the newest one
    (released) is Server 03 SP1, as you point out - but I don't believe that
    PASSTHRU changed from XPSP1 until now, at least in regards to LOOPBACK.

    The reason I asked what DDK you were using and recommended that you use at
    least the XPSP1 DDK was within the context of your PASSTHRU and LOOPBACK
    question. Perhaps it's worth a cursory WinDiff of the PASSTHRU sample
    between the DDK you are using and a newer one and migrate the differences
    into your project -- and then continue to use the older kit for building,
    if that's what you want to do.

    As for your bugcheck -- sorry I missed the debugger output. It looks like
    mydriver is sending a packet. You may want to turn on Driver Verifier for
    that driver, ndiswan and wanarp. My first reaction looking at the address
    0x63707273 is that it looks like ASCII 'srpc'. ESI of 0x63707257 could be
    ASCII text, too ('Wrpc'), perhaps the pooltag for WAN_CONN_TAG. But that's
    just speculation.

    Bryan S. Burgin

    This posting is provided "AS IS" with no warranties, and confers no rights.
    Bryan S. Burgin [MSFT], Aug 16, 2005
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.