WMI Method Call

I have implemented WMI in our driver. Now we want to make function calls with strings as in and out but the examples in the WDK only shows integer call. We now how it works with properties in classes.
Does anyone know where in the web lays an example which shows the usage with strings?

Solved with reference to this:
http://www.osronline.com/ShowThread.cfm?link=119542

No, It doesn*t work.

We want to do the following:
void GetDriverProperty([in, MaxLen(256)] string InData,
[out, MaxLen(256)] string OutData);

I get on the client site the errorcode wbemErrInvalidParameter but the EVT_WDF_WMI_INSTANCE_EXECUTE_METHOD function is called in the driver.

the inputbuffer is correct and we get the string from the client. Ihe OutBufferSize at execute method in the driver is 2 (mof file setting is 256). We set the buffer (PVOID Buffer) with our Output data and the driver crashs on the pool.

What must be done that we can return a string from the driver?

In the thread “http://www.osronline.com/ShowThread.cfm?link=119542” I find the following statement:
Are you passing a big enough buffer in the calling application to the ExecuteMethod call?

The Outparameter on the client site is set to NULL. The length of the output variable depends on the driver data but is set to 256 as maxlength

We follow the toaster example.

Here a second question comes into mind. What must be done if I want to return 2 Output string variables?

We also consulted the docs, examples and the web but we no further help on this topic.

The docs on the exact WMI record layout requirements are not super clear, and in the past had to do quite a few experiments on complex records.

I’ve used this function for years to correctly fill in a WMI return string.

// this function formats a unicode string to the correct format for a WMI record field
void FormatUnicodeToWMIString(PCUNICODE_STRING sourceString,
PWCHAR destinationWMIField,
ULONG wmiFieldSizeInBytes)
{
ASSERT(wmiFieldSizeInBytes < 0x7FFF);
RtlZeroMemory(destinationWMIField, wmiFieldSizeInBytes);
destinationWMIField[0] = (WCHAR)(wmiFieldSizeInBytes - sizeof(WCHAR));
RtlCopyMemory(&(destinationWMIField[1]), sourceString->Buffer, min(sourceString->Length, wmiFieldSizeInBytes - sizeof(WCHAR)));
}

FormatUnicodeToWMIString(&driverBuildString, instance->InternalBuild, sizeof(instance->InternalBuild));

You need to make sure the method reply size matches up with the embedded string size. Note the above function sets the embedded size to always be the maximum size, which is needed when strings are in the middle of a record or method parameters list. I don’t offhand remember what’s correct if the last parameter is a variable (possibly large) string.

I am not sure about method string parameters, but some kinds of method parameters need the ToInstance attribute, like for this return buffer:

[WmiMethodId(8), Implemented, Description(“Get the entry”) : amended]
void query_entry(
[in] uint32 start_index,
[in] uint32 nbr_entries,
[out] uint32 data_size,
[out, DisplayInHex, WmiSizeIs(“data_size”):ToInstance] uint64 entry
);

Jan

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@x-publisher.com
Sent: Sunday, January 28, 2018 11:48 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] WMI Method Call

No, It doesn*t work.

We want to do the following:
void GetDriverProperty([in, MaxLen(256)] string InData,
[out, MaxLen(256)] string OutData);

I get on the client site the errorcode wbemErrInvalidParameter but the EVT_WDF_WMI_INSTANCE_EXECUTE_METHOD function is called in the driver.

the inputbuffer is correct and we get the string from the client. Ihe OutBufferSize at execute method in the driver is 2 (mof file setting is 256). We set the buffer (PVOID Buffer) with our Output data and the driver crashs on the pool.

What must be done that we can return a string from the driver?

In the thread “http://www.osronline.com/ShowThread.cfm?link=119542” I find the following statement:
Are you passing a big enough buffer in the calling application to the ExecuteMethod call?

The Outparameter on the client site is set to NULL. The length of the output variable depends on the driver data but is set to 256 as maxlength

We follow the toaster example.

Here a second question comes into mind. What must be done if I want to return 2 Output string variables?

We also consulted the docs, examples and the web but we no further help on this topic.


NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>

The driver crashs and it seems that the RTLZeroMemory does it. By the way the OutBufferSize is always 2

BAD_POOL_HEADER (19)
The pool is already corrupt at the time of the current request.
This may or may not be due to the caller.

