There is a NULL deref problem. You are not allowed to lower IRQL the way you have in your code right now. If you didn’t raise IRQL, you are not allowed to lower it. You are doing something to screw up the irp, specifically Irp->AssociatedIrp.SystemBuffer. kbdclass is in the wdk, so you can see KeyboardClassServiceCallback
PDEVICE_EXTENSION deviceExtension;
PIO_STACK_LOCATION irpSp;
LIST_ENTRY listHead;
PIRP irp;
ULONG bytesInQueue;
ULONG bytesToMove;
ULONG moveSize;
ULONG dumpData[2];
BOOLEAN logOverflow;
KbdPrint((2,“KBDCLASS-KeyboardClassServiceCallback: enter”));
deviceExtension = DeviceObject->DeviceExtension;
bytesInQueue = (ULONG)((PCHAR) InputDataEnd - (PCHAR) InputDataStart);
moveSize = 0;
*InputDataConsumed = 0;
logOverflow = FALSE;
//
// N.B. We can use KeAcquireSpinLockAtDpcLevel, instead of
// KeAcquireSpinLock, because this routine is already running
// at DISPATCH_IRQL.
//
KeAcquireSpinLockAtDpcLevel (&deviceExtension->SpinLock);
InitializeListHead (&listHead);
irp = KeyboardClassDequeueRead (deviceExtension);
if (irp) {
//
// An outstanding read request exists.
//
// Copy as much of the input data possible from the port input
// data queue to the SystemBuffer to satisfy the read.
//
irpSp = IoGetCurrentIrpStackLocation (irp);
bytesToMove = irpSp->Parameters.Read.Length;
moveSize = (bytesInQueue < bytesToMove) ?
bytesInQueue:bytesToMove;
*InputDataConsumed += (moveSize / sizeof(KEYBOARD_INPUT_DATA));
KbdPrint((
3,
“KBDCLASS-KeyboardClassServiceCallback: port queue length 0x%lx, read length 0x%lx”,
bytesInQueue,
bytesToMove
));
KbdPrint((
3,
“KBDCLASS-KeyboardClassServiceCallback: number of bytes to move from port to SystemBuffer 0x%lx”,
moveSize
));
KbdPrint((
3,
“KBDCLASS-KeyboardClassServiceCallback: move bytes from 0x%p to 0x%p”,
(PCHAR) InputDataStart,
irp->AssociatedIrp.SystemBuffer
));
RtlMoveMemory( <== you are blowing up here
irp->AssociatedIrp.SystemBuffer,
(PCHAR) InputDataStart,
moveSize
);
Which if I were to guess, you are somehow zero’ing out irp->AssociatedIrp.SystemBuffer in your processing of the read irp before it gets to kbdclass
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Thomas Milton
Sent: Wednesday, September 07, 2011 2:03 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] DispatchAny and IoCompletion working for \Device\Beep but not for \Device\KeyboardClass0
!analyze -v(output at the end) stated that the bugcheck occured while trying to access a pageable address at an IRQL which is too high.
Current IRQL was 2,so DISPATCH_LEVEL.
What is strange is that both,dispatch-and iocompletion-routine are defined with
#pragma alloc_text(NONPAGE,)
and all functions use functions which can be called at IRQL<=DISPATCH_LEVEL.
Using an explicit KeRaiseIrql() to PASSIVE_LEVEL and KeLowerIrql() did not solve the problem.
I append changed source code.
Thomas
output !analyze -v
-------------------------------------
Loading Kernel Symbols
…
…
Loading User Symbols
Loading unloaded module list
…
Bugcheck
Analysis
****
Use !analyze -v to get detailed debugging information.
BugCheck 1000000A, {0, 2, 1, 804d9e98}
Probably caused by : kbdclass.sys (
kbdclass!KeyboardClassServiceCallback+77 )
Followup: MachineOwner
---------
kd> !analyze -v
Bugcheck
Analysis
****
IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an interrupt request level (IRQL) that is too high. This is usually caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 00000000, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: 804d9e98, address which referenced memory
Debugging Details:
------------------
WRITE_ADDRESS: 00000000
CURRENT_IRQL: 2
FAULTING_IP:
nt!memmove+120
804d9e98 89448ff4 mov dword ptr [edi+ecx*4-0Ch],eax
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO
BUGCHECK_STR: 0xA
PROCESS_NAME: Idle
LAST_CONTROL_TRANSFER: from f8809209 to 804d9e98
STACK_TEXT:
80550f20 f8809209 00000000 81de8f70 0000000c nt!memmove+0x120
80550f48 f85b0712 0000000c 81de8f70 81e3612c
kbdclass!KeyboardClassServiceCallback+0x77
80550fac 804dbbd4 81e62284 01e62020 00000000
i8042prt!I8042KeyboardIsrDpc+0xf0
80550fd0 804dbb4d 00000000 0000000e 00000000 nt!KiRetireDpcList+0x46
80550fd4 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x26
STACK_COMMAND: kb
FOLLOWUP_IP:
kbdclass!KeyboardClassServiceCallback+77
f8809209 8b5508 mov edx,dword ptr [ebp+8]
SYMBOL_STACK_INDEX: 1
SYMBOL_NAME: kbdclass!KeyboardClassServiceCallback+77
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: kbdclass
IMAGE_NAME: kbdclass.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 48025372
FAILURE_BUCKET_ID: 0xA_kbdclass!KeyboardClassServiceCallback+77
BUCKET_ID: 0xA_kbdclass!KeyboardClassServiceCallback+77
Followup: MachineOwner
---------
--------------------------
CODE
-------------------------
NTSTATUS Dispatching(IN PDEVICE_OBJECT DeviceObject,IN PIRP irp){
PDEVICE_EXTENSION pdx = (PDEVICE_EXTENSION)
DeviceObject->DeviceExtension;
PIO_STACK_LOCATION irpstack = IoGetCurrentIrpStackLocation(irp);
NTSTATUS status = STATUS_SUCCESS;
KIRQL oldirql;
KeRaiseIrql(PASSIVE_LEVEL,&oldirql);
DbgPrint(“Dispatching\n”);
if(pdx->LowerDeviceObject == NULL||!NT_SUCCESS(status)){
IoCompleteRequest(irp,IO_NO_INCREMENT);
return STATUS_SUCCESS;
}
status = IoAcquireRemoveLock(&pdx->RemLock,irp);
//IoSkipCurrentIrpStackLocation(irp);//only if we do not want to provide a completion routine
IoCopyCurrentIrpStackLocationToNext(irp);
IoSetCompletionRoutine(irp,IRP_COMPLETION,NULL,TRUE,TRUE,TRUE);
IoReleaseRemoveLock(&pdx->RemLock,irp);
KeLowerIrql(oldirql);
return IoCallDriver(pdx->LowerDeviceObject,irp);
}
NTSTATUS IRP_COMPLETION( in PDEVICE_OBJECT pdevobj, in PIRP pirp,__in PVOID contenst){
KIRQL oldirql;
KeRaiseIrql(PASSIVE_LEVEL,&oldirql);
DbgPrint(“Completing\n”);
if(pirp->PendingReturned)//mandetory
IoMarkIrpPending(pirp);
KeLowerIrql(oldirql);
return pirp->IoStatus.Status;
}
------------------------------------------
Am 07.09.2011 03:32, schrieb Doron Holan:
> What is the output of !analyze -v ?
>
> d
>
> debt from my phone
>
>
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer