SoulseekQt Windows - Crashes after many files in upload queue

[snowbie]

OS: Windows 11 24H2
Build: Qt 2025.03.20
CPU: Ryzen 9950X3D

96GB RAM

I notice that after substantial uploading, my client crashes. If there's heavy usage and people queuing a few thousand files, my client can crash after about 16hrs. With regular moderate uploading, my client will crash after 2-3 days. There's never any sluggish performance when using the program during heavy usage (aside from the initial freezing of a massive queue being made). I'll just happen to check my computer and see that Soulseek is no longer running.

I don't believe there's any kind of hardware limitation, and this issue has spanned across builds for the last few years

[Nir Arbel]

Have you monitored memory usage by the client over time? If it doesn't appear to be a problem of the client running out of memory, I can send you a build you can run in a debugger so we can see where it crashes in the code.

[snowbie]

I've not actively tracked Soulseek's RAM usage, but I've occasionally checked general usage, and I never exceed 70GB usage while averaging 25-40GB. I don't recall seeing anything unusual. After a couple hours since my last relaunch, it's currently using 1.3GB.

I'll try the debug build, thank you.

2026년 1월 17일 토요일 PM 10시 4분 52초 UTC-5에 Nir Arbel님이 작성:

[Nir Arbel]

Is it possible you're using the 32 bit build? Those are limited to around 4GB so if it hits that it would crash.

If you're sure this is happening with the 64 bit build there's a build here you can try and instructions on how to get it running inside a debugger:

https://groups.google.com/g/soulseek-discussion/c/d9VERaiHmJo/m/erW6c80sAwAJ

The only difference for you is that you don't need to use Ctrl+c but just wait for the client to crash and then type by in gdb to get a stack trace, then just copy paste it to here so I can take a look at it.

[Nir Arbel]

Sorry meant to say: type 'bt' in gdb (without the quotes)

[snowbie]

I checked, and I can confirm that I'm using the 64-bit version. I should have a stacktrace in the next few days.

2026년 1월 18일 일요일 AM 12시 40분 45초 UTC-5에 Nir Arbel님이 작성:

[Nir Arbel]

Thanks, once it crashes the debugger will also keep the program in memory so you can check memory consumption then as well.

[snowbie]

`[Thread 5592.0x2f44 exited with code 3]
[Thread 5592.0x5310 exited with code 3]
[Thread 5592.0x17c8 exited with code 3]
[Thread 5592.0x2c68 exited with code 3]
[Thread 5592.0x1e38 exited with code 3]
[Thread 5592.0x1f64 exited with code 3]
[Thread 5592.0x1040 exited with code 3]
[Thread 5592.0x2de4 exited with code 3]

Program terminated with signal SIGQUIT, Quit.
The program no longer exists.`
It didn't appear to stay in memory, but I last saw around 5.5GB of RAM usage. No stack trace when running 'bt'. Nothing in event viewer during the hours the program closed. 

During monitoring, there was persistent warning spam that read `warning: onecore\net\netprofiles\service\src\nsp\dll\namespaceserviceprovider.cpp(601)\nlansp_c.dll!00007FFB37BCD95C: (caller: 00007FFB3D39E207) LogHr(132711) tid(5e48) 8007277C No such service is known. The service cannot be found in the specified name space.`

I'm trying again, this time debugging in Visual Studio.

2026년 1월 18일 일요일 AM 1시 25분 25초 UTC-5에 Nir Arbel님이 작성:

[Nir Arbel]

In gdb, try:

 

catch signal SIGQUIT

catch signal SIGABRT

catch signal SIGSEGV

Before starting the program with run, it should pause when one of these signals is sent so you should hopefully be able to use bt.

[snowbie]

Didn't work, same result. I'll see if Visual Studio can find something.
I turned on auditing in Event Viewer prior to starting the last gdb monitoring. SearchProtocolHost.exe started at 12:05:03PM for search indexing then closed at 12:06:43PM. SoulseekQt.exe closes two seconds later with exit status 0x3. Maybe it was a coincidence, since SearchProtocolHost runs every few minutes.

2026년 1월 19일 월요일 PM 5시 4분 30초 UTC-5에 Nir Arbel님이 작성:

[snowbie]

Exception thrown at 0x00007FFB3BD080DA (KernelBase.dll) in SoulseekQt.exe: 0x20474343 (parameters: 0x000000004AC92260).
Exception thrown at 0x00007FFB3BD080DA (KernelBase.dll) in SoulseekQt.exe: 0x20474343 (parameters: 0x000000004AC92260).
The thread 38908 has exited with code 3 (0x3).
The thread 10528 has exited with code 3 (0x3).
The thread 30576 has exited with code 3 (0x3).
The thread 38832 has exited with code 3 (0x3).
The thread 38824 has exited with code 3 (0x3).
The thread 38820 has exited with code 3 (0x3).
The thread 19168 has exited with code 3 (0x3).
The thread 38812 has exited with code 3 (0x3).
The thread 38592 has exited with code 3 (0x3).
The thread 38888 has exited with code 3 (0x3).
The thread 37912 has exited with code 3 (0x3).
The thread 38676 has exited with code 3 (0x3).
The thread 38816 has exited with code 3 (0x3).
The program '[6768] SoulseekQt.exe' has exited with code 3 (0x3).

'sfc /scannow' found no issues. Soulseek's RAM usage never exceeded 6GB. No other program that I run crashes like this.

[Nir Arbel]

I'm not seeing anyone usable, but I forgot you can use Dr. MingW to get a crash report without running it in at debugger:

https://github.com/jrfonseca/drmingw

Let me know if you need help setting it up, or if you get a crash report.

[snowbie]

I think I got it setup correctly.. I installed it via drmingw -i and attached it to Soulseek process after launching 

2026년 1월 23일 금요일 PM 8시 51분 35초 UTC-5에 Nir Arbel님이 작성:

[Nir Arbel]

I don't think it needs to be attached in any way, if Dr. MingW is installed you can run SoulseekQt normally (outside a debugger) and it should generate a report when it crashes.

[snowbie]

Output from the live drmingw debugger: https://pastebin.com/dhRDBWqW
Seems like a memory allocation failure.
The drmingw output from the crash contained .pdb files for Windows .dlls, not Soulseek specific. (kernel32, kernelbase, msvcrt, mswcrt, mswsock, ntdll, user32, win32u, winhttp, winmm)

[Nir Arbel]

Oh! Turn off diagnostics from options.

[snowbie]

Diagnostics in Soulseek? I use the output from the transfer queue to track my upload stats via https://github.com/mrusse/Slsk-Upload-Stats-Tracker .

Is this causing a crash somehow? Is this something that could be fixed?

2026년 1월 26일 월요일 PM 4시 29분 8초 UTC-5에 Nir Arbel님이 작성:

[Nir Arbel]

I can try cropping old text in each diagnostic tab so it doesn't get too crowded, but I don't know if it will interfere with the plugin. Do you want to try that? I'll need a day or two to get a new build ready.

[snowbie]

The program doesn't run actively/depend on Soulseek. You have to manually paste the outputs from the transfer queue tab into the other program, which then parses the logs. There is no use for the other diagnostics.

Do you know how it's causing the crash? It's not a RAM limit issue. Maybe a limitation with Qt?

[Nir Arbel]

Yeah it's a Qt limitation, it can't handle that much text in the UI control.