Error from CoInitializeSecurity (WMI)

**Anders** · 12 October 2009, 23:41

first one just means CoInitializeSecurity has already been called (this function is process wide and only works once) Maybe some kind of injected shell extension or something on the failing machines?

as far as the other one goes, what does WBEMTest.exe do on the failing machine?

as a final note, getting logical drives can be done without using WMI

**demiller9** · 13 October 2009, 00:33

When it doesn't fail on the ole32::CoInitializeSecurity, it makes it through the next 2 calls OK (ole32::CoCreateInstance, IWbemLocator->ConnectServer) but gets a 0xC0000005 returned by the call on line 92 to IWbemServices->ExecQuery. The program doesn't terminate, but I guess it means to COM-connected process terminated. I don't try to use the other value (a IEnumWbemClassObject) that it ought to return.

I'm home now, so I can't try any experiments or investigate the injected shell extension theory until tomorrow.

About other ways to get logical drives - are you suggesting there is an API for it? I want to find the logical drives, and for each one I want to know if it is a CD or removable drive, what size it is, and the current volume name (if there is media in it).

Don

**Anders** · 13 October 2009, 01:11

if WBEMTest.exe works where IWbemServices->ExecQuery called by system.dll fails, there could be a bug in the COM handling or using wrong parameter somewhere. If it also fails with WBEMTest.exe, I'm guessing there is a problem with the COM default security on that machine

As far as native API goes, call GetLogicalDriveStrings() or GetDriveType() directly in a loop. GetVolumeInformation() gives you label, GetDiskFreeSpace[Ex]() the size. It should also be noted that a volume could be mounted in a subfolder somewhere and not have a dos style drive letter at all, for those, call FindFirstVolume+FindFirstVolumeMountPoint and friends IIRC

**demiller9** · 13 October 2009, 01:55

I misunderstood your earlier question asking what WBEMTEST.exe does on the failing machine. It works properly, I get successful data back from all the queries I'm using.

**demiller9** · 14 October 2009, 04:27

Thought I found a solution, but it still crashes

I read the MSDN article on Getting WMI Data from the Local Computer and saw a note that says on Win2000 you have to specify the default authentication credentials for a user by using a SOLE_AUTHENTICATION_LIST structure in the pAuthList parameter of CoInitializeSecurity .

I've tried to do that but my program crashes now on the call to CoInitializeSecurity. I know this isn't really a NSIS problem at this point, but hope that Anders, F0rt or someone can spot what I've done wrong. Here's the part that sets up the call to CoInitializeSecurity. I have tried it with and without the SOLE_AUTHENTICATION_SERVICE structure, it crashes either way. It runs fine on XP and Vista.

code:
!define RPC_C_AUTHN_DEFAULT  0xFFFFFFFF

!define RPC_C_AUTHZ_DEFAULT  0xFFFFFFFF



${If} ${IsWin2000}

	; allocate and initialize SOLE_AUTHENTICATION_INFO Structure

	System::Call "*(i ${RPC_C_AUTHN_DEFAULT}, i ${RPC_C_AUTHZ_DEFAULT}, i 0)i.r2"

	; allocate and initialize SOLE_AUTHENTICATION_LIST Structure

	System::Call "*(i 1, i r2)i.r3"

	; allocate and initialize SOLE_AUTHENTICATION_SERVICE Structure

	System::Call "*(i ${RPC_C_AUTHN_DEFAULT}, i ${RPC_C_AUTHZ_DEFAULT}, i 0, i 0)i.r4"

	StrCpy $5 1

${Else}

	StrCpy $2 0

	StrCpy $3 0

	StrCpy $4 0

	StrCpy $5 -1

${EndIf}



System::Call "ole32::CoInitializeSecurity( \

   i 0,               ; PSECURITY_DESCRIPTOR pSecDesc \

   i r5,              ; LONG cAuthSvc \

   i r4,              ; SOLE_AUTHENTICATION_SERVICE *asAuthSvc \

   i 0,               ; void *pReserved1 \

   i ${RPC_C_AUTHN_LEVEL_DEFAULT},    ; DWORD dwAuthnLevel \

   i ${RPC_C_IMP_LEVEL_IMPERSONATE},  ; DWORD dwImpLevel \

   i r3,              ; void *pAuthList \

   i ${EOAC_NONE},    ; DWORD dwCapabilities \

   i 0) i.r1"

TIA
Don

**Anders** · 14 October 2009, 20:40

Your code looks correct to me.

Would it be possible for you to write a little app in C to test so we could rule out the system plugin? or alternatively debug WBEMTEST.exe and check the parameters it passes to CoInitializeSecurity

(Also, using comments like that in a plugin parameter might not be so smart, not sure if the script parser is able to handle it)

edit:
(this is on XP, not sure if wbemtest is the same on 2000)

code:


0:000> bp ole32!CoInitializeSecurity

...

0:000> kd

0013febc  0013ff1c

0013fec0  01006a64 wbemtest!WinMain+0xc4

0013fec4  00000000

0013fec8  ffffffff << cAuthSvc (-1)

0013fecc  00000000

0013fed0  00000000

0013fed4  00000001 << they are passing RPC_C_AUTHN_LEVEL_NONE

0013fed8  00000003

0013fedc  00000000

0013fee0  00000000

0013fee4  00000000

0013fee8  00000000

0013feec  7c80b529 kernel32!GetModuleHandleA

0013fef0  00151f05

0013fef4  7c80b529 kernel32!GetModuleHandleA

0013fef8  00151f05

0013fefc  00000000

0013ff00  77c39d7a msvcrt!_initterm+0x13

0013ff04  00fbf758

