Can anyone help interpret this crash dmp file?

[SIXSGMA]

Hi everyone, I've been having persistant issues with this crash for years since (atleast V6).
Starting a family has meant I've been spending less time on music and this persistant issue has turned me off of music even more.

To the best of my knowledge, this crash happens when I am doing either of the following:

Deleting multiple audio tracks (like ~10+),
Dragging in audio files from browser (~10+),
Timestretching audio

It doesn't happen every time I do the actions, but I'd say atleast 20% of the time.

This leads me to suspect its something to do with caching. (I've also tried toggled the cache setting)

I've even done a clean install of Windows/studio One and problem still persists.

My system specs are Windows 11, Ryzen 3900x, 64GB RAM, RTX2060, OS is on NVME SSD, Project folder and samples are on SATA SSDs. Interface is Presonus Studio 192

I'm also considering transferring my project folder to an NVME drive if some how read/write speeds are to blame.

Hopefully this is not too against the forum rules, but I changed the file extension from .dmp to .txt to bypass the attachment restrictions.

Any help would be greatly appreciated.

 

[Lukas]

Hi, welcome to the forum!

While we try to help as much as we can here, PreSonus Support is definitely the best place for analyzing crash dumps.
I took a look at the file using WinDbg, but I'm not very familiar with this tool - unlike Tech Support and the Studio One QA team, who analyze crash dumps all day.

WinDbg suggested that an exception occurred in the JavaScript engine, and the last command listed in the file is Audio | Detect Tempo.
So it might be related to tempo detection - but no guarantee, as I really don't usually use this tool.

Are there audio files that reliably reproduce this crash?

Lukas

 

[SIXSGMA]

Thanks Lukas. I submitted a ticket.

It happens with stem files that have tempo information.

I just created a new song (on my NVME), added a dozen stems. Played with tempo, deleted half the stems, promptly added a bunch of other stems, and crash.
When the crash happens, the cache activity meter is >50%.

I checked Windbg and same error and last action as before.

It's almost like the crash happens because two functions are trying to access the cache at the same time.