I do the following and set the out with your routine. Here the difference was that you set the length minus the end delimiter.

[Implemented, WmiMethodId(1)]
void GetDriverProperty([in, Id(0)] string InData,
[out, Id(1), WmiSizeIs(“256”):ToInstance] string OutData);

typedef struct _GetDriverProperty_OUT
{
WCHAR OutData[256];
}

typedef struct _GetDriverProperty_IN
{
WCHAR OutData[256];
WCHAR InData[128];
#define GetDriverProperty_IN_InData_ID 1
#define GetDriverProperty_IN_InData_SIZE 1

} GetDriverProperty_IN, *PGetDriverProperty_IN;

Are you checking if the return buffer size is sufficient to hold the return data, and return the correct error code and desired buffer size if not? WMI will then call the same method again with the requested return buffer size, and you can then fill in the reply with data. On the first call, the buffer may be smaller than the required return buffer size. This is tricky if the reply size is dynamically varying, as you can’t fail the method call a second time with a new increased size. If your return data is larger than you input data, expect to always have to return an error on the first call, and then process things again when it calls again with a larger buffer.

Jan

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@x-publisher.com
Sent: Monday, January 29, 2018 1:46 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] WMI Method Call

The driver crashs and it seems that the RTLZeroMemory does it. By the way the OutBufferSize is always 2

BAD_POOL_HEADER (19)
The pool is already corrupt at the time of the current request.
This may or may not be due to the caller.

I do the following and set the out with your routine. Here the difference was that you set the length minus the end delimiter.

[Implemented, WmiMethodId(1)]
void GetDriverProperty([in, Id(0)] string InData,
[out, Id(1), WmiSizeIs(“256”):ToInstance] string OutData);

typedef struct _GetDriverProperty_OUT
{
WCHAR OutData[256];
}

typedef struct _GetDriverProperty_IN
{
WCHAR OutData[256];
WCHAR InData[128];
#define GetDriverProperty_IN_InData_ID 1
#define GetDriverProperty_IN_InData_SIZE 1

} GetDriverProperty_IN, *PGetDriverProperty_IN;


NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>

Thank you Jan. It works now.

Only one problem left with the WMI function call. The problem is the ReturnValue. The function call is S_OK on the client site and all params come back from the kernel but the ReturnValue from Get on the client site is always 0.
We have defined:
[Implemented, WmiMethodId(1)]
uint32 GetDriverProperty([in, Id(0)] string InData,
[out, Id(1)] string OutData);
and the Out struct is:
typedef struct _GetDriverProperty_OUT
{
WCHAR OutData[256];
ULONG ReturnValue;

} GetDriverProperty_OUT, *PGetDriverProperty_OUT;

As described in the docs the ReturnValue should not have an Id. The ReturnValue lays in the memory like any other numeric value.

What mus be done that this works?

I can’t remember ever using WMI method return values in drivers, only in or out parameters.

When you use the WMI methods from powershell, it syntactically looks like…

// this gets the WMI object
$myWMIObj = WMIObject -Namespace root/wmi_myObj -Filter “myInstanceKey = ‘foo1’”

// this does the WMI method call on the selected instance, which passes 3 in values and returns some out values, one is named outParm1
$results1 = $myWMIObject.myMethod1(1,7,$parm1)

If ($results1.outParm1 -eq 1) { // some code }

At least in powershell, your method return value is an object with a property for each out parameter, much like an object in JavaScript. I assume a return value, if they do work, would just be another property in that return object.

The low level user mode WMI interface functions build an in parameter object with all in parameters as dynamic properties on that object, and then it does the call with one in parameter object and one empty out parameter object (which gets properties set as part of the call reply), and it gets back an integer COM status telling if the call worked. WMI is based on dynamic objects, we just are required to deal with them as fixed structures in drivers. If you write a user mode WMI function, you deal more with the dynamic WMI objects.

You said the return value is S_OK, which sounds like a COM status code, telling you if the COM WMI call was successful, which it was, no matter what value you stuff in the ReturnValue property. The out values come back in the response object as properties. It’s way easier to exercise WMI interfaces from powershell than C/C++. I believe .Net handles WMI as dynamic objects directly.

Jan

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@x-publisher.com
Sent: Monday, January 29, 2018 11:24 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] WMI Method Call

