Re: WMI question

Hi guys,
  If anyone is interested, here's an update on my progress with this WMI
problem. I tracked the problem down to a function call that was quietly
failing and not telling anyone about it. the problem code is below:

hres = pclsObj->Get(L"Name", 0, &vtProp, 0, 0);

this was failing with WBEM_E_NOT_FOUND (which means that the specified
property was not found, i.e. the 'Name' property in this case) when
certain Win32_ query strings were being sent because those don't have a
'Name' property that the function can get. I verified this by looking up the
class definitions for Win32_Processor (which performs perfectly) it does
have a 'Name' property and I also looked up the class definition for
Win32_WMIElementSetting, which was one of the queries that was crashing the
program. The Win32_WMIElementSetting, along with the other query strings
that were crashing the program don't have a 'Name' property that the Get( )
function can return.  This was also causing my calls to VariantChangeType( )
to fail with DISP_E_BADVARTYPE and DISP_E_TYPEMISMATCH that means that the
vtProp.bstrVal could not be converted into a type that wcout( ) wouldn't
choke on.

Even if I can't do anything about the crashes when the 'problem' strings are
sent to the program (other than not use that particular set of query
strings), atleast I figured out the problem and tracked it to its source,
i.e. the class definitions themselves, for the query strings that are
causing the crashes...

Thanks for all your help guys.

On Sat, Dec 4, 2010 at 7:35 PM, John Smith <[email protected]> wrote:

> Hi Kim,
>   I think you're on to something here, I used a query that normally causes
> the program to crash and I commented out the
> wcout<< "Data Name : " << vtProp.bstrVal<< endl;   line and although the
> program didn't print any information, it also did not crash, which is a
> positive sign. I did try casting the bstr to a const wchar_t* but it didn't
> seem to help, I wonder if I could load the data into an array and step
> through it in a for loop just to see what information is actually there
> before it is sent to wcout( )? I'll keep working and see what I can come up
> with. Thanks again for your help.
>
>
> John
>
>   On Sat, Dec 4, 2010 at 12:38 AM, Kim Gräsman <[email protected]>wrote:
>
>>
>>
>> Hi John,
>>
>>  On Sat, Dec 4, 2010 at 02:21, John Smith <[email protected]> wrote:
>>>
>>>  I just found out that google will not let me attach a lib file that is
>>> needed for the project. the file is WbemUuid.lib, if your SDK's are up to
>>> date, you should have it already.
>>>
>>
>>             VARIANT vtProp;
>>
>>             // Get the value of the Name property
>>             hres = pclsObj->Get(L"Name", 0, &vtProp, 0, 0);
>>             wcout<< "Data Name : " << vtProp.bstrVal<< endl;   //changing
>> vtProp.bstrVal to one of the other 'dot' member
>>             VariantClear(&vtProp);   //variables seems to keep it from
>> crashing, but the data
>>         }   //that is reported is garbage...
>>
>> I think the BSTR you get back may not be zero-terminated. They are
>> apparently supposed to be, see [1], but I seem to recall the rule was that
>> they may be but aren't required to, since the length is already available in
>> the prefix.
>>
>> I'd try and wrap it in a _bstr_t and call its conversion operator to a
>> wide string;
>>
>>   wcout<< "Data Name : " << (const wchar_t*) _bstr_t(vtProp.bstrVal) <<
>> endl;
>>
>> Also, when you get a VARIANT out of a COM method, it's always a good idea
>> to check its type before attempting to use it. Try and inspect the vtProp.vt
>> member in your debugger, and compare it to the VT_ flags in wtypes.h. If the
>> type is anything other than VT_BSTR, the bstrVal member is not valid.
>>
>> So, you may need to change the type of the value into a string before
>> printing it, using VariantChangeType(Ex).
>>
>> Hope that helps,
>> - Kim
>>
>> [1] http://msdn.microsoft.com/en-us/library/ms221069.aspx
>>
>> - BSTRs are length-prefixed and wide strings are zero-terminated
>> - BSTRs MAY BE zero-terminated but aren't required to be, since the length
>> is available from the prefix
>>
>>  
>>
>
>