Crash or freeze on large queues during extreme heavy load of events

Please attach the crash log if there's any, from File menu / Open crash log. Thanks!

DC++ has crashed on 2025-09-14 at 11:40:33.
Please report this data to the DC++ team for further investigation.

DC++ version: DC++ v0.883 ("b'cd491d03bbba - 2025-09-12 13:18 +0200'")
TTH: WXNXQEKOEAM27Z3QVBQNIT6RPUYPICY3SZKS3KA
Compiled with MinGW-w64's GCC 11.2.0 (x64)
Exception code: c0000005
Windows version: major = 10, minor = 0, build = 22631, SP = 0, type = 1
Processors: 32 * x64
System memory installed: 255.95 GiB
Writing the stack trace...

DCPlusPlus: dcpp\ClientManager.cpp
DCPlusPlus: C:\DcDev\dcpphg\dcplusplus/dcpp/Speaker.h (46:9), function: void/unknown onLine(NmdcHub* const this, string const& aLine, string cmd, string param, size_type x)
DCPlusPlus: C:\DcDev\dcpphg\dcplusplus/dcpp/Speaker.h (45:3), function: void/unknown threadRead(BufferedSocket* const this, int left, size_type pos, string l, int bufpos, int total)
DCPlusPlus: C:\DcDev\dcpphg\dcplusplus/dcpp/BufferedSocket.cpp (486:3), function: int run(BufferedSocket* const this)
DCPlusPlus: C:\DcDev\dcpphg\dcplusplus/dcpp/Thread.h (108:3), function: DWORD starter(void/unknown p, Thread* t)
KERNEL32: [Failed to load the debugging data into memory (error: 2)] BaseThreadInitThunk
ntdll: [Failed to load the debugging data into memory (error: 2)] RtlUserThreadStart

Information about the crash has been written.

A possible duplicate of <https://bugs.launchpad.net/dcplusplus/+bug/1814386>.

Do you have any 3rd party virus scanner (Avast, Norton, McAfee,...) or the like installed?

Nope... just Windows Defender

@Mike If you up to doing some test for us to rule Defender out then please try to Exclude the DC++ executable or the complete DC++ progeram folder, as how described in <https://support.microsoft.com/en-gb/windows/virus-and-threat-protection-in-the-windows-security-app-1362f4cd-d71a-b52a-0b66-c2820032b65e>, under the Exlusions dropdown and see if it fixes things.

Otherwise thanks for your report and you can indeed stay on 0.882 long term as there's nothing critical in the new release. We'll see if we get more reports of this.

--

There is no change in the NMDC protocol line dissector in 0.883 vs 0.882 and also currently I see someone running 0.883 for several hours on the dev hub, reportedly logged on to instane amount of hubs (~90) and apparently without any issues. I also tested with many NMDC/S public hubs the way leading up to the release...

I have added it to the exclusions. Screenshot attached

I saw there was another user reporting slowness when connecting to encrypted servers, maybe its the same thing?

I will continue in 883 and see how it goes.

Thanks

Would you be able to join the DCDev public hub and PM me Mike?

I killed the process, and launched DC++ 35 min ago, I'm still at 37% loading download queue (my queue is around 4.8TB so it takes ages to startup).

Can you provide the DCDev public hub details?

Hub address is - adcs://hub.dcbase.org:16591/?kp=SHA256/ATFW63HSK5RSOSSOGJ7GIRNEDWNQY7YK2GPZ3PKLSFVFZZTVL2ZA

This 3rd time I opened v883 it started up with no issues...

We usually don't like to mix up different problems in one bug report - crash is one thing, freezes and long startup is pretty much another but they might be related in this case.

> my queue is around 4.8TB so it takes ages to startup

Yeah, and this is most probably the reason of all of your later freeze issues.
Not the total files size, rather the number of files in the queue. If it's more than 10-20k files overall then you'll certainly start to see DC++ lagging when you just go on to hubs with large user count and especially when you search for something and / or many downloads going on...
Fact is that DC++ is simply not designed to work well with such huge number of queued items.

I closed the other issue (2122804) as I believe these symptoms are related to a overly large queue.xml:
- super slow interface (closing a tab can take many minutes, etc)
- intermittent freezes (freezes up to a few minutes, while networking activity in task manager is high)
- freezes (that require killing the process)
- crashes

This all correlates to very large queue.xml. If file contains over 150,000 entries, DC++ will crash or freeze every couple of hours. If its around 120,000 it will crash or freeze every 6 to 8 hours. If its 80,000 it will crash/freeze daily.

Crashes and freezes are highly dependent on download speeds, so if download speed is high (10-20 MBps) it will crash much more often, which is in line with the file being too large (higher download speeds require more reading/writing the queue.xml file).

Thank you for the through tests Mike, much appreciated!

Useful info, especially the relation of the downloads. It must be an issue with locking the queue stuffed with many items - since among other events, user log on/offs, autosearch-automatches of large filelists and start/ends of downloading segments are doing just that.
Looks like constantly occuring heavy blow of these events can surface a flaw in form of either a deadlock or a crash, possibly when users that added as a source for queue items are logging off during processing events related to them.