Only one problem left with the WMI function call. The problem is the ReturnValue. The function call is S_OK on the client site and all params come back from the kernel but the ReturnValue from Get on the client site is always 0.
We have defined:
[Implemented, WmiMethodId(1)]
uint32 GetDriverProperty([in, Id(0)] string InData,
[out, Id(1)] string OutData); and the Out struct is:
typedef struct _GetDriverProperty_OUT
{
WCHAR OutData[256];
ULONG ReturnValue;

} GetDriverProperty_OUT, *PGetDriverProperty_OUT;

As described in the docs the ReturnValue should not have an Id. The ReturnValue lays in the memory like any other numeric value.

What mus be done that this works?


NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>

Yes, we test the interface with C++, COM.

>telling you if the COM WMI call was successful, which it was, no matter
>what value you stuff in the ReturnValue property

No, this is not correct. You get only S_OK if the parameter is defined. I
tested it.

Sure, it is more easy to do it with powershell but we have other
requirements.

No problem, I define now the ReturnValue as one out param and make the
function =B3void".

Thanks
Manfred

On 30.01.18, 10:32, “xxxxx@pmatrix.com

wrote:

>I can’t remember ever using WMI method return values in drivers, only in
>or out parameters.
>
>When you use the WMI methods from powershell, it syntactically looks
>like…
>
>// this gets the WMI object
>$myWMIObj =3D WMIObject -Namespace root/wmi_myObj -Filter “myInstanceKey =3D
>‘foo1’”
>
>// this does the WMI method call on the selected instance, which passes
>3 in values and returns some out values, one is named outParm1
>$results1 =3D $myWMIObject.myMethod1(1,7,$parm1)
>
>If ($results1.outParm1 -eq 1) { // some code }
>
>At least in powershell, your method return value is an object with a
>property for each out parameter, much like an object in JavaScript. I
>assume a return value, if they do work, would just be another property in
>that return object.
>
>The low level user mode WMI interface functions build an in parameter
>object with all in parameters as dynamic properties on that object, and
>then it does the call with one in parameter object and one empty out
>parameter object (which gets properties set as part of the call reply),
>and it gets back an integer COM status telling if the call worked. WMI is
>based on dynamic objects, we just are required to deal with them as fixed
>structures in drivers. If you write a user mode WMI function, you deal
>more with the dynamic WMI objects.
>
>You said the return value is S_OK, which sounds like a COM status code,
>telling you if the COM WMI call was successful, which it was, no matter
>what value you stuff in the ReturnValue property. The out values come
>back in the response object as properties. It’s way easier to exercise
>WMI interfaces from powershell than C/C++. I believe .Net handles WMI as
>dynamic objects directly.
>
>Jan
>
>
>-----Original Message-----
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com] On Behalf Of
>xxxxx@x-publisher.com
>Sent: Monday, January 29, 2018 11:24 PM
>To: Windows System Software Devs Interest List
>Subject: RE:[ntdev] WMI Method Call
>
>Only one problem left with the WMI function call. The problem is the
>ReturnValue. The function call is S_OK on the client site and all params
>come back from the kernel but the ReturnValue from Get on the client site
>is always 0.
>We have defined:=20
> [Implemented, WmiMethodId(1)]
> uint32 GetDriverProperty([in, Id(0)] string InData,
> [out, Id(1)] string OutData); and the Out struct
>is:
>typedef struct _GetDriverProperty_OUT
>{=20
> WCHAR OutData[256];
> ULONG ReturnValue;
>
>} GetDriverProperty_OUT, *PGetDriverProperty_OUT;
>
>As described in the docs the ReturnValue should not have an Id. The
>ReturnValue lays in the memory like any other numeric value.
>
>What mus be done that this works?
>
>—
>NTDEV is sponsored by OSR
>
>Visit the list online at:
>http:
>
>MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>software drivers!
>Details at http:
>
>To unsubscribe, visit the List Server section of OSR Online at
>http:
>
>—
>NTDEV is sponsored by OSR
>
>Visit the list online at:
>http:
>
>MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>software drivers!
>Details at http:
>
>To unsubscribe, visit the List Server section of OSR Online at
>http:</http:></http:></http:></http:></http:></http:>