@Martin.Jirsak thanks for the reply, but I’m still confused if this is a Microsoft issue why Reaper,Studio one, Ableton, Bitwig have zero issues with Wdmaud ? and the fix is a Steinberg app not a microsoft one as it’s available from your downloads.
As a windows DAW user I’ve not come across this and have never had to change any DAW’s fundamental midi settings before inc Cubase as a user since the 1980’s .
Something need to be sorted with Cubase/windows so this doesn’t happen to anyone again. If Reaper,Studio one, Ableton, Bitwig do not have this issue on Windows then surely Steinberg has a duty to sort this out for us windows users.
It’s bad enough that your poster boy Dom Sigales and also Chris Silim have ditched windows , so things like this only make it worse for those of us who prefer to us Cubase on Windows machines, something that has always worked well if not better than Mac’s historically.
My posts here are not to have a go at anyone, I want to make Cubase/Windows as good as it can be, I also don’t want anyone to have to go through the last 8 months of grief I have trying to track this down.
I hope that Steinberg keep their commitment to the windows platform and not let it become the poor relation to the Mac version.
M
1 Like
Technically, the driver doesn’t crash. It ends up just waiting forever for the port. Semantics, I know. 
The root cause seems to be Cubase sending messages to a device on shut down. For USB that is reasonable unless you are super quick in unplugging a USB device at exactly the right time while shutting down Cubase.
But for software MIDI devices like VEP, where I assume the problem is coming from, that results in a call that just hangs. My complete guess here is it’s a race condition between VEP’s MIDI connection being closed and Cubase shutting down. But again, that’s just an educated guess as the traces don’t go that far down.
Unfortunately, the older WinMM API doesn’t have a great way of checking if a device has disconnected after it was opened because when created, all the devices were physical ones. That’s on us, and is one of the things fixed in WinRT MIDI and the new Windows MIDI Services.
A fix/workaround for Cubase could be to not send that sysex when shutting down a connection to a software device. No idea if that’s feasible, desirable, or will address it 100%.
Pete
Microsoft
Hi @Psychlist1972,
Thank you for your input.
Do you mean on Cubase shut down? Yes, Cubase does.
As far as I know, most of these crashes don’t happen while Cubase quit, the happen while using Cubase.
1 Like
the main issues:
Cubase would hang when opening the first time at the hub, it seems it was waiting for the midi/sysex checks and just froze. The problem was you could not kill the process from the task manager. It would eventaully close after about 10-15 minutes but a reboot was quicker.
If there was no freeze and a project opened Cubase was stable and worked well…until you closed a project to work on another one, and often it would then hang/freeze on the hub inbetween closing and trying to open a new project.
So… this led to me being told to use windows RT…
So I tried this, only switching to windows RT midi meant in my case none of my midi devices worked in cubase anymore. Sometimes with reboots I’d get one device working but it was a different device everytime. So after being told some hardware didn;t work with Midi RT I set about replacing hardware.
So I bought an AXR4…same problem ( and also discovered a bug whereby external FX crashed cubase) I swapped my Cc121 for an X touch one…same problem… I replaced both my midi keyboards …same problem…
At this point I reached out to pete and Vin and the mention of MMCSS came up…
As soon as I applied the steinberg patch all my midi devices worked with windows RT midi.
At no point did I ever get any error messages regarding MMCSS. The crash logs for the freezes just showed a general Wdmaud crash, it didn’t specify which device was causing it leading me to just replace things by trial and error.
M
Hi,
Do you use any MIDI Remote Device, please?
Thanks. Not sure why, but I thought this was happening on shut down.
The issue is still likely with trying to send SysEx to a disconnected device. Not sure if Cubase is sending messages under the covers when one closes a project and switches to the hub, but seems like it could be a similar thing.
Pete
I am using the remote for the x touch one, but I wasn’t until the last week, so it’s not that.
I was using all steinberg hardware… AXR4, CC121 and having the issue.
Lookng back I’ve a feeling this started with Cubase 12. Cubase 11 worked well apart from the known problem of hanging on closing projects, in fact i had a batch file to close C11 on my desktop
C12 just was a nightmare in that it kept freezing on opening, exactly like now, but I jumped to Reaper as it was so stable and did all my work on that.
C13 was released and I was desparate to get back to Cubase is it’s been my life for all my recording days since the 80’s
So that then led me down the path we’re at now with the freezes.
M
1 Like
Hi,
I cannot confirm this, because I haven’t tested it properly. But my feeling is the same.
Since Cubase 12, we have MIDI Remote, which sends SysEx messages (in some cases) to the devices to set them up. And I don’t remember these issues back then.
@Martin.Jirsak that’s interesting and could be a good place to start. Looking back now it’s when my troubles started and I’d gone all the way through the cubase/Nuendo cycles from V1.
M
1 Like
Hi,
Apologies for jumping on this thread, new forum member here, but fairly long term Cubase user.
As this thread exactly matched my issues i hope it is acceptable to add to it.
I have exactly the same dump file analysis pointing to wdmaud driver being the culprit with the midiout statement in there too, so i was glad to find i was not alone in some way.
I wanted to echo the OP that this issue only showed up recently, never having these Hub freezes before about 3 weeks ago.
The only thing i can think of that changed on my system was the recent Cubase 13 Pro update and perhaps a windows update that i mistakenly let through (i don’t usually upgrade windows unless absolutely necessary). My system is a purely music centric Audio specific setup.
So i guess my point being - why now??
I see there is a alternative driver (RT), but why if EVERYTHING else can use wdmaud with no issue can’t Cubase??
Its so frustrating, i don’t have time to mess around with the PC when I’m supposed to be being creative!
Other than using the RT driver is there no “Steinberg” fix for their software as it absolutely, without doubt, must be an issue their side?
I too worry that Steinberg is making us windows platform users second class, I’m reticent to dump over £2k worth of bespoke PC hardware to go the Mac route 
Nic
1 Like
Nic.
yes, it’s very frustrating as all other DAW software has worked flawlessly as you say.
I will say this: since this thread and my hardware and software changes/experiments I can say I"m now at a place whereby Cubase 13 is working as well as it did for me on V11 which was one of the best versions by far.
With that in mind here’s what I did to get to that point.
Install the MMCSS patch,set it to maximum threads. it does no harm so nothing to lose
Switch to windows RT midi , again, nothing to lose unless you have really old midi hardware that wont work with RT.
I’ll add that I’m using a Midex 8 which is very old and has an unoficial driver that still works with windows 11. I’ve hooked this up recdently to try and narrow down some midi device issues and it works great.
So my current set up that is working great now, had 2 solid weeks of work with zero issues.
AMD 7950x-64GB DDR5- NVMe drives-Windows 11 pro latest- RME UFX III-Ferrofish pulse MADI- Midex 8- -Nektar keyboard- 2x Euphonix Artist Mix -Behringer X touch One( using midi remote script)
As I said, this system has now run flawlessly for the past 2 weeks everyday, so I’m pretty certain I’ve sorted the WDM midi issue with Cubase by the 2 simple methods i described.
M
2 Likes
JFYI. There have been no Windows updates that impact the old MIDI API. That stack hasn’t been changed in a very long time.
Pete
@Psychlist1972 , I’m pretty sure this is somethng to do with the new Midi Remote that was added in Cubase 12. Before then I had never needed to look at any midi settings in cubase but when C12 appeared my troubles began. I was too busy at the time to trouble shoot this so skipped C12 all together.
I came back with c13 and again the issues were there, however I had more time to look at this and after a lot of trouble shooting have sorted it out with the MMCSS and windows RT settings.
There’s something about how cubase sends sysex messages (since the midi remote was added) that on windows can cause a freeze but not on Mac OS. So probably a cross platform /coding issue.
I hope they can sort it as I know MIDI 2 is about to be with us and Windows users will be able to make use of this.
M
3 Likes
The old winmm API is hard to code against in a reliable way if you’re doing anything beyond the basics. It just hasn’t aged well.
When Steinberg moves to the new MIDI API, which includes MIDI 2.0, these types of problems should go away. (And it’ll be faster, multi-client, more reliable, include loopback and virtual devices, etc.)
It’s on us (Microsoft) to finish it and put it in-box, though. We’re going through final privacy, security, and threat model reviews now, so nearing the end of development.
Pete
2 Likes
@Psychlist1972
Do companies like Steinberg have acces to the new API though long before it’s actually released?
If so do you envisage it being incorporated into Cubase fairly soon?
M
1 Like
Timing is up to Steinberg and where it fits in with their product priorities.
They’ve been a great partner, though, having made available an early prototype / proof-of-concept using the new API and SDK. I showed that at the last NAMM show.
Even if they don’t move to the new API, you’ll still get a small subset of the benefits, including multi-client, because we’ve repointed the older winmm API to the new service. I don’t yet know if it will solve this problem, however. (This can’t be served up from Github and needs to come in an Insider build before it can really be tested by other developers).
All music app developers have access to the developer preview releases on github.
Pete
4 Likes
@Psychlist1972 good to hear. I was begining to think Steinberg were going very Mac focused so it’s good to hear from someone at Microsoft saying they’ve been a good partner. Long may it continue.
I was nearly tempted to go over to Mac OS fully but since sorting this out and a whole new set of Intel CPU architecture on the horizon I’m more than happy to stay with Windows as my primary Studio DAW OS and keep mac os for my Mobile set up.
M
M
1 Like
The demo is shortly after 14:11 in this video, IIRC.
3 Likes
