Mulab crashes after standbye

[wibem]

After a few hours, when the computer (Mac) has been in stand-bye-modus (with running Mulab) and is reopened again, Mulab crashes. That means, Mulab is frozen, when you use the computer. You can't even save the project or quit the program.

[mutools]

If that happens on your Mac then best to save your project and quit MuLab before standbye.

[wibem]

I like to work on projects without closing the apps, when I set the computer to standbye. So it's much faster to start again. I assume that the standbye- issue with Mulab is the connection to the audio driver, which gets lost after a while. Mulab reacts with freezing, when the connection is lost. Other DAWs, which I use beside Mulab, don't have this problem. When the connection to the audio - driver is lost, you just have to reconnect in the running app.

[FabBad]

I have this daily issue but i'm using windows PC, the thing is, it crash to desktop.
But, i have my suspicious that has to do with the reported latency.
when i don't use it, it works like a charm.

[mutools]

I have this daily issue but i'm using windows PC, the thing is, it crash to desktop.
But, i have my suspicious that has to do with the reported latency.
when i don't use it, it works like a charm.

Please send the relevant MuLab log file as well as the relevant Windows crash report to

[Michael L]

Hey wibem,
I have never had the issue you describe, but macos compatibility and sleep-wake errors are pervasive (for more reasons than you can believe).
Try these:
1. update or reinstall your audio interface driver.
2. open your mac in safe mode (shift) and reset the smc (unplug) together, and see if the problem persists; then restart
3. open only MuLab, not Safari
4. check the MuLab audio setup to see if settings are correct.
Best of luck!
Michael

[FabBad]

I have this daily issue but i'm using windows PC, the thing is, it crash to desktop.
But, i have my suspicious that has to do with the reported latency.
when i don't use it, it works like a charm.

Please send the relevant MuLab log file as well as the relevant Windows crash report to

Sent

[mutools]

Thx but i don't see any crash data for the MUX Plugin code.
Is the issue repeatable with MUX Plugin inside Reaper?
If yes please send me a simple Reaper project using the latest version of MUX 8 Plugin together with the precise steps to repeat the crash. Thx.

[FabBad]

Well im pretty sure that is has to do with the latency compensation

MUX 64/32

From the last lines of log and windows event viewer

Code: Select all

...
0x00001EA4 15:30:08:137 M2VEW[252]
0x00001EA4 18:53:25:628 M2VEW[252]
0x00001EA4 18:53:25:659 App[945]
0x00001EA4 18:55:50:193 M2VEW[252]
0x00001EA4 18:55:50:222 App[945]
0x00001EA4 18:56:13:169 LeftClick  in window "" : 499,32 -> 0000027C7F416B80 = Mebc = [0,0,550,47]
0x00001EA4 18:56:13:477 Key  in window "" : [<] XY = 0,0 -> 0000027C014FA080 = MMPE = [0,0,550,307]
0x00001EA4 18:56:13:482 CF: 0000027C014FA080 = MMPE = [0,0,550,307] -> MMPE-s2de = Show Modular Area
0x00001EA4 18:56:50:464 LeftClick  in window "Setup I-O + adds 20210922_64bit Modular Area" : 468,229 -> 0000027C7F309588 = SBAR = vsbr = [463,148,12,460]
0x00001EA4 18:56:55:633 LeftClick  in window "Setup I-O + adds 20210922_64bit Modular Area" : 323,524 -> 0000027C7D9AADC8 = MPBt = prcs = [317,522,12,12] = GenericOnOffLed
0x00001EA4 18:56:56:081 LeftClick  in window "Setup I-O + adds 20210922_64bit Modular Area" : 322,528 -> 0000027C7D9AADC8 = MPBt = prcs = [317,522,12,12] = GenericOnOffLed
0x00001EA4 18:56:56:448 LeftClick  in window "Setup I-O + adds 20210922_64bit Modular Area" : 322,529 -> 0000027C7D9AADC8 = MPBt = prcs = [317,522,12,12] = GenericOnOffLed
0x00001EA4 18:56:56:695 LeftClick  in window "Setup I-O + adds 20210922_64bit Modular Area" : 322,529 -> 0000027C7D9AADC8 = MPBt = prcs = [317,522,12,12] = GenericOnOffLed
0x00001EA4 18:56:57:032 LeftClick  in window "Setup I-O + adds 20210922_64bit Modular Area" : 322,529 -> 0000027C7D9AADC8 = MPBt = prcs = [317,522,12,12] = GenericOnOffLed
0x00001EA4 18:56:57:256 LeftClick  in window "Setup I-O + adds 20210922_64bit Modular Area" : 322,529 -> 0000027C7D9AADC8 = MPBt = prcs = [317,522,12,12] = GenericOnOffLed
0x00001EA4 18:56:57:752 LeftClick  in window "Setup I-O + adds 20210922_64bit Modular Area" : 322,529 -> 0000027C7D9AADC8 = MPBt = prcs = [317,522,12,12] = GenericOnOffLed

