Hi folks,
I have a bugcheck here that has me utterly mystified. Looking at the info I
have, it appears to be the kind of thing that just should *not* happen ever.
Even looking at the bugcheck, it is very unclear to me as to why on earth it has
faulted in the first place.
Cut a long story short:
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: f1881574, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: f1881574, address which referenced memory
Debugging Details:
READ_ADDRESS: f1881574 Nonpaged pool
CURRENT_IRQL: 2
FAULTING_IP:
mediaxImx!WorkerThreadFn+c4
f1881574 8845fb mov [ebp-0x5],al
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0xD1
LAST_CONTROL_TRANSFER: from 80536753 to 804e30d9
STACK_TEXT:
f20788d8 80536753 00000003 f2078c34 00000000 nt!RtlpBreakWithStatusInstruction
f2078924 8053721e 00000003 f1881574 f1881574 nt!KiBugCheckDebugBreak+0x19
f2078d04 804e106f 0000000a f1881574 00000002 nt!KeBugCheck2+0x574
f2078d04 f1881574 0000000a f1881574 00000002 nt!KiTrap0E+0x238
f2078dac 80576b24 8216be68 00000000 00000000 mediaxImx!WorkerThreadFn+0xc4
[s:\soft\win2000\kernel\lib\workerthread\workerthread.c @ 228]
f2078ddc 804eed86 f18814b0 8216be68 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
So "oh dear, it seems to have munched on fetching its own code" - which,
incidentally, looks like this:
VOID WorkerThreadFn(PVOID Context)
{
PSTREAM_WORK_POOL pPool = (PSTREAM_WORK_POOL) Context;
ULONG NextToCheck = 0;
KIRQL Irql;
BOOL DidWork; //Flag that allows us to determine that last time
//we checked all state atomically, and there is no work to do.
//Have to check all entries in round robin order.
//Must check all entries *before* checking closing pool.
KdPrint2(("%s: WorkerThreadFn Start.\n", gDriverName));
PAGED_CODE();
ASSERT(pPool);
ASSERT(pPool->InitFlag == POOL_INIT_FLAG);
KeAcquireSpinLock(&pPool->DataLock, &Irql); //<-Line 228.
So that made me think: "the thing that would cause this is if, in fact the code
is pageable" - Now, the PAGED_CODE macro is in there simply because other parts
of the code in the thread wait on dispatcher objects. However, the code section
itself *appears* to be in non paged memory - is this the case? Here's the
relevant bits of map file:
Start Length Name Class
0001:00000000 000184eeH .text CODE
0002:00000000 000000c4H .idata$5 DATA
0002:000000d0 000009c8H .rdata DATA
0002:00000a98 00000075H .rdata$debug DATA
0003:00000000 000000e0H .data DATA
0003:000000e0 00000038H .bss DATA
0004:00000000 000009d6H PAGE CODE
0005:00000000 000000a0H PAGECONST DATA
0006:00000000 0000003cH .idata$2 CODE
0006:0000003c 00000014H .idata$3 CODE
0006:00000050 000000c4H .idata$4 CODE
0006:00000114 00000402H .idata$6 CODE
0007:00000000 000000a0H .rsrc$01 DATA
0007:000000a0 000004a8H .rsrc$02 DATA
0001:00017090 _WT_InitStreamWorkPool@4 00027590 f
WorkerThreadd:workerthread.obj
0001:00017400 _WT_AllocateStreamWorkEntry@16 00027900 f
WorkerThreadd:workerthread.obj
0001:000176f0 _WT_RequestStreamWork@8 00027bf0 f
WorkerThreadd:workerthread.obj
0001:00017a10 _WT_CloseStreamWorkEntryAndWait@8 00027f10 f
WorkerThreadd:workerthread.obj
0001:00017dc0 _WT_CloseStreamWorkPoolAndWait@4 000282c0 f
WorkerThreadd:workerthread.obj
Static symbols
0001:000152c0 _MemSplitBlockAt@8 000257c0 f mmd:memmgr.obj
0001:00018200 _WorkerThreadFn@4 00028700 f
WorkerThreadd:workerthread.obj
Where on earth have I gone wrong???
MH.
This email and any attachments is confidential, may be legally privileged and is intended for the use of the addressee only. If you are not the intended recipient, please note that any use, disclosure, printing or copying of this email is strictly prohibited and may be unlawful. If received in error, please delete this email and any attachments and confirm this to the sender.