There’s something weird in my application(standalone app, not VST) under Windows.
I have a class which encapsulates an AudioDeviceManager. I’ve noticed that if I call
deviceManager.setMidiInputEnabled(...), Juce creates a thread for each midi input. Nothing wrong with that.
In my class destructor, there’s a call to deviceManager.closeAudioDevice();
If the program runs normally, there’s no problem at all. However, if for some reason, the app is terminated without the destructor being called, then the app process keeps running after the crash as a “ghost” process, and it can’t be killed using task manager, process explorer, command line taskkill or whatever…
For example :
- if there is a crash (not an exception, but a real crash, like writing to a wrong place in memory) of my app
- if stop it, int he middle, using the debugger, I have an exit code of 0, the debugger says the app exited normally…but I still have this “ghost” process.
- if I kill the app while running using a task manager
Basically the condition to make this happen is when the program doesn’t call “deviceManager.closeAudioDevice();”
In every case, the debugger shows that the thread(s) created for the MidiInput keep running indefinitely … (ProcessExplorer says they are blocked in wmaud.drv!midMessage+0xb6f6, in Wait:DelayExecution state)
Now if I remove the calls to setMidiInputEnabled, the program can be killed normally.
The “interesting” point is that it only happens with DirectSound. If I use ASIO, it can also be killed.
This is quite annoying for debugging, because the app can’t be recompiled (I have to rename the target .exe, or to restart the computer to kill the reluctant process)
Any idea about why it’s happening ?!