All,
Sorry for the vague bug description I provided last week. The bugcheck
that ocurs in psched.sys is becoming the most commonly occurring bugcheck.
Here are some specifics on it. I am still running with driver verifier on
ndis.sys and my protocol driver. The system is a dual 1.2 GHz running Xp
Sp1.
BugCheck D1, {89b66fc0, 2, 1, baa14247}
Probably caused by : psched.sys ( psched!ClRequestComplete+23 )
– note: memory at 89b66fc0 is invalid –
One of the parameters to psched!ClRequestComplete is an NDIS_REQUEST, in
this instance, 0x89235210. Here is a dump at 0x89235200 that indicates a
pool tag of PSC0 and the subsequent NDIS_REQUEST being passed to
ClRequestComplete.
0: kd> dd 89235200
89235200 0001000d 4c506343 0a0f0001 30435350
89235210 00000000 89f90f40 00000000 80000000
89235220 00000001 0001010e 891fb56c 00000004
89235230 00000004 00000000 00000000 00000000
Address Value Description
8923520c 30435350 Pool tag ‘PSC0’
89235210 00000000 Beginning of NDIS_REQUEST
89235220 00000001 NdisRequestSetInformation
89235224 0001010e OID_GEN_CURRENT_PACKET_FILTER
89235228 891fb56c Buffer for OID request - contains 0x2B - see below
8923522c 00000004 Data Length
89235230 00000004 Bytes Read
89235234 00000000 Bytes Needed
…
0: kd> dd 891fb56c l 1
891fb56c 0000002b
Perhaps the above information and the bugcheck analysis below might help
someone with more NDIS experience than myself to see what is happening
here and explain it to me. The protocol driver that I’m working with DOES
set OID_GEN_CURRENT_PACKET_FILTER, but it sets it to 0x20, not 0x2B. At
the time of the crash, there were 3 threads (2 separate processes) calling
NdisSend(), and one thread waiting for the completion of a query of
OID_GEN_CURRENT_LOOKAHEAD.
Again, thank you for any insights you might have.
Brad
0: kd> !analyze -v
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************
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: 89b66fc0, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: baa14247, address which referenced memory
Debugging Details:
WRITE_ADDRESS: 89b66fc0 Special pool
CURRENT_IRQL: 2
FAULTING_IP:
psched!ClRequestComplete+23
baa14247 8908 mov [eax],ecx
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0xD1_W
TRAP_FRAME: b0f84c84 – (.trap ffffffffb0f84c84)
ErrCode = 00000002
eax=89b66fc0 ebx=00000000 ecx=00000004 edx=8937cc02 esi=89235210
edi=89235210
eip=baa14247 esp=b0f84cf8 ebp=b0f84d04 iopl=0 nv up ei pl zr na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010246
psched!ClRequestComplete+23:
baa14247 8908 mov [eax],ecx
ds:0023:89b66fc0=???
Resetting default context
LAST_CONTROL_TRANSFER: from badc8c7c to baa14247
STACK_TEXT:
b0f84d04 badc8c7c 8912c298 89235210 00000000 psched!ClRequestComplete+0x23
b0f84d30 badc8ba9 89f90f40 89282ad8 8051d20e
NDIS!ndisMSyncSetInformationComplete+0xf2
b0f84d58 badc4f42 89f90f40 89282ad8 89235210 NDIS!ndisMDoRequests+0x3e2
b0f84d74 badc85ec 89f90f40 89235210 8a0ccfd8 NDIS!ndisMRequest+0xfa
b0f84d98 badb7623 8a0ccfc0 00000000 88fdc020
NDIS!ndisMRundownRequests+0x30
b0f84dac 805b046c 8a0ccfc8 00000000 00000000 NDIS!ndisWorkerThread+0x73
b0f84ddc 80534ad6 badb7600 8a0ccfc8 00000000
nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
FOLLOWUP_IP:
psched!ClRequestComplete+23
baa14247 8908 mov [eax],ecx
FOLLOWUP_NAME: MachineOwner
SYMBOL_NAME: psched!ClRequestComplete+23
MODULE_NAME: psched
IMAGE_NAME: psched.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 3d6ddcea
STACK_COMMAND: .trap ffffffffb0f84c84 ; kb
BUCKET_ID: 0xD1_W_psched!ClRequestComplete+23
Followup: MachineOwner
At the start of the week, I got a bugcheck on WinXP SP1 (windows update
enabled and keeping the machine up to date) in my NDIS protocol driver. I
had been stressing my driver for 48 hours when the bugcheck occurred.
Analysis of the bugcheck showed that NDIS was calling my
RequestCompleteHandler at a time in which I did not have any NDIS requests
pending. I did not think that this was a situation that I needed to
handle.
I calmly figured it must be something that I’m doing - probably the result
of how my driver interacts with NDIS. I enabled driver verifier for
ndis.sys; I was already verifying my driver.
After enabling driver verifier for ndis.sys, I now run into a bugcheck
within a few hours. I’ve seen bugchecks in psched.sys, wanarp.sys, and
NDIS!EthChangeFilterAddresses. Sometimes my driver is in the stack, often
it is not.
Has anyone else had problems with NDIS under high stress on WinXP? Anyone
have any ideas on how to track down the problem? I’m always running with
windbg hooked up to my test system, so any debugging hints would be
greatly appreciated as well.
Thanks in advance,
Brad