Event Viewer

Faulting application name: Element 0.46.2 x64.exe, version: 0.46.2.0, time stamp: 0x60f5b13a
Faulting module name: ntdll.dll, version: 10.0.19041.1110, time stamp: 0xe7a22463
Exception code: 0xc0000374
Fault offset: 0x00000000000ff259
Faulting process id: 0x4114
Faulting application start time: 0x01d7b28ba0498951
Faulting application path: C:\Portables\Audio\Host\Element 0.46.2 x64.exe
Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
Report Id: d428c1aa-642e-4e84-bff1-e2a58a9f9350
Faulting package full name: 
Faulting package-relative application ID: 

Logged on 2021-09-29 18:56:58

The latest recent crash

Ok, the details was;
i woke up thepc at 12 pm aprox, i listen some staff no to loud
then, i leave the pc on with no sound but running Element (hosting a specific MUX patch for the output monitoring as usual), and i didn't use form somwhat 2 hours
when i came again i play some vidieos no loud, and then i start to play music at full volume... susednly, the sounds start to stuter (got ya). So, when i go to review the patch i notice that the latency generator module (intensionally added for this purposse), was ON, so i deactivate an reactivate again until it crashes to desktop, but this time it was able to log into event viewer but by the nature of these crashes it doesnt possible to write any specific error. but at least it shows what it logged just before the event.

tl:dr
caused by some sound level and the latency compensation in a long time after.

Regards.

[mutools]

None of both logs indicate a crash in mux code. Especially the windows crash log is the most important here as it specifically shows the crash point which is inside "ntdll.dll" which is a windows file, not MUX.dll. I don't see any connection between MUX' Latency Generator module and ntdll.dll.
Please try to isolate the issue by making a MUX patch that only contains a Latency Generator in the same way as you used it and see if it still repeats the issue. If yes then please redo the exact same case in Reaper and see if the same crash also happens there.

[magicmusic]

if you have plugins that use e-licenser, then test without them. I notice from windows that e-licenser make problems and hangs when use standby and resume and DAW is open

[sl23]

Personally, I have avoided standby mode since XP days. I recently had an issue on win10 caused by standby mode. Why it happens I do not know. But every now and then I try it, and it always causes malfunctions in the OS, usually right click errors are common, but it has also caused errors with apps loading or running correctly. This happens on any hardware or OS I've run even with mint Linux.

I know it's this as a restart fixes it. If you're in the middle of a project session, I would advise NOT to use standby. Either turn off your computer or lock it.

[magicmusic]

Personally, I have avoided standby mode since XP days. I recently had an issue on win10 caused by standby mode. Why it happens I do not know. But every now and then I try it, and it always causes malfunctions in the OS, usually right click errors are common, but it has also caused errors with apps loading or running correctly. This happens on any hardware or OS I've run even with mint Linux.

I know it's this as a restart fixes it. If you're in the middle of a project session, I would advise NOT to use standby. Either turn off your computer or lock it.

I notice no problems except with e licencer so i do not use it. I do always standby several times per day and i reboot near always only on windows patches or when a driver need it. so i reboot only after 10-14 days

I used logitech mouse then logitech trackball and now kensington expert trackball. all work ok. maybe your problems have something to do with USB standby. This i have on all hubs and ports disable. need not boot safe alot of time

[mutools]

Pure from MuLab's pov i don't see an issue with putting Windows standby while MuLab is launched, but there may be other components that are more sensitive to that case eg audio driver, dongle, maybe vst plugins, ... So it can differ from system to system. So as a general guideline i should recommend to quit MuLab before standby, but if you know it does not cause any issues on your specific setup, then you could leave it launched.

Note that it's not recommended to keep MuLab launched for more than a week without restarting MuLab. Try to restart MuLab each couple of days. (That's because of some remaining 32 bit counters, and i'm sure that these will evolve into 64 bit counters where relevant to cease this minor sensitivity)

In any case whatever your system, whatever your apps: Regularly save and regularly backup!