Re: IM driver crash & resets
From: Warren Ryd (grizzlyblueeyes_at_netzero.net)
Date: 02/20/04
- Next message: Carey Gregory: "Re: genprint print processor and EMF"
- Previous message: Andrew: "Re: A service and WTS"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 20 Feb 2004 12:02:06 -0700
Someone else asked for this, so I thought I'd post my solution here:
This turned out to be a flaw in the handling of resets. The sample PassThru
basically ignores the whole reset scenario, so it was no help at all. The
problem is that if a reset is in progress, you are not allowed to call
NdisRequest() - the blue screen occurs because the lower driver is trying to
respond to your request while at the same time freeing all its buffers.
What I did was make a "reset state" flag in my ADAPT structure. This field
has three states - "running", "in reset", and "reset end". (Be sure to
protect the state with a spin lock.)
When handling query/set requests (MiniportSet/QueryInformation()), if the
state is not "running", I queue the request. I use the sample PassThru
logic here, which leaves the request data in the ADAPT Request buffer and
sets the "QueuedRequest" flag to TRUE. (Do not call NdisRequest() here in
that case - just return from the function.)
The state change is managed as follows:
In the ProtocolStatus() function, we will get notifications of
NDIS_STATUS_RESET_START and NDIS_STATUS_RESET_END at the beginning and end
of a reset operation. When we get the "start" event, I set the reset state
to "in reset". When we get the "end" event, I set the state to "reset end".
In the ProtocolStatusComplete() function, if I see the reset state is "reset
end", then I set the state to "running" and check the "QueuedRequest" flag.
If a request was queued, I then pass the request buffer (from the ADAPT
structure) to NdisRequest().
This fixed the problem, and it has been running well in the environments
where it used to blue screen. This does, of course, require the faith that
once Ndis sends the RESET_START, it will follow it up with RESET_END and
ProtocolStatusComplete(), but so far this all seems to be happening as
documented.
Hope that helps!
Warren
"Warren Ryd" <grizzlyblueeyes@netzero.net> wrote in message
news:eFNEEUt3DHA.2296@TK2MSFTNGP11.phx.gbl...
> I have an NDIS filter driver (based on the PassThru sample) that works
well
> "most" of the time. However, one user's laptop will bug-check
occasionally
> when using a WLAN connection. (Memory dump analysis is below.) From the
> stack trace, it is crashing in a QIC, and the eax register shows
"c001000d",
> which is the status for NDIS_STATUS_RESET_IN_PROGRESS. Thus, I'm guessing
> the problem is related to handling resets...
>
> The PassThru didn't handle resets at all, which seems to go against the
DDK
> docs. Is there an example that does show how a filter should deal with
> resets? Or is there something else I should look at?
>
> Thanks,
>
> Warren
>
> --------------------------------------------------------------------------
-
> DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
> An attempt was made to access a pagable (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: 00000000, memory referenced
> Arg2: 00000002, IRQL
> Arg3: 00000000, value 0 = read operation, 1 = write operation
> Arg4: f766e1d2, address which referenced memory
>
> Debugging Details:
> ------------------
>
>
> READ_ADDRESS: 00000000
>
> CURRENT_IRQL: 2
>
> FAULTING_IP:
> NDIS!ndisMSyncQueryInformationComplete+1c
> f766e1d2 8b07 mov eax,[edi]
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0xD1
>
> TRAP_FRAME: ee902cac -- (.trap ffffffffee902cac)
> ErrCode = 00000000
> eax=c001000d ebx=00000000 ecx=00000000 edx=c001000d esi=852aaad8
> edi=00000000
> eip=f766e1d2 esp=ee902d20 ebp=ee902d30 iopl=0 nv up ei pl zr na po
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010246
> NDIS!ndisMSyncQueryInformationComplete+1c:
> f766e1d2 8b07 mov eax,[edi]
> ds:0023:00000000=????????
> Resetting default context
>
> LAST_CONTROL_TRANSFER: from f766f773 to f766e1d2
>
> STACK_TEXT:
> ee902d30 f766f773 85093ea0 852aaad8 8051aa1c
> NDIS!ndisMSyncQueryInformationComplete+0x1c
> ee902d58 f766a727 85093ea0 852aaad8 84fcbe60 NDIS!ndisMDoRequests+0x30b
> ee902d74 f766f907 85093ea0 84fcbe60 85321d18 NDIS!ndisMRequest+0xab
> ee902d98 f765fa01 85321d00 00000000 84e9dd10
NDIS!ndisMRundownRequests+0x30
> ee902dac 805aa2b6 85321d08 00000000 00000000 NDIS!ndisWorkerThread+0x73
> ee902ddc 805319c6 f765f98e 85321d08 00000000
nt!PspSystemThreadStartup+0x34
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>
>
> FOLLOWUP_IP:
> NDIS!ndisMSyncQueryInformationComplete+1c
> f766e1d2 8b07 mov eax,[edi]
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: NDIS!ndisMSyncQueryInformationComplete+1c
>
> MODULE_NAME: NDIS
>
> IMAGE_NAME: NDIS.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 3e6793e0
>
> STACK_COMMAND: .trap ffffffffee902cac ; kb
>
> BUCKET_ID: 0xD1_NDIS!ndisMSyncQueryInformationComplete+1c
>
> Followup: MachineOwner
> ---------
>
>
- Next message: Carey Gregory: "Re: genprint print processor and EMF"
- Previous message: Andrew: "Re: A service and WTS"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
