Noel Borthwick

I appreciate that troubleshooting these kinds of issues is very frustrating and laborious. Its an insane number of permutations of things that can cause such problems so unfortunately thats the only way. If you come up with a recipe that we can reproduce we can try and isolate it further and communicate with the developer in more technical terms.

Its not your system. The crash is from the plugin. Only the developer can solve it since it crashes in their code.

The dump file you sent is NOT from the 2022.11 release. In fact its a crash from a 2022.09 build. Are you sure that you are running the latest version, or did you send the wrong dump file? Clearly the same crash occurred in 09.

Re 1. Please try setting BounceFlushTailsMaxDurationSec to 0 in preferences configuration file and see if that prevents the crash. Re 2. Try turning on Send All Notes off on Stop under VST settings

Delete all is new and has a confirmation prompt.

Perhaps post in this section as well. https://discuss.cakewalk.com/index.php?/forum/45-track-project-templates/

You can reset the device and reload the driver's in Cakewalk, by control clicking the reset audio and midi button on the toolbar next to the transport.

Maybe you had a mix of 32 bit and 64 bit plugins with different ID's. It works fine here.

In theory yes. It was likely not implemented for that gesture.

2022.11 Update 1 has been released. Thanks for your help everyone.

Is it reproducible and new to this build? Capture a hang dump file and send a link.

@El Diablo 2022.11 EA build 21 has improvements for app startup on a network when there is no internet. There should be no delay when starting the application now. Shutdown should also be quicker.

Note that the EA has been updated to build 21 (see link in main post). There are several improvements and fixes including improvements for slow startup when there is no active internet connection. We plan to release this build tomorrow so if you can give it a quick look. New for Build 28.11.0.021 Delete All now available in effect bin menus Additional support for quick grouping in FX Chains Issues Resolved in Build 28.11.0.021: Crash when quick group bypassing FX Chains when other effects are in the bin Quick group support for track effect bin Delete command Don't require SHIFT for quick-group recursing FX Chains, if you're invoking from an effect already within ProChannel FX Chain Quick group delete (CTRL+SHIFT) FX Chains across multiple tracks fails to remove the plugin instance in the other track FX chains Quick group replace/delete (CTRL+SHIFT) effect from track effects bin should also affect ProChannel FX chain Improved project load performance Show Clip Stretch amount to 2 decimal places Incorrect plugin menu behavior Quick Group insert FX into ProChannel FX Rack inserts into track bin instead App startup can be slow when running on local network without internet ProChannel can be empty after inserting a new audio track

You said it's a WASAPI wrapper. If it is doing low latency AND sharing, then it's not using WASAPI shared they are using something other than WASAPI.

Well even if they are doing WASAPI they are likely using WASAPI Exclusive mode rather than WASAPI shared. WASAPI shared mode cannot go lower than 10 msec for any USB devices so there isn't anything they could do to enable that. It's at the OS level. We don't flag the FL studio driver. You can check the current list of flagged drivers in %appdata%\Cakewalk\Cakewalk Core\drivercompat.json

MMCSS is just a mechanism to let all realtime threads run at a very high priority so that other tasks on the PC don't interfere with audio processing as far as possible. Have you turned off MMCSS altogether in Cakewalk or just MMCSS for ASIO? If your system has enough bandwidth MMCSS won't help that much.

No, I don't think so. Just watch for anything unusual with load times. Not waiting for the load just meant that the UI could flicker during project load since it would show the UI before all operations had completed.

I've had the RME UFX for a long time and have had no issues with their ASIO drivers. The only thing is the device doesn't work well in WASAPI mode and in ASIO it doesn't support changing latency from the host side - you have to do it via the driver panel. Relatively minor issues.

Not in build 17 I just made those changes today.

Oh I didnt know they added an MMCSS disable in the driver panel, that is good. He had mentioned it, but it wasn't available at the time. It's not that surprising that you get worse performance if you turn off ASIO MMCSS in both CbB AND Lynx while leaving MMCSS enabled in Cakewalk, since that means the audio engine is running at a much high priority than the ASIO driver. The recommended settings are the following: Use MMCSS ON Enable MMCSS for ASIO ON MMCSS in ASIO driver panel OFF Use MMCSS ON Enable MMCSS for ASIO OFF MMCSS in ASIO driver panel ON NOT recommended: Use MMCSS ON Enable MMCSS for ASIO OFF MMCSS in ASIO driver panel OFF

