Hello, I am currently writing a keyboard filter driver, and I am having
a problem. I wrote the keyboard filter to be independent of the
underlying bus driver whether it be for PS/2 or USB. The problem I am
having is that when I install this filter driver for PS/2, it works
great. I am able to install it and uninstall it, and it functions
fine. When I install it for a USB keyboard filter driver, my driver
crashes. I looked at the crash dump, and it crashed at the PAGED_CODE
call below in my unload routine. my unload routine looks like this:

--------------------------------------------------------------------
KbFilter_Unload( __in PDRIVER_OBJECT Driver ){

PDEVICE_EXTENSION devExt;

PAGED_CODE();

devExt = (PDEVICE_EXTENSION) Driver->DeviceObject->DeviceExtension;

DbgPrint("Driver Unload Called...\n");

devExt->bThreadTerminate = TRUE;

KeReleaseSemaphore(&devExt->semQueue, 0, 1, TRUE);

KeWaitForSingleObject( devExt->pThreadObj, Executive, KernelMode,
FALSE, NULL);

ZwClose(devExt->hLogFile);

IoDeleteDevice(Driver->DeviceObject);

Driver->DeviceObject = NULL;
}
--------------------------------------------------------------------

As I said before, for a PS/2 keyboard, it works fine, but for USB, it
bug checks.

any ideas?

Re: problem with PAGED_CODE by Doron

Doron
Fri Sep 15 10:34:52 CDT 2006

if you are a pnp filter, there are no device objects left when your unload
routine is called. this means that Driver->DeviceObject is == NULL and you
are blowing up there. what is the callstack and results of !analyze -v?

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Jon" <TheFakeJon@gmail.com> wrote in message
news:1158281161.410952.113370@p79g2000cwp.googlegroups.com...
> Hello, I am currently writing a keyboard filter driver, and I am having
> a problem. I wrote the keyboard filter to be independent of the
> underlying bus driver whether it be for PS/2 or USB. The problem I am
> having is that when I install this filter driver for PS/2, it works
> great. I am able to install it and uninstall it, and it functions
> fine. When I install it for a USB keyboard filter driver, my driver
> crashes. I looked at the crash dump, and it crashed at the PAGED_CODE
> call below in my unload routine. my unload routine looks like this:
>
> --------------------------------------------------------------------
> KbFilter_Unload( __in PDRIVER_OBJECT Driver ){
>
> PDEVICE_EXTENSION devExt;
>
> PAGED_CODE();
>
> devExt = (PDEVICE_EXTENSION) Driver->DeviceObject->DeviceExtension;
>
> DbgPrint("Driver Unload Called...\n");
>
> devExt->bThreadTerminate = TRUE;
>
> KeReleaseSemaphore(&devExt->semQueue, 0, 1, TRUE);
>
> KeWaitForSingleObject( devExt->pThreadObj, Executive, KernelMode,
> FALSE, NULL);
>
> ZwClose(devExt->hLogFile);
>
> IoDeleteDevice(Driver->DeviceObject);
>
> Driver->DeviceObject = NULL;
> }
> --------------------------------------------------------------------
>
> As I said before, for a PS/2 keyboard, it works fine, but for USB, it
> bug checks.
>
> any ideas?
>



Re: problem with PAGED_CODE by Jon

Jon
Fri Sep 15 13:44:38 CDT 2006

Here is the result of the crash dump:



----------------------------------------------------------------------------------------------------------------

kd> !analyze -v
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M (1000007e)
This is a very common bugcheck. Usually the exception address
pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this
address.
Some common problems are exception code 0x80000003. This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG. This is not supposed to happen as developers should never
have
hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG. This will let us see why this breakpoint is
happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: f2658415, The address that the exception occurred at
Arg3: f7a27a98, Exception Record Address
Arg4: f7a27794, Context Record Address

Debugging Details:
------------------


EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx"
referenced memory at "0x%08lx". The memory could not be "%s".

FAULTING_IP:
kbfiltr!KbFilter_Unload+35 [c:\src\kbfiltr.c @ 604]
f2658415 8b4828 mov ecx,dword ptr [eax+28h]

EXCEPTION_RECORD: f7a27a98 -- (.exr fffffffff7a27a98)
ExceptionAddress: f2658415 (kbfiltr!KbFilter_Unload+0x00000035)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 00000028
Attempt to read from address 00000028

CONTEXT: f7a27794 -- (.cxr fffffffff7a27794)
eax=00000000 ebx=00000000 ecx=00000000 edx=86b75340 esi=86b75340
edi=e139eaf8
eip=f2658415 esp=f7a27b60 ebp=f7a27b68 iopl=0 nv up ei ng nz ac
pe cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010297
kbfiltr!KbFilter_Unload+0x35:
f2658415 8b4828 mov ecx,dword ptr [eax+28h]
ds:0023:00000028=????????
Resetting default scope

CUSTOMER_CRASH_COUNT: 3

PROCESS_NAME: System

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx"
referenced memory at "0x%08lx". The memory could not be "%s".

READ_ADDRESS: 00000028

BUGCHECK_STR: 0x7E

DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE

