Hi there!
I have run into problems while implementing WMI in my SCSI miniport.
Ofcourse, I am using SCSIWMI library (scsiwmi.lib).
As described in the DDK, I set ConfigInfo->WmiDataProvider = TRUE in
HwScsiFindAdapter. This is causing SCSIPORT to crash (It works fine if I
don’t set this flag to TRUE). Stack trace (please see below for full stack
tarce) tells me that it crashes while looking for something(a callback?)
in the Device Extension in SCSIPORT!SpWmiPassToMiniPort. Am I missing
something?
I guess I am doing the WMI related stuff as described in the DDK (Binary
MOF compiled with the Driver sys file). I have noticed that the crash
happens even before any calls to StartIo with function code set to
SRB_FUNCTION_WMI, so I am assuming the only WMI related stuff in my
miniport that has executed at this point is the DATA provider flag in
HwScsiFindAdapter.
My miniport is based on DDK SCSI miniport sample aha154x. Only major diff
being that mine is a VIRTUAL miniport, can that be a problem?
Any help is hugely appreciated!!
Thanks in advance!
This is some info from the kernel debugger.
PS: Unhandled Kernel Mode Exception Pointers = 0xF897C600
Code c0000005 Addr F838AD2C Info0 00000000 Info1 00000004 Info2 00000004
Info3 00000000
*** Fatal System Error: 0x0000007e
(0xC0000005,0xF838AD2C,0xF897CAA4,0xF897C7A4)
Break instruction exception - code 80000003 (first chance)
A fatal system error has occurred.
Debugger entered on first try; Bugcheck callbacks have not been invoked.
A fatal system error has occurred.
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 7E, {c0000005, f838ad2c, f897caa4, f897c7a4}
Probably caused by : SCSIPORT.SYS ( SCSIPORT!SpWmiPassToMiniPort+11a )
Followup: MachineOwner
nt!RtlpBreakWithStatusInstruction:
80581b54 cc int 3
kd> !analyze -v
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************
SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
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.
An exception code of 0x80000002 (STATUS_DATATYPE_MISALIGNMENT) indicates
that an unaligned data reference was encountered. The trap frame will
supply additional information.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: f838ad2c, The address that the exception occurred at
Arg3: f897caa4, Exception Record Address
Arg4: f897c7a4, Context Record Address
Debugging Details:
EXCEPTION_CODE: c0000005
FAULTING_IP:
SCSIPORT!SpWmiPassToMiniPort+11a
f838ad2c 8b4804 mov ecx,[eax+0x4]
EXCEPTION_PARAMETER1: f897caa4
CONTEXT: f897c7a4 – (.cxr fffffffff897c7a4)
eax=00000000 ebx=81fd0af0 ecx=00000000 edx=00000000 esi=f897cc7c
edi=f897cbf4
eip=f838ad2c esp=f897cb6c ebp=f897cc14 iopl=0 nv up ei ng nz ac po
cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010297
SCSIPORT!SpWmiPassToMiniPort+11a:
f838ad2c 8b4804 mov ecx,[eax+0x4]
Resetting default context
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0x7E
LAST_CONTROL_TRANSFER: from f838b9ec to f838ad2c
STACK_TEXT:
f897cc14 f838b9ec 81fcca38 00000008 f897cc7c
SCSIPORT!SpWmiPassToMiniPort+0x11a
f897cc60 f838c188 81fcca38 0097cc7c 81fcca38
SCSIPORT!SpWmiIrpRegisterRequest+0x16b
f897cc8c f8363591 81fccaf0 81d9a628 81d9a628
SCSIPORT!ScsiPortSystemControlIrp+0xe6
f897cca0 804f61de 81fcca38 81d9a628 c00000bb
SCSIPORT!ScsiPortGlobalDispatch+0x1b
f897ccb8 806dc092 f897cd40 81d9a628 81e991d8 nt!IopfCallDriver+0x4f
f897cce8 806dc255 81d9a628 00000008 81fcca38 nt!WmipForwardWmiIrp+0x23b
f897cd14 806de56d 00000008 81fcca38 00000000 nt!WmipSendWmiIrp+0x8b
f897cd50 806de6f6 81fce180 00000000 81fce180
nt!WmipRegisterOrUpdateDS+0xa3
f897cd64 806df6a5 81fce180 81fb4640 805c7bfc nt!WmipRegisterDS+0x42
f897cd80 80590ff5 00000000 00000000 81fb4640
nt!WmipRegistrationWorker+0x101
f897cdac 80683a64 00000000 00000000 00000000 nt!ExpWorkerThread+0x10d
f897cddc 8059e9be 80590ee8 00000001 00000000
nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
FOLLOWUP_IP:
SCSIPORT!SpWmiPassToMiniPort+11a
f838ad2c 8b4804 mov ecx,[eax+0x4]
FOLLOWUP_NAME: MachineOwner
SYMBOL_NAME: SCSIPORT!SpWmiPassToMiniPort+11a
MODULE_NAME: SCSIPORT
IMAGE_NAME: SCSIPORT.SYS
DEBUG_FLR_IMAGE_TIMESTAMP: 3b7d7f2f
STACK_COMMAND: .cxr fffffffff897c7a4 ; kb
BUCKET_ID: 0x7E_SCSIPORT!SpWmiPassToMiniPort+11a
////////////////////////////////////////////
The stack trace tells me that it is causing a memory access violation in
SCSIPORT!SpWmiPassToMiniPort, but I fail to understand why?
Here is some followup:
The first parameter to SpWmiPassToMiniPort is the miniport device object.
And the disassembly at this point is something like this:
f838ad23 8b4598 mov eax,[ebp-0x68]
f838ad26 8b8010010000 mov eax,[eax+0x110]
f838ad2c 8b4804 mov ecx,[eax+0x4]
I can see that [ebp-0x68] is nothing but device extension (SCSIPORT?)
and[eax+0x110] is NULL. I deduce that it is looking for something in
device extension at offset 0x110. What could it be?