Can anyone get FileSelectPopuEx and WMI calls to CoInitializeEx / CoInitializeSecurity to coexists in same code?

[blakney]

I am having a problem running the attached code which in an ideal world would allow me to access the hard drive serial numbers on the host PC and use the FileSelectPopupEx function in any order.

It seems as soon as I run FileSelectPopupEx (even by cancelling) the hard drive code ceases to function. It will retrun errors at CoInitializeEx if run from the same thread or CoInitializeSecurity if run from separate threads.

Based on the help for the 3 functions, it is likely the error is caused by the apartment mode for the pieces of code. With the WMI needing an MTA and the FileSelectpopupEx needing to be single threaded compartment. The FileSelectPopupEx suggests running in a separate thread to avoid conflicts. I have attempted this and unless I messed that up, separate threads did not fix the whole problem.

Since I never plan on running these items simultaneously, it would be eneough to "uninitialize" the environment variables set by by FileSelectPopupEx after each instance in my case. Unfortunately, I am at a bit of a loss as to which bits to toggle.

As for the attached code, I have tried to run in both CVI2012 SP1 (32 bit and 64 bit) and CVI2013 (SP1 (32 bit and 64 bit) with identical results. If you want to recreate the issues just link to the  following static libraries from the SDK lib for CVI : WbemUuid.lib, Ole32.lib, OleAut32.lib, propsys.lib.

[blakney]

I should add if you run both in same thread but run CoUninitialize () after FileSelctPopupEx then there is no error on CoInitialzeEx() but the CoIntialiazeSecurity returns an error.

[blakney · Accepted solution]

I found out the "error" code in this case was just a warning that CoinitializeSecurity has already been called. The code is equal to RPC_E_TOO_LATE and can be swallowed with the following slight modification to the supplied code.

if (FAILED(hr) && !(hr == RPC_E_TOO_LATE))

Sorry to bug everyone.