0013ff08  0013ffc0

RPC_C_AUTHN_LEVEL_DEFAULT might equal RPC_C_AUTHN_LEVEL_NONE on a local machine, I don't know (And its documented that you need to pass those extra structs on 2k, so I'm sure its not going to fix it)

**demiller9** · 14 October 2009, 22:00

Thanks for the suggestions. You're right, the script parser does not like the comments embedded in the SYSTEM plugin call strings. I took those out after I spotted that.

I have pretty much duplicated (in NSIS code) the example MSDN showed, it runs on XP but only gets as far as the IWbemServices::ExecQuery call on Win2000. That call doesn't crash the app, but returns a 0xC0000005 error code.

The latest code is attached to this post.

I will look at trying to run the debugger on WbemTest.exe. Here is the call to CoInitializeSecurity that seems to work on both OS's.

code:
; allocate and initialize SOLE_AUTHENTICATION_INFO

System::Call "*(i ${RPC_C_AUTHN_WINNT}, i ${RPC_C_AUTHZ_NONE}, i 0) i .r2"

; allocate and initialize SOLE_AUTHENTICATION_LIST Structure

System::Call "*(i 1, i r2) i .r3"

	

System::Call "ole32::CoInitializeSecurity( \

   i 0, i -1, i 0, i 0, i ${RPC_C_AUTHN_LEVEL_CALL}, \

   i ${RPC_C_IMP_LEVEL_IMPERSONATE}, i r3, i ${EOAC_NONE}, i 0) i.r1"

Don

Attached Files

bios_sn.nsi (4.8 KB, 387 views)

**Anders** · 18 October 2009, 01:23

the WBEMTEST.exe version on windows 2000 does not have CoInitializeSecurity in its import table (it could still be calling it, but it is a bit weird to just not import it normally)

edit: So it does end up calling CoInitializeSecurity after GetProcAddress'ing it (why, I don't know, that function should exist on every version of windows so there is no point in delay loading it)

**Anders** · 18 October 2009, 02:23

looking over your code some more, you are using "w" as the arguments in some places, those arguments are really BSTR's and BSTR != plain unicode string, you can use a BSTR where a unicode string is expected, but not the other way around and the system plugin does not have a BSTR parameter type AFAIK, you can make a proper BSTR with the SysAllocString() function

**Anders** · 18 October 2009, 03:38

I made a little test app in c++, it works fine on XP but fails with WBEM_E_INVALID_CLASS (0x80041010) on IWbemServices->ExecQuery()

Not really sure where to go from here

**Anders** · 18 October 2009, 04:24

Right, got it working now!

For whatever crazy reason, using CLSID_WbemAdministrativeLocator in the call to CoCreateInstance seems to fix things on 2000 (plain CLSID_WbemLocator works fine on XP)

I'll end with a few notes...

I did not use WBEM_FLAG_RETURN_IMMEDIATELY, did not want to deal with semisynchronous calls (whatever they are)
CoInitializeSecurity(0,-1,0,0,1,3,0,0,0)//using the same params as wbemtest
CoCreateInstance(CLSID_WbemAdministrativeLocator,NULL,CLSCTX_INPROC_SERVER,IID_IWbemLocator,(LPVOID*)&WBEMLoc)
I'm not calling CoSetProxyBlanket() IIRC

**demiller9** · 18 October 2009, 06:46

Anders, thanks for continuing work on my problem, and the suggestion that CLSID_WbemAdministrativeLocator might work for me on Win2000.

After a little playing around, I've got it working! I switched to CLSID_WbemAdministrativeLocator and commented out the CoSetProxyBlanket. The SerialNumber came back different (even though here at home I run Win2000 under VirtualBox), but that is accurate (according to what WBEMTest shows.

Then I tried a different query (Select * from Win32Bios) and property ('Name'), and after crashing the WMI repository a few times, it comes back with the BIOS name correctly. Hopefully the crash is just an artifact of the VirtualBox. XP continues to work correctly.

[A few minutes go by] Now I've incorporated those changes into my WMI.nsh, and my app runs in XP and Win2000! Thank you, Anders! I'll need to clean up WMI.nsh, but I plan to put it in the wiki when I've done that.

I'm in the middle of moving to a new apartment and may not be able to try on a true Win2000 system until either Monday or Tuesday.

Don

Attached Files

bios_sn.nsi (5.1 KB, 433 views)

**Anders** · 18 October 2009, 07:13

As far as crashes go, one thing you should fix is the w vs BSTR problem.

code like System::Call "$3->20(w 'WQL', w 'Select * from Win32_BIOS' ... is wrong, like I said, you can't use w, you need proper BSTR's (you can fake BSTR's with the system plugin struct syntax (on BSTR's you are going to free yourself) something like *{i 3,w "abc"}i.r0 but the pointer you must pass is not $0 but $0+4 (length is at -4) )

**Anders** · 6 July 2022, 20:48

A very delayed update here.

Originally Posted by Anders View Post

As far as crashes go, one thing you should fix is the w vs BSTR problem.

Turns out this was very true. On 2000 CLSID_WbemLocator requires a real SysAllocString when calling ExecQuery, CLSID_WbemAdministrativeLocator accepts a plain wide string. XP is happy with the wide string hack for both interfaces.

Neither CoInitializeSecurity nor CoSetProxyBlanket exist on 95RTM but that does not explain why 2000 delay loads CoInitializeSecurity.

I can also confirm that CoSetProxyBlanket on the svc interface can be used instead of CoInitializeSecurity, even on 2000 (Not that it matters in NSIS).

Error from CoInitializeSecurity (WMI)

Error from CoInitializeSecurity (WMI)

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment