https://bugs.winehq.org/show_bug.cgi?id=42695
--- Comment #44 from Paul Gofman gofmanp@gmail.com --- I downloaded the game and tried to track down what's happening there. While forcing CoInitializeSecurity() to return error unconditionally is occasionally pushing app to work (it skips CoUnitialize() in this case), this is no more than another hack as it does not fail in the application running on Windows. Before discovering that I tested some legit cases for CoInitializeSecurity() to fail (that is, if security was already initialized in any thread), but nothing like this is related here as Nikolay said.
On Windows CoCreateInstance() succeeds for WICImagingFactory, while COM is seemingly not initialized. I tested that injecting CoInitialize() calls before or after successful CoCreateInstance() returns S_OK (not S_FALSE) which suggests COM was not initialized before this call. The only documented way how this can happen which I knew or could find is a thread created from some thread which has MTA initialized. But this is not the case here (CoCreateInstance() under discussion happens in main thread, and no other thread initializes MTA apartment). Besides, this case is supported in Wine. I tried to track down what triggers CoCreateInstance() to succeed by injecting the calls to the code creating WICImagingFactory at different points, and found that the call starts to succeed after SetWindowPlacement() call for the application window created like this:
002a:Call user32.CreateWindowExW(00000000,1413ce2c8 L"POEWindowClass",1413cdde8 L"Path of Exile",00cf0000,80000000,80000000,00000328,00000273,00000000,00000000,140000000,00000000) ret=140c48753
I also found some mentioning of the mysterious CoCreateInstance() success after ShowWindow() on the internet: https://social.msdn.microsoft.com/Forums/vstudio/en-US/c1a642e2-184e-4f5a-98.... I checked library calls utilized from the window procedure of the application window and did not find anything relevant. Yet I did not test it thoroughly, so it leaves some room for mistake.
I did not yet reproduce that case on an standalone test, but I am not sure all this has any practical sense, as carefully reconstructing the conditions of this out-of-init CoCreateInstances and reproducing this behavior looks unlikely feasible at the moment. And I hope game developers will add an explicit CoInitializeEx() at some point.