jnc
Mon Feb 05 16:01:48 CST 2007
Gianluca, Ali,
Thanks for your replies. I was able to locate the problem in the
ProtocolUnbindAdapter(), it was that code called NdisWaitEvent() with
NDIS spinlock acquired. The NDIS called the ProtocolUnbindAdapter()
with correct IRQL indeed.
I read earlier that acquiring spinlocks raise IRQL, but thought this
is applicable to spinlocks managed by Ke*() functions. In
NdisAcquiredSpinLock() function description in WDK, I saw no
references to similar behaviour, only in NdisAllocateSpinLock(), which
confused me a little and distracted from the NDIS spinlocks. I guess
NDIS spinlocks are just framework around the Ke* spinlocks.
Thanks for your guidelines, it helped me get the driver work in Vista.
PS. Gianluca, I know the trick with debugging with VMware, however, I
have only 512MB on my PCs, and Vista itself requires 512MB to run,
leaving no memory for host OS. And I can't just take RAM from other
machines - there are so many form-factors of RAM now :) None of my
machines have same memory type :)
On 2 =D0=A4=D0=B5=D0=B2., 02:25, "Gianluca Varenni" <gianluca.vare...@cacet=
ech.com>
wrote:
> If you are 100% sure that in your PtUnbindAdapter you are releasing all t=
he
> spinlocks and such, just put a temp check for the IRQL at the very beginn=
ing
> of PtUnbindAdapter and see if it bugchecks there. Something like
>
> PtUnbindAdapter(...)
> {
> =C2=A0 =C2=A0 =C2=A0 if (KeGetCurrentIrql() !=3D PASSIVE_LEVEL) KeBugChec=
kEx(0xcafecafe,
> 0,0,0,0);
>
> =C2=A0 =C2=A0 .... rest of the code...
>
> }
>
> This is a quick (and very very very very dirty) way to check that your
> ProtocolUnbind handler is called at the right IRQL. If it doesn't crash (=
and
> I'm pretty sure it won't), analyze every single line of code before your
> NdisWaitEvent() and ask yourself if that code could possibly raise the IR=
QL.
> If that code is just some 10-20 lines of code, it's ok posting it on the
> list.
>
> Regarding serial debugging, for such bugs (i.e. completely repeatable, non
> related to performance) I always go with a virtual machine and a virtual
> serial port, i.e. a named pipe acting as a COM port. =C2=A0I personally u=
se
> vmware for this, but virtual PC should work in the same exact way. Just
> search for "virtual pc windbg" or "vmware windbg" and you'll find several
> tutorials on the web.
>
> Hope it helps
> GV
>
>
>
> > I'm kinda newbie in NDIS programming, so any additional directions you
> > can give in which to look for a problem, will be highly appreciated.
>
> > Thanks.
>
> > The call stack is as follows (also for Gianluca Varenni):
>
> > ChildEBP RetAddr =C2=A0Args to Child
> > 9398296c 8065bbcc 0000007c 00000014 00000002 nt!KeBugCheckEx+0x1e
> > 93982990 9277d98e 836a179c 00000000 818b06b5 ndis!NdisWaitEvent+0x23
> > 939829b0 80731f54 93982a8c 92784138 939829d0 fxwrap!PtUnbindAdapter
> > +0xfc [l:\fx-release\wrap-win\protocol.c @ 534]
> > 93982a94 8072d22d 8fae7c58 00000000 82e96488 ndis!ndisUnbindProtocol
> > +0x24b
> > 93982b38 80732277 82e96488 93982b98 00000000 ndis!
> > ndisPnPNotifyAllTransports+0x1c8
> > 93982bbc 807329d9 8fa50298 00a502a0 00000000 ndis!
> > ndisHandleProtocolUnbindNotification+0x1bd
> > 93982bd8 807222f2 8fa502a8 00000000 836fd530 ndis!ndisHandleUModePnPOp
> > +0x10e
> > 93982c0c 807224dd 836fd530 82e581d0 82d434d0 ndis!ndisHandlePnPRequest
> > +0x2d6
> > 93982c2c 81827ecf 82d434d0 836fd530 836fd530 ndis!ndisDispatchRequest
> > +0x8a
> > 93982c44 81988f65 82e581d0 836fd530 836fd5a0 nt!IofCallDriver+0x63
> > 93982c64 81989f25 82d434d0 82e581d0 00000000 nt!
> > IopSynchronousServiceTail+0x1e0
> > 93982d00 8198ee8d 82d434d0 836fd530 00000000 nt!IopXxxControlFile
> > +0x6b7
> > 93982d34 8188c96a 00000308 00000000 00000000 nt!NtDeviceIoControlFile
> > +0x2a
> > 93982d34 77670f34 00000308 00000000 00000000 nt!KiFastCallEntry+0x12a
> > 00c8e894 7766f850 76377c92 00000308 00000000 ntdll!KiFastSystemCallRet
> > 00c8e898 76377c92 00000308 00000000 00000000 ntdll!
> > ZwDeviceIoControlFile+0xc
> > 00c8e8f8 6df9b851 00000308 00170008 002b0488 kernel32!DeviceIoControl
> > +0x14a
> > 00c8e960 6df7c53a 00000001 00000002 00c8e994 netcfgx!NdisHandlePnPEvent
> > +0x1d5
> > 00c8e9bc 6df7ca43 00000001 00000002 0023ce38 netcfgx!HrPnpBindOrUnbind
> > +0xa6
> > 00c8edf4 6df73ae6 00000002 00c8ee4c 00000002 netcfgx!
> > CRegistryBindingsContext::PnpBindOrUnbindBindPaths+0x126
> > 00c8f02c 6df74ae6 00000000 020807f8 761c380d netcfgx!
> > CModifyContext::ApplyChanges+0x9c2
> > 00c8f040 6df66d55 00000001 00000000 018c0e18 netcfgx!
> > CModifyContext::HrApplyIfOkOrCancel+0x2d
> > 00c8f054 6bddc3f4 020807f8 761c244a 0004036e netcfgx!
> > CImplINetCfg::Apply+0x33
> > 00c8f070 6bddf1d6 00000000 00c8f3b4 00c8f0a0 netshell!
> > CLanNetPage::OnApply+0x61
> > 00c8f084 6bdeec81 0004036e 0000004e 00000000 netshell!
> > CLanNetNormalPage::ProcessWindowMessage+0x115
> > 00c8f0b4 761c1a10 0004036e 0000004e 00000000 netshell!
> > CPropSheetPage::DialogProc+0x44
> > 00c8f0e0 761b0df4 6bdeec3d 0004036e 0000004e USER32!InternalCallWinProc
> > +0x23
> > 00c8f15c 761b0c6e 00218cdc 6bdeec3d 0004036e USER32!
> > UserCallDlgProcCheckWow+0x132
> > 00c8f1a4 761b122b 00000000 0000004e 00000000 USER32!DefDlgProcWorker
> > +0xa8
> > 00c8f1c0 761c1a10 0004036e 0000004e 00000000 USER32!DefDlgProcW+0x22
> > 00c8f1ec 761c1ae8 761b1209 0004036e 0000004e USER32!InternalCallWinProc
> > +0x23
> > 00c8f264 761c286a 00218cdc 761b1209 0004036e USER32!
> > UserCallWinProcCheckWow+0x14b
> > 00c8f2a4 761c2bba 007d19d0 007d82c8 00000000 USER32!SendMessageWorker
> > +0x4b7
> > 00c8f2c4 74c655c7 0004036e 0000004e 00000000 USER32!SendMessageW+0x7c
> > 00c8f35c 74c7b459 00c8f374 ffffff36 00c8f3b4 comctl32!CCSendNotify
> > +0x79e
> > 00c8f398 74caba3f 0004036e 00060370 ffffff36 comctl32!SendNotifyEx
> > +0x57
> > 00c8f3c4 74cabc04 00242358 00000000 ffffff36 comctl32!_Ppd_SendNotify
> > +0x2b
> > 00c8f46c 74cabaae 00242358 00000001 00060372 comctl32!ButtonPushed
> > +0x129
> > 00c8f488 74caba54 00242358 00000001 00060372 comctl32!Prsht_OnCommand
> > +0x161
> > 00c8f504 761c1a10 00060370 00000111 00000001 comctl32!PropSheetDlgProc
> > +0x4a4
> > 00c8f530 761b0df4 74cabcb8 00060370 00000111 USER32!InternalCallWinProc
> > +0x23
> > 00c8f5ac 761b0c6e 00215a3c 74cabcb8 00060370 USER32!
> > UserCallDlgProcCheckWow+0x132
> > 00c8f5f4 761b122b 00000000 00000111 00000001 USER32!DefDlgProcWorker
> > +0xa8
> > 00c8f610 761c1a10 00060370 00000111 00000001 USER32!DefDlgProcW+0x22
> > 00c8f63c 761c1ae8 761b1209 00060370 00000111 USER32!InternalCallWinProc
> > +0x23
> > 00c8f6b4 761c286a 00215a3c 761b1209 00060370 USER32!
> > UserCallWinProcCheckWow+0x14b
> > 00c8f6f4 761c2bba 007d8330 007d82c8 00000001 USER32!SendMessageWorker
> > +0x4b7
> > 00c8f714 74c6e5cc 00060370 00000111 00000001 USER32!SendMessageW+0x7c
> > 00c8f734 74c6e583 002309f8 00000000 00000000 comctl32!
> > Button_NotifyParent+0x3d
> > 00c8f750 74c6e680 50030001 00000001 00c8f824 comctl32!
> > Button_ReleaseCapture+0x112
> > 00c8f7a8 761c1a10 00060372 00000202 00000000 comctl32!Button_WndProc
> > +0xa4b
> > 00c8f7d4 761c1ae8 74c7bd42 00060372 00000202 USER32!InternalCallWinProc
> > +0x23
> > 00c8f84c 761c2a47 00215a3c 74c7bd42 00060372 USER32!
> > UserCallWinProcCheckWow+0x14b
> > 00c8f8b0 761c2a98 74c7bd42 00000000 00c8f8e4 USER32!
> > DispatchMessageWorker+0x322
> > 00c8f8c0 761b11fc 00c8f91c 00242358 00c8f91c USER32!DispatchMessageW
> > +0xf
> > 00c8f8e4 74cabfe0 00060370 007d8750 002425f8 USER32!IsDialogMessageW
> > +0x586
> > 00c8f900 74cabf82 00242358 00c8f91c 02000182 comctl32!
> > Prop_IsDialogMessage+0x16f
> > 00c8f958 74cac4d7 00240000 02000182 00000000 comctl32!
> > _RealPropertySheet+0x286
> > 00c8f96c 74cac48f 00242358 00000000 00c8f990 comctl32!_PropertySheet
> > +0x45
> > 00c8f97c 6be0c862 00c8f9ac 00000034 1c780005 comctl32!PropertySheetW
> > +0xf
> > 00c8f990 6be0012c 00c8f9ac 595bb4f8 76378129 netshell!PropertySheetW
> > +0x40
> > 00c8fa80 6bdf9181 00060330 00000000 018c0b80 netshell!
> > HrRaiseConnectionPropertiesInternal+0x307
> > 00c8fb04 6bdfb247 00c8fb28 00060330 018c0920 netshell!
> > HrOnCommandProperties+0x183
> > 00c8fb50 6bdfb29e 00060330 001fd4b4 6bdf8ffe netshell!
> > HrRaiseDialogFromINetConnection+0x8e
> > 00c8fb64 6be00889 00060330 001fd4b4 00000000 netshell!
> > HrRaiseConnectionProperties+0x1b
> > 00c8fb88 76373833 018c08d0 00c8fbd4 7764a9bd netshell!
> > ShowPropertiesDialogThreadProc+0x87
> > 00c8fb94 7764a9bd 018c08d0 00c88aaf 00000000 kernel32!
> > BaseThreadInitThunk+0xe
> > 00c8fbd4 00000000 6be00802 018c08d0 00000000 ntdll!_RtlUserThreadStart
> > +0x23
>
> > On 1 =C3=A6=C3=85=C3=97., 03:01, "Alireza Dabagh [MS]" <a...@online.mic=
rosoft.com>
> > wrote:
> >> Do you know what caused NDIS to unbind your protocol? Are you sure we
> >> were
> >> at dispatch when unbind handler was called and the problem is not with
> >> your
> >> code acquiring a spinlock -after- unbind call and before you call
> >> NdisCloseAdapter?
>
> >> It is also possible that somewhere prior to NDIS calling unbind handle=
r,
> >> you
> >> (or some other driver) acquired a lock and forgot to release it. What's
> >> the
> >> underlying miniport adapter?
>
> >> -ali
>
> >> --
> >> This posting is provided "AS IS" with no warranties, and confers no
> >> rights.
>
> >> <j...@astrakhan.ru> wrote in message
>
> >>news:1170265051.878424.111180@v33g2000cwv.googlegroups.com...
>
> >> > I got a problem, where ProtocolUnbindAdapter() of my IM driver gets
> >> > called at IRQL DISPATCH_LEVEL on Vista, consequently causing a
> >> > bugcheck 0x7C with 0x14,0x02,0x00,0x00 parameters when calling
> >> > NdisWaitEvent() to wait for NdisCloseAdapter() to complete
> >> > asynchronously.
>
> >> > I'd like to know, why this can happen (most likely it's my programmi=
ng
> >> > error, but still), if the documentation clearly states that
> >> > ProtocolUnbindAdapter() is called at PASSIVE_LEVEL IRQL.
>
> >> > Also, the Debugging Tools documentation must be updated probably,
> >> > since it doesn't reflect 0x14 parameter in the 0x7C bugcheck
> >> > documentation.
>
> >> > Additionally, when I specifically enable "DbgPrint buffering"
> >> > parameter in GFlags utility and reboot the system and it crashes with
> >> > a full memory dump, WinDbg then displays nothing when issuing !
> >> > dbgprint command. =C2=A0The nt!kdprint* buffers are empty for some r=
eason.
>
> >> > Thanks.- =C3=B3=C3=8B=C3=92=C3=99=C3=94=C3=98 =C3=83=C3=89=C3=94=C3=
=89=C3=92=C3=95=C3=85=C3=8D=C3=99=C3=8A =C3=94=C3=85=C3=8B=C3=93=C3=94 -
>
> >> - =C3=B0=C3=8F=C3=8B=C3=81=C3=9A=C3=81=C3=94=C3=98 =C3=83=C3=89=C3=94=
=C3=89=C3=92=C3=95=C3=85=C3=8D=C3=99=C3=8A =C3=94=C3=85=C3=8B=C3=93=C3=94 -=
- =D0=A1=D0=BA=D1=80=D1=8B=D1=82=D1=8C =D1=86=D0=B8=D1=82=D0=B8=D1=80=D1=83=
=D0=B5=D0=BC=D1=8B=D0=B9 =D1=82=D0=B5=D0=BA=D1=81=D1=82 -
>
> - =D0=9F=D0=BE=D0=BA=D0=B0=D0=B7=D0=B0=D1=82=D1=8C =D1=86=D0=B8=D1=82=D0=
=B8=D1=80=D1=83=D0=B5=D0=BC=D1=8B=D0=B9 =D1=82=D0=B5=D0=BA=D1=81=D1=82 -- =
=D0=A1=D0=BA=D1=80=D1=8B=D1=82=D1=8C =D1=86=D0=B8=D1=82=D0=B8=D1=80=D1=83=
=D0=B5=D0=BC=D1=8B=D0=B9 =D1=82=D0=B5=D0=BA=D1=81=D1=82 -
>
> - =D0=9F=D0=BE=D0=BA=D0=B0=D0=B7=D0=B0=D1=82=D1=8C =D1=86=D0=B8=D1=82=D0=
=B8=D1=80=D1=83=D0=B5=D0=BC=D1=8B=D0=B9 =D1=82=D0=B5=D0=BA=D1=81=D1=82 -