MIXXX 2.4.1 crashes randomly on ucrtbase.dll

[audministrator]

Bug Description

After installing MIXXX version 2.4.1 on Windows 11 and Windows 10 (2 different PC's)? The application crashes randomly on ucrtbase.dll

Faulting application name: mixxx.exe, version: 2.4.1.0, time stamp: 0x663bec78 Faulting module name: ucrtbase.dll, version: 10.0.19041.3636, time stamp: 0x81cf5d89 Exception code: 0xc0000409 Fault offset: 0x000000000007286e Faulting process ID: 0x4520 Faulting application start time: 0x01db0d9b2b4c4311 Faulting application path: C:\Program Files\Mixxx\mixxx.exe Faulting module path: C:\WINDOWS\System32\ucrtbase.dll Report ID: 50d5d990-74ca-4172-8552-637ddf10acce Faulting package full name: Faulting package-relative application ID:

It seems to happen when loading a new song (double click to load).

Version

2.4.1.0

OS

Windows 10,Windows 11

[daschuer]

Please post your mixxx.log after a crash has happened: https://github.com/mixxxdj/mixxx/wiki/Finding-the-mixxx.log-file

As extra, you may try to produce a backtrace: https://github.com/mixxxdj/mixxx/wiki/Creating-Backtraces

Which track it affected?

[audministrator]

Hi Daniel,

I can only post the MIXXX logs for now. Since I use these PC's for live performances I can't do a backtrace because I already downgraded the software to version 2.3.3 and 2.3.6

Mixxx Logs before and after.zip

[ronso0]

Does it happen with any track?

[ronso0]

Does it also happen when drag the track(s) to the deck for loading?

[audministrator]

No not really... it happens after using it for a while randomly. If I remember well it happens when double click from the library to load a track.

What I notice is that the version 2.4.1.0 installation file is much smaller size, than the previous versions ? Not sure if that has something to do with it. Maybe there are some components missing...

[ronso0]

Okay. Unfortunately the log file only contains some info about loading the last track (if that was indeed Laid Back - Bakerman (80s Redrum)). But we can try to figure when the crash happens.

Do you remember what was happening in the UI when you double-clicked:

• is the current track ejected?
• is new track loaded? (eg. deck labels are updated, overview waveform is cleared)

Can you effort to test with 2.4.1 again? (or even 2.5-beta?)

[audministrator]

I can't remember the details to be honest. Whether is was a double click or a drag & drop to the deck. But it happened on 2 different PC's with the same version. So it is not related to a specific track.

One PC is running Windows 10 the other Windows 11...

What happened is that the complete MIXXX application was killed and the process shut down. So I had to start it again from scratch. Can't afford that have this happening in a live performance as you can imagine.

At the moment it is too busy so I can't affort to play around with these devices. I don't have a spare PC available to test it for the moment. I will definitely try to help out where possible but for the next couple of months this will be hard.

[ronso0]

Okay.

FYI you could also let 2.4.1 run with AutoDJ unattended for hours and see if it crashed with the internal track load operations.

Also note that it's always worth backing up your data (library, config, mappings etc.) when switching versions.

[audministrator]

If I find a spare PC I will do.

[daschuer]

Mixxx 2.4.1 64 MB Mixxx 2.3.6 75 MB Don't now why.

This is interesting

Debug [CachingReaderWorker 1] SoundSourceMp3 - Skipping MP3 Info Frame: "\FF\FF\FF\FF"
Debug [CachingReaderWorker 1] TrackMetadata - Modifying duration: 364695510204 ns -> 364669387755 ns
Debug [Main] BaseTrackCache(0x21919ef9490) updateIndexWithQuery took 0 ms
Warning [CachingReaderWorker 1] First sound has been moved! The beatgrid and other annotations are no longer valid "file:///F:/Music/TC Matic/Essential/03 They Never Make You Laugh.mp3"

And this

Debug [AnalyzerThread 0 #2] AnalyzerThread - Analyzing "F:/Music/New Wave/Laid Back - Bakerman (80s Redrum).mp3"
Warning [Main] Track duration has changed since last analysis 1920 != 1921

Did you actually change the tracks with a third party app? Maybe the crash happens because we failed to deal with changed tracks?

[audministrator]

I don't thouch the tracks with a third party app ?

But what I do is sometimes the track quality is not OK or the bitrate is too low. So I go to look for a better quality track and override the old MP3 with the new version. Better Quality MP3.

So the Mixxx DB might still hold the old Analyzed data ? And craches maybe on that part ? Nevertheless this is what I am doing since I started using Mixxx years ago, and never experienced issues in version 2.3.3 and 2.3.6

[daschuer]

Mixxx does not yet fully cover this use case, but at least it shall not crash. Not sure if this is related. To fix this issue we need more info. A receipt for reproduction would be Ideal.

[audministrator]

This cannot be the root cause ... Because than the older versions 2.3.3 and 2.3.6 would have crashed as well in the past years ?

[daschuer]

Not if we have introduced the issue in 2.4. But anyway, it can be a totally different issue. To find it, we need to have the issue reproducible, or a significant backtrace.

[audministrator]

I understand that this is heard to find the root cause, without more debug info. Problem for me is that I can't do trial and error on these 2 devices now. I can do this after New Year.

[audministrator]

Some more info that might give a clue ? If I have the GUI open no tracks loaded the CPU is OK

If I load 2 tracks (no playing) the CPU jumps to VERY HIGH. If I unload 1 track it lowers to HIGH If I unload all 2 tracks it is back to LOW

[daschuer]

This is normal with key lock enabled. The tracks are already "playing" paused. Which pit shift engine do you use in hardware preferences?

[audministrator]

There are the HW settings. On this Win10 PC there is no DJ controller attached. Is used as a backup device. But has the same sympthoms as the Win11 that has a DJ controller attached

[ronso0]

FYI Windows DirectSound is not the best API. You may try another one, see https://manual.mixxx.org/latest/en/chapters/preferences/sound_hardware.html#sound-api

[audministrator]

I have been running this HW selection in versio 2.3.3 / 2.3.6 and no problems at all ? I have downgrade back to 2.3.3 and everything is running stable again...

So must be something in the 2.4.1 version not realy related to the Windows OS HW settings I would say.

[JosepMaJAZ]

Just wanted to add that the meaning of the error code:

0xc0000409 means STATUS_STACK_BUFFER_OVERRUN

About the CPU usage, you can always reduce the non-audio CPU usage of Mixxx by reducing the framerate of the Waveforms.

[audministrator]

Thanks for the tip. But why should version 2.3.3 have a different CPU load if the framerate compared to the version 2.4.1 is the same.

If both settings are the default v 2.3.3

v 2.4.1