[BUG] Crash on shutdown while calling OleUniitialize

[Psychlist1972]

Reported by Reuben Thomas (JUCE) on Discord

In JUCE, we call OleInitialize (nullptr) shortly after startup, and OleUninitialize() on shutdown after closing all COM resources.

For WinRT, I know we're supposed to call winrt::init_apartment() instead. I've read in a few places that it's actually fine (or even recommended) to skip calling winrt::uninit_apartment, but that advice seems to focus on applications rather than plugins. Given that we may be loaded and unloaded multiple times over the lifetime of a process, I'd prefer to clean up properly each time.

With the context out of the way, I'm seeing a crash on shutdown inside the final call to OleUninitialize() for JUCE apps that balance these COM setup/teardown calls. This happens after the message loop has exited and the message queue has been torn down. I'm omitting the stack trace for brevity, but it ends up crashing inside OleUninitialize while trying to call the destructor of IMidiSessionTracker, which seems to be owned by IMidiClientInitializer.

In the debugger, it appears that immediately after calling CoCreateInstance to make an IMidiClientInitializer, the returned object has a refcount of 2. This is also true at the point where we call Shutdown to close down our client instance. This means, even if we call release on our strong ref before reaching OleUninitialize, something else keeps the object alive with its own strong ref. This seems a bit weird - I wouldn't expect another object to hold a strong ref to an object we created, especially after we've called Shutdown to let the service know that we're about to go away.

This seems like a lifetime bug to me. I wonder, can anyone else can confirm?

[Psychlist1972]

The SDK does need a multi-threaded apartment, and we do recommend calling winrt::init_apartment(), but uninit_apartment should not be needed (although I'll investigate your specific scenario).

I'll look to see what might be holding on to the IMidiSessionTracker object in this case as this sounds like a bug in the SDK or the RPC code.

[reuk]

The SDK does need a multi-threaded apartment

I'm finding it a bit difficult to understand the implications of this. It seems like we want our main (UI) thread to be a STA, and we can't change the apartment mode without tearing down COM and setting it up again on the thread.

Are you saying that the thread that calls CoCreateInstance to create an IMidiClientInitializer needs to be in a MTA (i.e. we shouldn't call this from our UI thread), or that the process needs to have an (implicit) MTA before calling CoCreateInstance, or something else?

[Psychlist1972]

The SDK does need a multi-threaded apartment

I'm finding it a bit difficult to understand the implications of this. It seems like we want our main (UI) thread to be a STA, and we can't change the apartment mode without tearing down COM and setting it up again on the thread.

If your UI thread is not the one initializing and using MIDI, it should be fine.

Are you saying that the thread that calls CoCreateInstance to create an IMidiClientInitializer needs to be in a MTA (i.e. we shouldn't call this from our UI thread), or that the process needs to have an (implicit) MTA before calling CoCreateInstance, or something else?

Here's what I'm saying. I should maybe amend it to be "prefer" and not "require".

1. We try to limit use of coroutines in the SDK's interface, but there are some calls to internal WinRT components which must use them.

2. We only test with MTA. The coroutines used in some calls are largely supposed to work with STA, but I have not personally tested them. (C++/WinRT does things like this behind the scenes: https://devblogs.microsoft.com/oldnewthing/20230124-00/?p=107746 ).

3. Callbacks like the MidiMessageReceived event are typically going to come back on a different thread. If you initialize STA, there's additional marshaling/messaging overhead there. This should be tested in your app under STA if you want to go that route. I'd need to look into it, but C++/WinRT should be handling this for us, with the overhead built-in.

[Psychlist1972]

Related issue on COM Lifetime is #558

[ReinholdH]

The SDK does need a multi-threaded apartment

I am having another/similar problem when using multi-threaded apartment. In our apps we use a solution for using 32-bit dlls with x64 apps. Please see https://blog.mattmags.com/2007/06/30/accessing-32-bit-dlls-from-64-bit-code/ (btw. a very old blog but still a very smart solution. See comments to the blog.)

This solution requires CoInitializeEx which is completely running while the app is open.

We found out that we need to use COINIT_APARTMENTTHREADED because with COINIT_MULTITHREADED the virtual printer "Microsoft Print to PDF" hungs up.

For Windows MIDI Services I have to change it back to COINIT_MULTITHREADED but now the virtual printer "Microsoft Print to PDF" won't work any longer.

I am not sure where the problem is but a solution needs to be found that "Microsoft Print to PDF" works, too. Probably a change in virtual printer "Microsoft Print to PDF" is required to be able to work with COINIT_MULTITHREADED. May be this is a new issue.

[Psychlist1972]

The SDK does need a multi-threaded apartment

I am having another/similar problem when using multi-threaded apartment. In our apps we use a solution for using 32-bit dlls with x64 apps. Please see https://blog.mattmags.com/2007/06/30/accessing-32-bit-dlls-from-64-bit-code/ (btw. a very old blog but still a very smart solution. See comments to the blog.)

This solution requires CoInitializeEx which is completely running while the app is open.

We found out that we need to use COINIT_APARTMENTTHREADED because with COINIT_MULTITHREADED the virtual printer "Microsoft Print to PDF" hungs up.

For Windows MIDI Services I have to change it back to COINIT_MULTITHREADED but now the virtual printer "Microsoft Print to PDF" won't work any longer.

I am not sure where the problem is but a solution needs to be found that "Microsoft Print to PDF" works, too. Probably a change in virtual printer "Microsoft Print to PDF" is required to be able to work with COINIT_MULTITHREADED. May be this is a new issue.

have you tried initializing with an STA? Or are you going by my above responses?

winrt::initialize_apartment() (the recommended way to initialize both COM and WinRT when you use WinRT) will take a parameter for the apartment type.

C++/WinRT handles apartment thread marshaling behind the scenes. There's likely to be some performance impact, especially with the message received event. In your case, that is unlikely to be a problem. If you find any SDK calls which work under MTA and not under STA, let me know and I'll take a look. It hasn't been a priority to date so there's been no testing there.

Pete

[ReinholdH]

Pete, thanks.

I eliminated all STA, MTA usages in our software. Only one

winrt::init_apartment();

is used for Windows MIDI services. For printing we use the MFC CPrintDialog via a derived class. When printing to the virtual printer "Microsoft Print to PDF", I see

and it hangs at the progress window

The app needs to be killed manually. "Microsoft XPS Document Writer" hangs as well.

But with

winrt::init_apartment(winrt::apartment_type::single_threaded);

"Microsoft Print to PDF" and "Microsoft XPS Document Writer" run fine. The issue only happens for "Microsoft Print to PDF" and "Microsoft XPS Document Writer" when MTA is used. All other real printers or other virtual printers work fine.

PS: I use CppWinRT 2.0.240405.15 and MS.Windows:Devices.Midi2 1.0.2-preview-9.250121-1820

If you find any SDK calls which work under MTA and not under STA...

You probably meant "If you find any SDK calls which work under STA and not under MTA..."

Reinhold

[Psychlist1972]

@ReinholdH Thanks. All the Windows MIDI Services SDK testing to date has been under MTA. So I meant that because you are forced to use STA in your app due to the PDF and XPS writers, if you run across something in MIDI which fails under STA, but was working under MTA, please let me know.

Unfortunately, there's nothing I can do about the XPS or PDF writers.

[Psychlist1972]

@reuk

For your instance, please try with the new SDK that will be released with the upcoming Canary release. I've sorted out all the lifetime issues I was able to test for.