Re: Bluescreen when we try to attach a filter to another device stack in KMDF
- From: "Scott Noone" <snoone@xxxxxxx>
- Date: Thu, 28 May 2009 07:07:52 -0400
Looks like a breakpoint. Have you tried checking the IFR to see if there's a
message before (or after) the break?
http://www.osronline.com/article.cfm?id=496
-scott
--
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com
"Ray Trent" <rat@xxxxxxxxxxxxx> wrote in message
news:OX6QT8y3JHA.6004@xxxxxxxxxxxxxxxxxxxxxxx
Let me start by saying, I know this is the wrong way to do things, but it
was the only hack we could figure out with MS's help in the pre-Vista days
for working around the extremely quirky behavior of installing PS/2 filter
drivers (since 2k, the OS "conveniently" removes any existing filters when
you do this... even if you tell it not to in the INF).
Basically, we have a PS/2 mouse filter driver that needs to dynamically
create a filter on the *keyboard* driver stack. We've carefully analyzed
that we are guaranteed to do this at the right time to avoid problems with
stack depth and the like.
We may end up needing to find a way to reliably install ourselves as a PNP
filter on the keyboard stack (without disturbing any other filters or
losing ours if one is installed after us... groan... this takes a very
delicate use of CoInstallers and wishing real hard that other keyboard
driver installers were written well). But this is a big redesign, and Win7
is fairly imminent.
What I need in the mean time is a workaround for this problem.
A summary of what we're doing: we're creating a KMDF control device, first
using WdfControlDeviceInitAllocate and WdfFdoInitSetFilter; then we're
activating the "Great Escape" by calling
WdfDeviceInitAssignWdmIrpPreprocessCallback. Finally, we WdfDeviceCreate
it, and attach it to the keyboard stack.
Using a trivial passthrough PreprocessCallback gets around the problem
that KMDF control devices don't have PNP handling code in them, and
therefore can't normally be attached to PNP driver stacks.
Anyway, all is good in Vista and even Win7, up until WLK 1.4, which
insists on using the 1.9 KMDF coinstaller, which in turn necessitates
using the 1.9 KMDF itself (we were using 1.7, but of course, 1.9 will get
picked up automatically at some point anyway).
In KMDF 1.9, it appears that some code changed that bluescreens when WDF
Verifier is turned on (as *also* required for the first time by the 1.4
WLK). The proximate location for this is WdfFdoInitSetFilter, but we've
tried taking that out (and even manually setting that bit ourselves as an
experiment), and it only postpones the problem until later.
A !analyze -v is attached at the bottom.
Any suggestions?
Thanks,
Ray
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Unknown bugcheck code (0)
Unknown bugcheck description
Arguments:
Arg1: 00000000
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000
Debugging Details:
------------------
ERROR: Could Not Find Target OS Version. Please Update
GetFunctionForOSVer to include target OS Version
PROCESS_NAME: System
FAULTING_IP:
nt!DbgBreakPoint+0
8287022c cc int 3
EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 8287022c (nt!DbgBreakPoint)
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 3
Parameter[0]: 00000000
Parameter[1]: 84aab4c0
Parameter[2]: 00000000
ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Breakpoint A breakpoint
has been reached.
EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments
are invalid
EXCEPTION_PARAMETER1: 00000000
EXCEPTION_PARAMETER2: 84aab4c0
EXCEPTION_PARAMETER3: 00000000
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0x0
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from 855957f6 to 8287022c
STACK_TEXT:
80e4aaf8 855957f6 82c126ee 92eb4470 0000fffe nt!DbgBreakPoint
80e4ab0c 8c8fd216 8d950508 8c1b0030 80e4abfc
Wdf01000!imp_WdfFdoInitSetFilter+0x6e
80e4ab1c 8c8fcadc 8c1b0030 00000000 84aab4c0
SynTP!WdfFdoInitSetFilter+0x16
[t:\tools\winddk\7100.0\inc\wdf\kmdf\1.9\wdffdo.h @ 295]
80e4abfc 8c9066fd 00000000 00000000 0000000b
SynTP!CntDevice::InitializeControl+0x1ec
[c:\source\driver\kernel\winnt\lib\cntdevice.cpp @ 333]
80e4ac38 829ce55e 80e4acac 8c961d08 92eb4470
SynTP!CosKBFilter::PnPNotifyInterfaceChange+0xbd
[c:\source\driver\kernel\winnt\share\os\coskbfilter.cpp @ 604]
80e4ac78 8299f4cd 80e4acac 80e4aca0 00000000
nt!PnpNotifyDriverCallback+0x107
80e4acd8 829d4e86 92f2b3d4 80e4acf8 8db75ce0
nt!PnpNotifyDeviceClassChange+0x159
80e4ad00 8286d2f7 8db75ce0 00000000 84aab4c0 nt!PnpDeviceEventWorker+0x1e3
80e4ad50 829e420d 00000001 05a4e960 00000000 nt!ExpWorkerThread+0x10d
80e4ad90 82887dd9 8286d1ea 00000001 00000000
nt!PspSystemThreadStartup+0x9e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19
STACK_COMMAND: kb
FOLLOWUP_IP:
SynTP!WdfFdoInitSetFilter+16
[t:\tools\winddk\7100.0\inc\wdf\kmdf\1.9\wdffdo.h @ 295]
8c8fd216 5d pop ebp
FAULTING_SOURCE_CODE:
291: PWDFDEVICE_INIT DeviceInit
292: )
293: {
294: ((PFN_WDFFDOINITSETFILTER)
WdfFunctions[WdfFdoInitSetFilterTableIndex])(WdfDriverGlobals,
DeviceInit);
296:295: }
297: //
298: // WDF Function: WdfFdoInitSetDefaultChildListConfig
299: //
300: typedef
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: SynTP!WdfFdoInitSetFilter+16
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: SynTP
IMAGE_NAME: SynTP.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 4a1dbf33
FAILURE_BUCKET_ID: 0x0_VRF_SynTP!WdfFdoInitSetFilter+16
BUCKET_ID: 0x0_VRF_SynTP!WdfFdoInitSetFilter+16
Followup: MachineOwner
---------
.
- Follow-Ups:
- References:
- Prev by Date: mouse driver
- Next by Date: Re: NDIS 6.0 Virtual Miniport
- Previous by thread: Bluescreen when we try to attach a filter to another device stack in KMDF
- Next by thread: Re: Bluescreen when we try to attach a filter to another device stack in KMDF
- Index(es):
Relevant Pages
|
