SCSI Miniport and WMI

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 :frowning: (It works fine if I don’t set this flag to TRUE).

I guess I am doing the WMI related stuff as described in the DDK (Binary MOF compiled with the Driver sys file). I have notice 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.

What am I doing wrong? Or something is wrong in SCSIPORT itself? My miniport is based on DDK SCSI miniport sample aha154x.

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?

Any help is hugely appreciated!!

Thanks in advance!