[Production Verification] MetaServer starts with Windows MIDI Services

As the title says: My Metaserver isn’t launching after the 6.0.3 Update. I was on Version 5.1.8 before.

I get the splashscreen and it gets to “Starting MIDI services” but that’s it.

I’m on Windows 11 and I’m already using the new Windows based MIDI Loopback setup.

I went back to 5.1.8 since I still had an old install and everything works fine for now. Today though, I noticed MetagridPro on my iPad stating that the Metaserver Version is outdated but It’s still able to connect to 5.1.8.
But all of a sudden some of my cutom macros send additional midi messages which move the volume fader and the send fader of the selected track in cubase (sending a 127 midi value to be specific - maxing out the fader value). That certainly didn’t happen before today.

I suspect that I need to update my setup to the “new” Cubase MIDI Remote thing instead of the legacy Generic Remote. But for that I need Metaserver 6 to run first. At this point I’m softlocked and my system isn’t working properly.

I just now found a similar topic, sorry about the double up. I sent the respective crash reports via email.

Thanks for sending the crash reports. They identified the failure precisely.

MetaServer 6.0.3 crashes while checking the Windows MIDI Services loopback transport during startup. The failure occurs inside the native Windows MIDI Services call, which explains why it affects your system but does not reproduce on all test systems.

The unnecessary startup probe will be removed in MetaServer Windows 6.0.4. Until that update is available, you can continue using the previous MetaServer version if it keeps your setup operational.

The additional MIDI value 127 messages may be a separate routing or configuration issue. After MetaServer 6.0.4 is available, please check whether those messages still occur. If they do, they will be investigated separately.

Thanks again—the crash files provided the exact information needed to identify the failing startup path.

1 Like

For me restarting Windows fix it

Status update: this correction has been implemented and is currently included in the MetaServer Windows 6.0.4 Beta 1 and MetaGrid Pro 1.7.4 Hot Fix beta.

This post is primarily an informational update for everyone following this issue. If you are already a member of the beta program, you are welcome to verify the correction and report the result here. If you are not a beta tester, no action is required—the correction is planned for the upcoming production hotfix.

The beta downloads and TestFlight build are available only to authorized beta testers, so the linked beta resources may show “Access denied” for other forum members.

Beta testers can download the server beta from https://forum.metagrid.app/t/latest-metaserver-beta-builds. Please start MetaServer repeatedly with Windows MIDI Services enabled and confirm whether it opens normally without the previous crash. If it fails, attach the new MetaServer logs and Windows event record.

Any news on when 6.0.4 will be publicly available?

MetaGrid Pro 1.7.4 and the new MetaServer builds are scheduled for release this week. MetaGrid Pro 1.7.4 is currently being reviewed by Apple, and the corresponding MetaServer builds will be released alongside it.

1 Like

MetaServer Windows 6.0.4 is now publicly available and includes the corrections developed from this report.

The startup path no longer creates the transient Windows MIDI Services loopback probe that could cause the native access violation. MetaServer also performs bounded recovery when stale MetaServer-owned virtual endpoints exist or newly created APP endpoints are not immediately ready to open.

Please install MetaServer Windows 6.0.4, enable Windows MIDI Services and confirm whether MetaServer now starts normally without requiring a reboot or falling back to the older MetaServer version.

If it still closes while showing Starting MIDI services, please send a fresh MetaServer support package and the corresponding Windows crash event or dump from that exact 6.0.4 run.