IOWMIOpenBlock

NTDEV
1

Hi

I am getting a 7e - c0005 Bug Check , my Schema is published and able to read usign CIM Stuido , but when I try Access from Driver it faults , can any body tell me what is worng with my code

!analyze -v Points to IOWMIOpenBlock Call

Thanks,
Manohara

DEFINE_GUID(XXXXX_GUID,0xa26f5000,0x7f22,0x41ab,0x8d,0x07,0x70,0x13,0x02,0x6b,0xcd,0xcf);

VOID DriverUnload(__in PDRIVER_OBJECT DriverObject);

NTSTATUS DriverEntry(__in PDRIVER_OBJECT DriverObject,__in PUNICODE_STRING RegistryPath)
{
NTSTATUS status = STATUS_SUCCESS;
ULONG ulIndex = 0;
GUID guid;

PVOID myHandle = NULL;

DebugPrint((“Compilet at %s %s \n”,DATE,TIME));
UNREFERENCED_PARAMETER (RegistryPath);

DriverObject->DriverUnload = DriverUnload;
RtlCopyBytes(&guid,&XXXXX_GUID,sizeof(GUID));

status = IoWMIOpenBlock(&guid,WMIGUID_QUERY,myHandle);
if (!NT_SUCCESS(status))
{
DebugPrint((“IoWMIOpenBlock Failure %X\n”,status));
}

//try

if (myHandle)
{
DebugPrint((“Calling ObDereferenceObject \n”,status));
ObDereferenceObject(myHandle);
}

DebugPrint ((“Entered the Driver Entry\n”));

return status;
}

VOID DriverUnload(__in PDRIVER_OBJECT DriverObject)
{
DebugPrint ((“unload\n”));
return;
}

2

xxxxx@hotmail.com wrote:

Hi

I am getting a 7e - c0005 Bug Check , my Schema is published and able to read usign CIM Stuido , but when I try Access from Driver it faults , can any body tell me what is worng with my code

!analyze -v Points to IOWMIOpenBlock Call

DEFINE_GUID(XXXXX_GUID,0xa26f5000,0x7f22,0x41ab,0x8d,0x07,0x70,0x13,0x02,0x6b,0xcd,0xcf);

VOID DriverUnload(__in PDRIVER_OBJECT DriverObject);

NTSTATUS DriverEntry(__in PDRIVER_OBJECT DriverObject,__in PUNICODE_STRING RegistryPath)
{
…
PVOID myHandle = NULL;
…
status = IoWMIOpenBlock(&guid,WMIGUID_QUERY,myHandle);

The third parameter to IOWMIOpenBlock is an output parameter. You need a &:

status = IoWMIOpenBlock( &guid, WMIGUID_QUERY, &myHandle );

Without it, you’re telling IoWMIOpenBlock to store the result at address
0. That will result in a C0000005 exception, which seems awfully familiar.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

3

Tim

Thanks for the reply ,

This site deserves more complex queries than some some stupid ‘C’ mistakes

that was really stupid of me (this is what happens after couple of Sleepless Nights :slight_smile: )

Sorrie Guys !

Thanks,
Manohara

4

xxxxx@hotmail.com wrote:

Tim

Thanks for the reply ,

This site deserves more complex queries than some some stupid ‘C’ mistakes

that was really stupid of me (this is what happens after couple of Sleepless Nights :slight_smile: )

Ah, but surely we can use this to add fuel to the C vs C++ fire. void*
is the universal pointer type in C, so passing a void* to a routine that
expects a void**, as you did here, is not a problem. But in C++, this
would have caused a compile-time warning…

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

5

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> Ah, but surely we can use this to add fuel to the C vs C++ fire. void*
> is the universal pointer type in C, so passing a void* to a routine that
> expects a void**, as you did here, is not a problem. But in C++, this
> would have caused a compile-time warning…

But you don’t need C++ for the check, just use /W4 /WX and this will refuse
to compile in C without an explicit cast.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com