I have an NDIS filter that works on "most" machines. However, on a couple
machines we get a nasty crash:

BugCheck D1, {0, 2, 0, 0}

Stack trace:
ChildEBP RetAddr Args to Child
eb823974 8042c0c3 00000003 eb8239bc 00000000
nt!RtlpBreakWithStatusInstruction (FPO: [1,0,0])
eb8239a4 8042c487 00000003 00000000 00000000 nt!KiBugCheckDebugBreak+0x31
(FPO: [Non-Fpo])
eb823d30 8046856f 00000000 00000000 00000002 nt!KeBugCheckEx+0x390 (FPO:
[Non-Fpo])
eb823d30 00000000 00000000 00000000 00000002 nt!KiTrap0E+0x27c (FPO: [0,0]
TrapFrame @ eb823d4c)
eb823dbc eb823dec bfb4fdd2 81f92c50 81f4df08 0x0
WARNING: Frame IP not in any known module. Following frames may be wrong.
00010246 00000000 00000000 00000000 00000000 0xeb823dec

In the stack trace, on the second-last line, the value "81f92c50" is the
pointer to the adapter structure we allocated and passed as the
"ProtocolBindingContext" to NdisOpenAdapter(). This happens during bootup,
after the BindAdapter() calls finish successfully but while the system is
still coming up - we're getting bunches of QueryInformation() and
SetInformation() OID's. To me it looks like someone is dereferencing a null
function pointer. Any ideas who or why?

Thanks,

Warren

Could be as a protocol there is a particular handler you are not supporting
such as IndicateReceive (on the false assumption that is good enough to have
a IndicateReceivePackets handler).

My second guess would be not handling received packets indicated with
RESOURCE status properly.
A more detailed stack dump would be useful.

-ali

--
This posting is provided "AS IS" with no warranties, and confers no rights.

"Warren Ryd" <grizzlyblueeyes@netzero.net> wrote in message
news:uNWSbf4VDHA.1512@TK2MSFTNGP11.phx.gbl...

I do supply all the required handlers, including both IndicateReceive and
IndicateReceivePackets. And I am following the RESOURCE logic outlined in
the DDK. The stack trace I gave is everything the debugger had.

I have another suspicion. We are getting a PNP event of NetEventReconfigure
with a NULL adapter pointer. According to the DDK, we're supposed to follow
this up with a call to NdisReEnumerateProtocolBindings(), which I'm doing.
But is there more that needs to happen here? Could this be wiping out the
lower driver's pointers to our functions?

Warren

Make sure you have the latest WinDbg
(http://www.microsoft.com/whdc/ddk/debugging) and you have the symbol
path pointing to the symbol server (see "How to Get Symbols").

Then after the bugcheck enter the command that WinDbg suggests. There
should be a lot more info available than what you posted here.

Stephan
---
On Thu, 31 Jul 2003 11:18:59 -0600, "Warren Ryd"
<grizzlyblueeyes@netzero.net> wrote:

As Stephan pointed out, at this point we need a better stack trace than what
you provided. It would also be useful if you enumerated every significant
event that happened up to this point.(PnP, the last OID request, have you
received any packets by then? Have you sent any packet by then?)

What you are doing with the NetEventReconfigure is correct and should not
cause this problem.

Also please make sure you have the driver verifier on so you can catch your
drive just in case it is corrupting memory somewhere that comes and bites
you back later.

-ali

"Warren Ryd" <grizzlyblueeyes@netzero.net> wrote in message
news:OB8ipOEWDHA.1368@TK2MSFTNGP11.phx.gbl...