janko74 wrote: ↑Sat Oct 18, 2025 1:35 pm Last time, while I was writing the description for the auto-generated crash log, the crash log itself crashed — because MediaMonkey stopped responding and Windows declared it dead. So I couldn’t submit it or note the log ID.

And no, my machine doesn’t even know what sleep mode is. When it’s running, it has to stay awake till i fall asleep.

I’d definitely appreciate a new version that removes the “crash features.”

Hi in such cases you should fine *.el files alongside MM5.DB (https://www.mediamonkey.com/support/kno ... ini-files/) taht you can ZIP and send it to us in Support ticket (eg. manual sending of crash logs). They are deleted on successful sending of debug log.

Last time, while I was writing the description for the auto-generated crash log, the crash log itself crashed — because MediaMonkey stopped responding and Windows declared it dead. So I couldn’t submit it or note the log ID.

And no, my machine doesn’t even know what sleep mode is. When it’s running, it has to stay awake till i fall asleep.

I’d definitely appreciate a new version that removes the “crash features.”

Thanks for the reports!
btw, if possible, when you submit an auto-generated crashlog, please note the log ID in this thread--that way it's easier to associate the report to the thread.

Also, is there any correlation between the crashes and your machine going to sleep?

-Rusty

p.s. we expect to post a new 2024.2 build shortly

The MediaMonkey saga continues.

Yesterday I managed to run MediaMonkey for almost 12 hours without a crash — after I had halved my huge database by deleting outdated network files and giving it a maintenance. During that cleanup process, MM actually crashed twice while removing non-existent network entries, but afterwards it seemed stable.

However, today after just about an hour of playback, it crashed again. A crash report was automatically sent.

You can attach logs to the open ticket if you wish. Things may or may not be related.

I opened two support tickets, but the one regarding the “Renderer process crashed” was closed, and support focused on the “Thread Creation Error” instead.

I’m a bit unsure which logs I should attach. I have several DebugView logs from MM Debug that capture different errors, including the Renderer crash and the Thread Creation Error. And should i send it everytime directly from the error window which pops up when MM crashes? I send the two debugview logs with the Support Ticket Page.

Please attach a full log for each issue to a Support Ticket as requested above.

Apparently, MediaMonkey decided it wanted to keep me on my toes — multiple bugs, unexpected crashes, and virtual memory mysteries. So here’s my latest “adventure log” from the front lines of monkey chaos...

Update:

I think I was dealing with multiple separate issues. The first one — Application Error: “External exception E0000008” (player.js line 966) during an unexpected track change — hasn’t appeared again in this form.

Then there was the “Renderer process crashed!” error in DebugView, which causes crashes. I believe I’ve solved this by disconnecting old, unused DLNA devices from my network and manually removing them from Persistent.json. (There still seems to be no option in MediaMonkey to delete outdated DLNA devices.)

The third issue is a thread creation error, which may be caused by a memory leak. The exact cause is still unclear. I’ve increased the size of my Windows paging file — although this doesn’t solve the underlying leak. Currently, I’m monitoring the virtual memory usage closely to see what exactly is happening when the error occurs.

Maybe I'm on the trail of the culprit. While scanning the DebugView log, I noticed something:

[34960] UPnP: Renderer name: RX-V671, Renderer UUID: 9ab0c000-f668-11de-9976-00a0de88f04e [34960] MM5 [28168](R) TRemotePlayers._addStoredPlayers [34960] MM5 [28168](R) TRemotePlayers: stored player candidate: {"udn":"9ab0c000-f668-11de-9976-00a0de88f04e","name":"RX-V671","last_seen":"2025-10-13 10:15:52","volume":1,"ip":"http://192.168.178.74:49154/MediaRender ... col":"dlna"} [34960] MM5 [28168](R) TRemotePlayers: stored player candidate: {"udn":"F00DBABE-SA5E-BABA-DADA188ED5A60E84","name":"Philips TV","last_seen":"2025-10-11 20:17:54","volume":1,"ip":"http://192.168.178.24:49153/","isGroup" ... col":"dlna"} [34960] MM5 [28168](R) **********Performance warning: Class TSharedList<UpNp.IRemotePlayer> doesn't implement its own createInstance.

According to ChatGPT’s analysis, this UPnP activity could be related to the renderer crashes.
The old Yamaha RX-V671 and Philips TV are still visible to MediaMonkey through my FritzBox network, and MM5 tries to communicate with them as DLNA renderers.
Since the RX-V671 is known to send malformed or incomplete DLNA responses, it might cause the Chromium renderer to hang or crash when the device list is refreshed.

So I'll diconnect these devices and have a look, if the crashes dissapper.

Yes, I'm using Nvidia Geforce RTX 5070. I deactivated hardware acceleration in MM Options. Hardware accelaration GPU-planning, in Windows advanced graphic settings, is on. So maybe GPU Settings override MM settings? NVidia Overlay is active.

Realtek audio is there in device manager. I will deactivate it, and the Nvidia Audio devices too, cause i'm using Rodecaster Pro II as audio device.

Hi,
Interesting, Few questions and possible relations, do you have nVidia GPU and possibly enabled tempered with nVidia App features especially overlays and GPU hardware acceleration?

Also Do you have MB integrated RealTek Sound card? If yes what version of sound card driver you have, Personally one of most stable driver versions I have found is 9239.1

Today I have sent two DebugView reports (“Renderer process crashed” and “Thread Creation Error”) to Support Ticket.
Unfortunately, MediaMonkey is crashing more and more frequently.

I just experienced several crashes, and this time Windows displayed a “Thread Creation Error” message before MediaMonkey froze completely. I had to kill the process manually via Task Manager. The “Thread Creation Error” seems to be a secondary symptom that occurs when the Chromium-based UI renderer crashes.

It’s extremely annoying, and MediaMonkey is becoming nearly unusable for me at this point. My system was freshly built in July, so this shouldn’t be related to a corrupted or unstable setup.

Man, I really love the Monkey, but this situation is a mess.

If it still happens on 3168, please capture a full debug log (step 4b) and attach the log to a Support Ticket: https://www.mediamonkey.com/forum/viewtopic.php?t=86643

Update: Crash while playback was stopped (still under MM 2024.2.0.3167 Debug Version)

Even with playback stopped, MediaMonkey crashed again. The DebugView log captured the following sequence before the application terminated:

Renderer process crashed!
InstanceManager - window destroyed
Going to kill: MediaMonkeyEngine.exe
Kill leftovers finished, res = 3

According to an analysis by ChatGPT, this indicates that the Chromium-based renderer process (the UI engine of MediaMonkey) crashed unexpectedly, while the playback engine (MediaMonkeyEngine.exe) was later terminated as a result.

The log also shows repeated filesystem errors such as:

ERROR:filesystem_win.cc(128)] GetFileAttributes D:\Steam\dumps\attachments\...

These seem to originate from other Chromium-based apps (like Steam or Epic Games Launcher) and might point to a GPU or overlay conflict — for example with Steam Overlay, Epic Overlay or NVIDIA’s In-Game Overlay.

ChatGPT’s assessment is that this could be a GPU/renderer-level issue, not directly related to the audio engine or specific tracks. Possible contributing factors might include:

GPU hardware acceleration in MediaMonkey’s UI (Chromium renderer)

As a test, ChatGPT suggested temporarily disabling hardware acceleration in Tools → Options → General → Performance and uncheck “Use hardware acceleration when available” (requires restart).

I've updated to 2024.2.0.3168 Debug Version. When it's crashing again, i'll deactivate hardware acceleration and next the overlays.

Lowlander wrote: ↑Wed Oct 08, 2025 1:21 pm I'd suggest trying MediaMonkey 2024.2 beta to see if this is already resolved.

Good tip, I will try this next. Last time i tried to analyse similar crashes on my old system, the crashes disappeard after using debug version...

Lowlander wrote: ↑Wed Oct 08, 2025 1:21 pm Are you using Start Time on the file MediaMonkey crashes?

No, i'm not using Start Time on any files.