Re: Register to wmi via wdf driver
- From: "Doron Holan [MSFT]" <doronh@xxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 22 May 2008 14:09:47 -0700
to further clarify, KMDF does not support registering with WMI on a control WDFDEVICE.
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.
"Doron Holan [MSFT]" <doronh@xxxxxxxxxxxxxxxxxxxx> wrote in message news:uF1EeAFvIHA.552@xxxxxxxxxxxxxxxxxxxxxxx
which WDFDEVICE are you registering your WMI provider on? is it the same WDFDEVICE? or is each control logical device its own WDFDEVICE? If it is is own WDFDEVICE, is it a control WDFDEVICE or a PDO WDFDEVICE that you enumerate from the parent?
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.
"ariels" <ariels@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:99212326-1313-4E1C-8354-441FEF2A82A0@xxxxxxxxxxxxxxxxHi,
I have a problem with registering new wmi provider for my device driver :
My driver has control logical devices that controls pnp devices , each
control logical device registers one wmi provider.
After the device created and the wmi create provider function terminated
succesfuly.
it seems that it enter to the wdf01000.sys driver (swithing to other thread
context that locks and raises the IRQL to dispatch then trying to access page
data and the driver crash)
via the stack trace it seems that the bug check occures in the
wdf01000!FxWmiIrpHandler::_RegInfo function.
I do not know if there is a problem in the wdf01000.sys or a problem with
the parameters that were sent to wdf01000.sys driver by my driver via the
WdfWmiInstanceCreate function .
my driver crash with bugcheck IRQL_NOT_LESS_OR_EQUAL (a).
here is the dump :
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: ffffffe8, memory referenced
Arg2: d0000002, 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: 8086c736, address which referenced memory
Debugging Details:
------------------
WRITE_ADDRESS: ffffffe8
CURRENT_IRQL: 2
FAULTING_IP:
nt!ObfReferenceObject+18
8086c736 f00fc106 lock xadd dword ptr [esi],eax
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0xA
PROCESS_NAME: System
TRAP_FRAME: f78f2b84 -- (.trap 0xfffffffff78f2b84)
ErrCode = 00000002
eax=00000001 ebx=85702000 ecx=00000000 edx=00000000 esi=ffffffe8 edi=85702024
eip=8086c736 esp=f78f2bf8 ebp=f78f2c40 iopl=0 nv up ei pl nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010202
nt!ObfReferenceObject+0x18:
8086c736 f00fc106 lock xadd dword ptr [esi],eax
ds:0023:ffffffe8=????????
Resetting default scope
LAST_CONTROL_TRANSFER: from 80826967 to 80871f20
STACK_TEXT:
f78f2780 80826967 00000003 00000000 00000000 nt!RtlpBreakWithStatusInstruction
f78f27cc 8082786b 00000003 ffffffe8 8086c736 nt!KiBugCheckDebugBreak+0x19
f78f2b64 8088c963 0000000a ffffffe8 d0000002 nt!KeBugCheck2+0x5e1
f78f2b64 8086c736 0000000a ffffffe8 d0000002 nt!KiTrap0E+0x2a7
f78f2bf8 f53bcaeb 8596ffa0 860edba4 f53d0ba0 nt!ObfReferenceObject+0x18
f78f2c40 f53bd1cb 8596ffa0 860eda38 00000000
wdf01000!FxWmiIrpHandler::_RegInfo+0x14c
f78f2c88 f5398665 860eda38 f78f2cb0 f5398888
wdf01000!FxWmiIrpHandler::Dispatch+0x1d8
f78f2c94 f5398888 8567a4f8 860eda38 c00000bb wdf01000!FxDevice::Dispatch+0x7f
f78f2cb0 8081df65 8567a4f8 860eda38 860eda38
wdf01000!FxDevice::DispatchWithLock+0x7b
f78f2cc4 80980320 f78f2d48 860eda38 85702000 nt!IofCallDriver+0x45
f78f2cf0 809803e9 860eda38 0000000b 8567a402 nt!WmipForwardWmiIrp+0x17e
f78f2d1c 809821d3 0000000b 8567a4f8 00000000 nt!WmipSendWmiIrp+0x59
f78f2d58 80982275 85662ba0 00000000 f78f2d80 nt!WmipRegisterOrUpdateDS+0x53
f78f2d68 809825c2 85662ba0 8639b8d0 808ae5fc nt!WmipRegisterDS+0xf
f78f2d80 8088043d 00000000 00000000 8639b8d0 nt!WmipRegistrationWorker+0x50
f78f2dac 80949b7c 00000000 00000000 00000000 nt!ExpWorkerThread+0xeb
f78f2ddc 8088e062 80880352 00000001 00000000 nt!PspSystemThreadStartup+0x2e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
STACK_COMMAND: kb
FOLLOWUP_IP:
wdf01000!FxWmiIrpHandler::_RegInfo+14c
f53bcaeb 8b45e8 mov eax,dword ptr [ebp-18h]
SYMBOL_STACK_INDEX: 5
SYMBOL_NAME: wdf01000!FxWmiIrpHandler::_RegInfo+14c
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: wdf01000
IMAGE_NAME: wdf01000.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 47919015
FAILURE_BUCKET_ID: 0xA_W_wdf01000!FxWmiIrpHandler::_RegInfo+14c
BUCKET_ID: 0xA_W_wdf01000!FxWmiIrpHandler::_RegInfo+14c
Followup: MachineOwner
---------
please advice
Thanks,
Ariels
.
- Follow-Ups:
- Re: Register to wmi via wdf driver
- From: ariels
- Re: Register to wmi via wdf driver
- From: ariels
- Re: Register to wmi via wdf driver
- References:
- Register to wmi via wdf driver
- From: ariels
- Re: Register to wmi via wdf driver
- From: Doron Holan [MSFT]
- Register to wmi via wdf driver
- Prev by Date: Re: Register to wmi via wdf driver
- Next by Date: Re: Why does formatting requests for USB targets fail?
- Previous by thread: Re: Register to wmi via wdf driver
- Next by thread: Re: Register to wmi via wdf driver
- Index(es):
Relevant Pages
|