@HOOK Lynx originally had a problem with MMCSS on a Lynx E44, where the driver would stop responding when Cakewalk enabled MMCSS. We had a case open with them and it was solved on their end back in Dec 2019, after I sent them a lot of info on this. Are you running the latest driver from them and if so, what problem do you see when MMCSS is enabled in Cakewalk for ASIO? In any case this is exactly why I added the ability to disable it from the host level and no longer default to MMCSS being enabled for ASIO drivers.

This is why we advise never installing or using these drivers. What they do is hook into Windows and utilize the audio device via low level WDM. Since at startup time Cakewalk loads all drivers to check for availability, when we hit this driver, it causes symtoms like you saw even if you never intended to use it. Sometimes it will even change the sample rate of your audio interface as a result of being loaded. The best solution is to remove these ASIO wrapper drivers from your system so Cakewalk never sees them. One thing I've been wanting to do is to change how Cakewalk starts up to avoid loading all ASIO drivers once one has been selected by the user. This might help alleviate problems like this. Its a pretty big change so will have to wait for when I have time to tackle that.

A few people had certain projects taking long to load with certain plugins, so we investigated it and found that some plugins can flood the message queue with data when loading. Since Cakewalk was waiting for all activity to finish at load time, this caused the delay. I've now also further improved load time on systems with no internet or poor internet speeds. The app should load immediately in such cases in the next build.

I looked at the dump file. The crash isn't in any Cakewalk code and its impossible to decipher from the stack. There are a lot of Sitala threads there but it's not clear if it was responsible. Very possible that some corruption caused the crash. The problem with errant plugins is it can be very hard to track down from the DAW level if crashes are random because they can corrupt memory. Details from your dump are below. Something (not Cakewalk) is basically trying to read from a bad memory address somewhere. Based on your description the most likely explanation one of the plugins possibly ran out of memory and had poor error handling leading to this crash. The bottom line is there is nothing any DAW can do to protect from cases like this. If you have consistent problems with particular plugins your best option is to work with the plugin vendor to fix it. ExceptionAddress: 00007ffb092812a8 (ntdll!RtlDispatchException+0x0000000000000048) ExceptionCode: c0000005 (Access violation) ExceptionFlags: 00000000 NumberParameters: 2 Parameter[0]: 0000000000000000 Parameter[1]: 00000000000000bc Attempt to read from address 00000000000000bc PROCESS_NAME: Cakewalk.exe READ_ADDRESS: 00000000000000bc ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s. EXCEPTION_CODE_STR: c0000005 EXCEPTION_PARAMETER1: 0000000000000000 EXCEPTION_PARAMETER2: 00000000000000bc FAULTING_THREAD: ffffffff STACK_TEXT: 00007ffb`092812a8 00007ffb`092812a8 ntdll!RtlDispatchException+0x48 STACK_COMMAND: ** Pseudo Context ** Pseudo ** Value: 3 ** ; kb SYMBOL_NAME: ntdll!RtlDispatchException+48 MODULE_NAME: ntdll IMAGE_NAME: ntdll.dll FAILURE_BUCKET_ID: BAD_DUMP_MISSING_MEMORY_NULL_CLASS_PTR_READ_c0000005_ntdll.dll!RtlDispatchException OS_VERSION: 10.0.19041.1 BUILDLAB_STR: vb_release OSPLATFORM_TYPE: x64 OSNAME: Windows 10 IMAGE_VERSION: 10.0.19041.2130

I wrote an article with guidelines for diagnosing plugin compatibility. Though to an end user it might not seem that way, the vast majority of problems are caused by plugin’s not being fully robust under a variety of operations. The most common problem areas are with following VST3 protocols, loading and saving state, thread safety, and proper separation of user interface operations from actual processing. Bugs in these areas can result in symptoms that vary from user interface problems, audio glitches, problems bouncing, crashes or hangs. We capture crash reports when possible and they sometimes lead to a resolution, but plugin issues are one of the most error prone areas in any DAW. You say you don’t see the same issues in your other DAW’s but that in itself doesnt mean anything beyond possibly the fact that the plugin vendor has not tested the same operations in Cakewalk. All DAW’s are vastly different in their internal architecture and a feature that works perfectly in one may or may not work in the other. We take plugin compatibility issues very seriously and if it indeed ends up being an issue in Cakewalk we fix it promptly. In fact even if it isn’t our issue we do what we can to work around it - much more than what some other DAW’s do.