LOCK_ADDRESS: 80551160 -- (!locks 80551160)

Resource @ nt!PiEngineLock (0x80551160) Available

WARNING: SystemResourcesList->Flink chain invalid. Resource may be
corrupted, or already deleted.


WARNING: SystemResourcesList->Blink chain invalid. Resource may be
corrupted, or already deleted.

1 total locks

PNP_TRIAGE:
Lock address : 0x80551160
Thread Count : 0
Thread address: 0x00000000
Thread wait : 0x0

LAST_CONTROL_TRANSFER: from 804f43cd to f2658415

STACK_TEXT:
f7a27b68 804f43cd 86b75340 e139eaf8 86b753f4
kbfiltr!KbFilter_Unload+0x35 [c:\src\kbfiltr.c @ 604]
f7a27c10 805887f4 f7a27c28 00000001 fff7e338 nt!IopUnloadDriver+0x22b
f7a27c30 804f5bbf 86b75340 00000000 e14ebba0
nt!IopUnloadAttachedDriver+0x72
f7a27c54 80588994 e1a34138 00000015 e14ebba0
nt!IopRemoveLockedDeviceNode+0x1d7
f7a27c6c 805889fb 861d3ee8 00000002 e14ebba0
nt!IopDeleteLockedDeviceNode+0x34
f7a27ca0 8058e66b 861d3b90 024ebba0 00000002
nt!IopDeleteLockedDeviceNodes+0x3f
f7a27d34 8058e92e f7a27d70 806d0778 e12e5528
nt!PiProcessQueryRemoveAndEject+0x76b
f7a27d50 8058ea87 f7a27d70 86d59670 8055a1fc
nt!PiProcessTargetDeviceEvent+0x2a
f7a27d74 80533dd0 86d59670 00000000 86fc48b8 nt!PiWalkDeviceList+0xfd
f7a27dac 805c4a06 86d59670 00000000 00000000 nt!ExpWorkerThread+0x100
f7a27ddc 80540fa2 80533cd0 00000001 00000000
nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16


FOLLOWUP_IP:
kbfiltr!KbFilter_Unload+35 [c:\src\kbfiltr.c @ 604]
f2658415 8b4828 mov ecx,dword ptr [eax+28h]

FAULTING_SOURCE_CODE:
600:
601: devExt = (PDEVICE_EXTENSION)
Driver->DeviceObject->DeviceExtension;
602:
603: DbgPrint("Driver Unload Called...\n");
> 604:
605: devExt->bThreadTerminate = TRUE;
606:
607: // Wake up our thread if it is blocked
608: KeReleaseSemaphore(&devExt->semQueue, 0, 1, TRUE);
609:


SYMBOL_STACK_INDEX: 0

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: kbfiltr

IMAGE_NAME: kbfiltr.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4509c1d6

SYMBOL_NAME: kbfiltr!KbFilter_Unload+35

STACK_COMMAND: .cxr 0xfffffffff7a27794 ; kb

FAILURE_BUCKET_ID: 0x7E_kbfiltr!KbFilter_Unload+35

BUCKET_ID: 0x7E_kbfiltr!KbFilter_Unload+35

Followup: MachineOwner
---------



thanks!


Re: problem with PAGED_CODE by Jon

Jon
Fri Sep 15 13:52:35 CDT 2006

Thanks Doron, actually this makes a lot of sense now. I am still a
newbie :( so actually when I am unloading my driver as a PnP filter, I
should be sticking my remove code in IRP_MN_REMOVE_DEVICE. But as a
filter for a non-PnP device such as a PS/2 keyboard, will I still
recieve a IRP_MN_REMOVE_DEVICE?

I appreciate the help.


Re: problem with PAGED_CODE by Slava

Slava
Fri Sep 15 18:17:05 CDT 2006

"Jon" <TheFakeJon@gmail.com> wrote in message
news:1158346355.349647.65810@h48g2000cwc.googlegroups.com...

[...]

> a non-PnP device such as a PS/2 keyboard

Even though PS/2 keyboards are not PnP in the popular use of the word, they
are PnP from the WDM point of view. For example, the keyboard that I am
using now is the end of the following device chain:

PnP enum -> HAL (PDO) -> HAL (FDO) -> ACPI (PDO) -> ACPI (FDO) -> PCI
(PDO) -> PCI (FDO) -> ISA bridge (PDO) -> ISA bridge (FDO) -> PS/2 keyboard
(PDO) -> PS/2 keyboard (FDO) -> PS/2 keyboard (FiDO).

The device stack is perfectly PnP, while the physical device is not PnP at
all, being a laptop keyboard.

S



Re: problem with PAGED_CODE by Jon

Jon
Fri Sep 15 19:04:23 CDT 2006

oh i see.. that was my confusion. I put my clean up code in
IRP_MN_REMOVE_DEVICE and it works great.

thanks for the help.

my next project is going to develop another filter driver. I wasn't
sure which one at the moment. I have a fairly recent build of the DDK,
build 5500. I was hoping that someone could direct me towards a
sample:

CD-ROM filter driver, USB filter, Firewire filter, mouse filter
(moufiltr?)?

thanks