Burn failed to initialize COM at EngineRun().

[wixbot]

CoInitializeEx returns 0x80010106 - Cannot change thread mode after it is set.

// initialize COM
hr = ::CoInitializeEx(NULL, COINIT_MULTITHREADED);
ExitOnFailure(hr, "Failed to initialize COM.");
fComInitialized = TRUE;

// Initialize dutil.
LogInitialize(::GetModuleHandleW(NULL));
fLogInitialized = TRUE;

This happened when I have installed Lingoes 2.9.1(http://www.lingoes.net/) and run it in the back.

When the bundle starts, it will load a dll from Lingoes.(C:\Users\Administrator\AppData\Local\Lingoes\Translator\lingoes-us\OpenText32.dll)

It looks like OpenText32.dll will call CoInitializeEx using a different thread mode before bundle's EngineRun().

When using the debug version of burn.exe, the generated bundle will crash because "ExitOnFailure(hr, "Failed to initialize COM.");" try to use the LogStringWork() before LogInitialize().

When using the release version of burn.exe, it won't crash.
but the CoInitializeEx is failed and I assume the COM is not initialized with COINIT_MULTITHREADED.
Will this affect the bundle's behavior?

I searched CoInitializeEx on msdn and it says,

Because there is no way to control the order in which in-process servers are loaded or unloaded, do not call CoInitialize, CoInitializeEx, or CoUninitialize from the DllMain function.

There is certainly something Lingoes is doing wrong, but maybe we should still make sure the bundle will behavior good under such environment .

Originally opened by uni

[wixbot]

AssignedTo set to robmen
Release changed from v3.9 to v3.10

[wixbot]

This is not quite about the crash thing. The release version won't crash.

The problem is whether "CoInitializeEx returns 0x80010106" is an ignorable situation or an error.

If it is an ignorable situation, then this issue could be just ignored too.

If it is an error, then maybe something could be done to mitigate the pain. It may be difficult to convince the user to uninstall those bad apps.

Originally posted by uni

[wixbot]

Fixed by pull request #270

Originally posted by robmen

[wixbot]

Should be fixed in next build.

Originally posted by robmen
Resolution set to fixed
Status changed from Open to Resolved