Compiling with WinRT option causes access violation on exit (related to MidiInput))

Windows
1

Hi,
I had a annoying problem devoloping an app which I can reproduce on AudioPluginHost app . The case is: on exit the app cause a exception trying to realloc space to a memoryBlock called from the member function processSysex of MidiDataConcatenator class.
Couriosly if I discconect the midi input device in the Audio Settings the app go on exit without problem.
I don´t know if this problem is a bug of Juce or a problem in the very windows.
Some suggestiown or anyone experiencing this?
Thanks
image

2

Please can you provide a few more details about the exact steps you’re taking to trigger the issue? In particular, it would be useful to know which MIDI devices you are using for testing (can you send a screenshot of the audio/midi settings window when it is set up in the crashing configuration?). Do you have any plugins loaded in the AudioPluginHost? Which version of Windows are you using?

I just tested the following:

  • Enable the JUCE_USE_WINRT_MIDI=1 flag in the AudioPluginHost project and build it.
  • Run the host. I ran it on Windows 10 21H1.
  • Double-click on the midi input node to open the audio/midi settings and select a MIDI input and output. I tested with a single MIDI input and output device connected.
  • Play some notes to confirm that the device is connected and functioning correctly.
  • Click the “X” button in the host’s titlebar to close the app. The application closes without errors.

Is there anything in those steps that I’m doing differently to you?

3

Hi reuk,
Thanks for you response. The steps I followed are practically the same:

  • My Windows version si Windows 10 20H2.
  • This weird behaviour is reproduced when I have a plugin loaded, for example it happens with the internal plugin Syne Wave Synth but the same with commercials others pluggins.
  • if I disconnect the Midi Input the app exits without error.
  • These are my settins:
    image

image

4

I just had another go at reproducing this issue without any luck. Unfortunately I don’t have a machine running 20H2 so I can’t test whether the issue is dependent on the OS version.

I wonder whether the issue is caused by specific MIDI data. Could you try attaching an instance of the “MIDI Logger” internal plugin to the MIDI Input and check whether all the received messages look sensible? Apparently there used to be a bug in the WinRT MIDI implementation where it would misbehave when processing short SysEx messages, so it might be worth checking whether your MIDI device is sending SysEx messages.

5

Hi reuk, sorru for the delay. I’m very bussy these days.
What a pity you couldn’t reproduce the issue. Yesterday I update my Windows to 21H1 and USB drivers but the problem persists. Although the issue seems to follow some kind of dispatch SYSEX messages the keyboard I’m using is a simple master keyboard connected via midi > usb to my pc, so I discard that the issue being caused by MIDI messages because they are simply Note On/Off. I’ll try to connect some other controller.
Meanwhille I would like to comment another issue in the AudioPluginHost, although I dont know íf it would be better to create a new thread. You will say. The issue is the following. The app don’t remember the list of mididevices connected in previous session. I invistigated and discovered that when deviceManager is initialised the internal call to GetAvalaiblesDevices() returns an empty Array. If I prevously do a call a this procudere the problem dissapears.:

auto inputs = MidiInput::getAvailableDevices();
auto n = inputs.size();

auto safeThis = SafePointer<MainHostWindow> (this);
RuntimePermissions::request (RuntimePermissions::recordAudio,
                             [safeThis] (bool granted) mutable
                             {
                                 auto savedState = getAppProperties().getUserSettings()->getXmlValue ("audioDeviceState");
                                 safeThis->deviceManager.initialise (granted ? 256 : 0, 256, savedState.get(), true);
                             });
6

I’m not sure exactly what you mean, sorry. Are you seeing that sysex messages are being sent between your computer and your MIDI device? If so, I think there’s a good chance that these are related to the crash. Did you check with the MIDI Logger? Testing with another device is definitely a good idea.

I’ve made a note about the MIDI device list issue. I’ll take a look when I get a chance.

7

Sorry for my English :). I mean that the crash seems to follow a chain which goes thrue MidiDataConcatenator::pushMidiData and then processSysex. There we have a request for a new size of a MemorBlock on a bad pointer. It is as if it wanted process data on a device already closed. You can see it in the first screenshot I sent.
But my MIDIi keyboard controller didn’t send any kind of Sysex messages. I checked it.
Thanks a lot