Qbittorrent: Does not wanna end process and freezes at 0% CPU Usage and Memory stays locked

[jefrotone]

OK, So I've already assessed that the problem was my memory. Scratch that. Changed all the sticks in and out, nothing. Did memtest, nothing. Reset bios, nothing. Still hangs on close. Just sits there, memory locked and slowly goes down. Cannot end process or end process tree. Will not disappear until I reboot and try again. I can still run other programs just fine and watch movies and continue any work. If I close it and run some torrents, it will not pop up. Let me know what you need and I'll throw it up here.

12GIGS RAM
CPU i5 2700k
Windows 7 x64 SP1 with all updates (which I think is the culprit as I'm reinstalling windows ATM)
Install is on a SSD (not sure if that matters)
Changed disk cache to 16MB instead of (AUTO) - still hangs and freezes

[sledgehammer999]

This has been reported before. Not actually a clue what happens here. I suspect that libtorrent deadlocks somewhere.
What version of qbt do you use?

[jefrotone]

qbittorrent 3.1.5 ... I just re-installed windows and didn't update anything and it still does it, so updates are not breaking it... also , i disabled ipv6 and it somehow disappeared. I used these commands and it went away:

netsh interface ipv6 6to4 set state disabled default
netsh interface ipv6 isatap set state disabled
netsh interface ipv6 set teredo disabled

maybe ipv6 is causing it to freeze?
Also, I have ESET NOD32 firewall running v7, Allowed all outgoing connections and still does it.. disabled and still does it.

====== EDIT ====
now it actually shuts down... weird, I guess it was IPV6 that was messing with it... it now ends when I exit the program, and also got incoming connections with port 6881, even with no torrents. But that's irrelevant to the situation.

===== EDIT 2 ====

Solution is to disable IPV6 completely using these commands.

netsh interface ipv6 6to4 set state disabled default
netsh interface ipv6 isatap set state disabled
netsh interface ipv6 set teredo disabled

Let me know if this works for anyone else...

[sledgehammer999]

Cool. Thanks for debugging. I'll need to forward this to the libtorrent author.

[sledgehammer999]

http://code.google.com/p/libtorrent/issues/detail?id=573

[arvidn]

there was a bug in windows (I forget which version vista or 7) for a long time where certain IPv6 interactions would cause a system call to hang in the kernel indefinitely. This has since been fixed in a service pack, iirc. is anyone that's seeing this not running the latest service pack? and which windows versions are you using?

[sledgehammer999]

Windows 7 x64 SP1 with all updates (which I think is the culprit as I'm reinstalling windows ATM)

and after a while he says:

I just re-installed windows and didn't update anything and it still does it, so updates are not breaking it

[jefrotone]

So, after a few torrents, it still isnt working properly. It worked temporarily using the ipv6 fix. But now upgrading to v3.1.8 its broken again. Very sad, I really liked this app. Let me know what I could use to see what the program is doing in real-time. I'll upload the debug info here.

[sledgehammer999]

Maybe getting a backtrace fixes this. Try this:
Help me get a backtrace of what is actually happening.

1. Install ProcDump
2. In a command prompt:
   <path-to-proc-dump>\procdump.exe -x qbt.dmp <path-to-qbt>\qbittorrent.exe -h
   e.g .c:\procdump\procdump.exe -x qbt.dmp c:\program files\qbittorrent.exe

This may not create a minidump for you. Please play with the command line args mentioned in the procdump link. If you are not that advanced, tell me and I'll try to help you.

Send me the dump at sledgehammer999 at qbittorrent dot org

[alfrix]

dupe of #670

[KwikOne]

ok, I only started having this problem (difference = cpu and io usage looks normal for hours) after updating to 3.1.8 (portable) (Win 7 SP1 x64 all updates). One thing I tried was killing threads to see if it would shut down. Well, all threads could be killed except 1 thread (address = start_null_buffers_receive_op@win_iocp_socket_sservice_base@detail@asio@boost@@IAEXAAUbase_implementation_type@1234@HPAVreactor_op@234@@Z+0x133a79).
That thread (of several with that address) was the only one that would not kill.
I can take a mini-dump (or full if desired) and send it - but who should i send it to? (sledgehammer999 had indicated to someone else to send him a dump so should i send it there?)

[sledgehammer999]

Does disabling ipv6, as mentioned above, work?
You could send me the dump but I am not sure I'll be able to make windbg display it...

[v6bit]

@sledgehammer999
Disabling ipv6 doesn't work on my computer.
the qbt3.1.8 can't be killed and I have sent the dump to you

[jefrotone]

Still need me to send a crash dump to you? BTW, it completely stopped working now .It doesn't quit now and fails to quit . ipv6 fix doesn't work either.

[v6bit]

@jefrotone do you test the older version?

[jefrotone]

Going to update and report back in a bit

[arvidn]

sledgehammer, if you could provide a build with debug symbols, I believe TaskManager can take snapshots of stack traces, which is exactly what we want for a deadlock like this.

If it is a deadlock that is. It's also possible that libtorrent gets stuck waiting for all asynchronous operations. given that a thread was not killable, it may indicate a deeper deadlock-issue with the kernel however. A build with asio-debugging=on would help track that down (but that also requires a terminal for the output).

[v6bit]

@arvidn I can build the debug version libtorrent and qbittorrent on my computer, but I don't know how to analyze the deadlock issue

[jefrotone]

Tell us what we need to do and I'll do it

[v6bit]

Built libtorrent with vc2010 using
bjam -q --without-python --toolset=msvc variant=debug encryption=openssl link=static runtime-link=shared logging=none geoip=static dht-support=on boost=source asio-debugging=on

don't know how to provide terminal for output:(

[v6bit]

set breakpoint at void MainWindow::shutdownCleanUp() {
when execute delete m_instance; of QBtSession::drop(), the qbt freeze

continue and find in libtorrent

session_impl::~session_impl()
{
m_io_service.post(boost::bind(&session_impl::abort, this));

    // we need to wait for the disk-io thread to
    // die first, to make sure it won't post any
    // more messages to the io_service containing references
    // to disk_io_pool inside the disk_io_thread. Once
    // the main thread has handled all the outstanding requests
    // we know it's safe to destruct the disk thread.
    m_disk_thread.join();

---

when exectue m_disk_thread.join(); the qbt keeps waiting

[sledgehammer999]

For anyone only reading the emails github sends on this bug: The previous poster's comment may be partially hidden in the email(gmail hides part of it). It contains info on where the code blocks.

So arvidn, you may want to visit the actual bug report on github to see the full comment(if you already haven't done so).

[arvidn]

when waiting for the disk thread, what is the disk thread doing? i.e. switch thread to the one that's somewhere in disk_io_thread.cpp and possibly has disk_io_thread::thread_fun or something like that in its stack. the take a stack trace of where it is. in a previous post it looks like there may be a disk system call that hangs.

[jefrotone]

Wait a minute , I forgot to mention I was using a ssd. Does the disk system call have something to do with it ?

[v6bit]

I take a snapshot

PS. I use ssd too

[arvidn]

oh.. no, that just looks like a libtorrent bug. an annoying one. Is this reliably reproducible for you? you're on libtorrent 0.16.x I take it, right? This weekend I will instrument libtorrent to try to track down this issue.

[v6bit]

Yes, reproducible on my computer, just run qbt afte reboot computer and there it is.
if you install qq(a chinese IM software), you can control my computer to debug remotely.
my os is win8 and have SSD disk.
boost 1.55 libtorrent 0.16.14 qbittorrent3.1.8 vc2010 qt4.8.5

[arvidn]

Here's a patch that adds the ability for libtorrent to log disk jobs as they are posted, processed and returned. I think this would help track down this issue. sledgehammer, could you please make a build for v6bit? (or maybe you can build yourself). You need to define TORRENT_JOB_LOGGING when building.

http://dpaste.com/1624431/plain/

please post the log from a run where you get the hang. if possible, try to keep the run as short as possible.

[sledgehammer999]

v6bit, if you can't build it tell me to do it.

[v6bit]

After patch -p0

bjam -q --without-python --toolset=msvc variant=debug encryption=openssl link=static runtime-link=shared logging=none geoip=static dht-support=on boost=source asio-debugging=on define=TORRENT_JOB_LOGGING

when quit the qbittorrent, I got the disk_jobs.log

00:00:00.000 POST update_settings
00:00:00.000 POP update_settings
00:00:00.000 PERFORM update_settings
00:00:00.000 COMPLETE update_settings
00:00:10.431 POP abort_thread
00:00:10.431 PERFORM abort_thread
00:00:10.431 COMPLETE abort_thread
00:00:10.431 FLUSHING
00:00:10.431 RELEASING

00:00:10.431 THREAD-EXIT

the debug window continue output

==== Waiting to shut down: 215 ==== conn-queue: 0 connecting: 0 timeout (next: -227625.968750 max: 0.000000)

udp_socket::on_read: (1)
0: print_backtrace
1: libtorrent::add_outstanding_async
2: libtorrent::udp_socket::bind
3: libtorrent::aux::session_impl::open_listen_port
4: libtorrent::aux::session_impl::init
5: libtorrent::aux::session_impl::main_thread
6: boost::_mfi::mf0::operator()
7: boost::_bi::list1 >::operator(),boost::_bi::list0>
8: boost::_bi::bind_t,boost::_bi::list1 > >::operator()
9: boost::asio::detail::win_thread::funcboost::_bi::bind_t > > >::run

---

the whole output file is here http://pan.baidu.com/s/1bnd5PBT

[arvidn]

printing that stacktrace over and over again is caused by a bug in asio-debugging. it has been fixed in a later 0.16 release (0.16.14 iirc). Another thing worth trying is to build using libtorrent 1.0 (trunk, it isn't released as 1.0 yet), I believe the disk thread is a bit more robust there. I will take a look at the log file, the hosting site seems pretty slow for me though, hopefully I'll be able to download it.

[v6bit]

where can I find the libtorrent 1.0? I can build one again.
I send the log file to your email address arvid#rasterbar.com, please check it out

[arvidn]

it's trunk in the libtorrent svn repository. you can find it on sourceforge and google code.

[v6bit]

I browser the svn of sourceforge and only find the latest version is 0.16.15

[sledgehammer999]

svn trunk is the libtorrent 1.0.0

[v6bit]

Sorry, I haven't used svn before.
I run svn checkout svn://svn.code.sf.net/p/libtorrent/code/trunk libtorrent-code
then how to switch to 1.0.0?
Would you please give me the real command?

[sledgehammer999]

Just think trunk as another branch (the master branch).

With that command you used you already have checked out the correct code (check version.hpp to confirm)

Now apply the patch and build.

[v6bit]

Just svn checkout svn://svn.code.sf.net/p/libtorrent/code/trunk libtorrent-code and without patch, I compile and failed

bjam -q --without-python --toolset=msvc variant=debug encryption=openssl link=static runtime-link=shared logging=none geoip=static dht-support=on boost=source asio-debugging=on define=TORRENT_JOB_LOGGING

Error message is
D:/boost/tools/build/v2/buildfeature.jam:325: in validate-feature from module feature
error: unknown feature ""

[sledgehammer999]

try dht=on

[v6bit]

new error comes out :(

    D:\6xvod\libtorrent\include\libtorrent/kademlia/item.hpp(96) : see refer

ence to function template instantiation 'std::pair<_Ty1,_Ty2>::pair(_Ot
her1 &&,_Other2 &&)' being compiled
with
[
_Ty1=const char *,
_Ty2=int,
_Other1=int,
_Other2=int
]
d:Program Files (x86)Microsoft Visual Studio 10.0VCINCLUDEutility(163) : er
ror C2439: 'std::_Pair_base<_Ty1,_Ty2>::first' : member could not be initialized

    with
    [
        _Ty1=const char *,
        _Ty2=int
    ]
    d:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\utility(1

66) : see declaration of 'std::_Pair_base<_Ty1,_Ty2>::first'
with
[
_Ty1=const char *,
_Ty2=int
]

call "D:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"

x86 >nul
cl /Zm800 -nologo @"binmsvc-10.0debugasio-debugging-onboost-sourceencryptio
n-opensslgeoip-staticlink-staticthreading-multisrcsession.obj.rsp"

...failed compile-c-c++ binmsvc-10.0debugasio-debugging-onboost-sourceencry
ption-opensslgeoip-staticlink-staticthreading-multisrcsession.obj...
...failed updating 1 target...
...updated 52 targets...

[arvidn]

I believe I fixed that already. I must have checked it in right after you checked out trunk. try "svn up" in your checkout.

[v6bit]

Built qbt 3.2.0alpha with libtorrent 1.0.0 and can quit successfully!
It works well so far

[arvidn]

ah, right. This moved to being a flag instead. I'm guessing that this is
only used for displaying of peers purposes, and that you can probably
comment out any code that relies in this being set.

sledgehammer, sorry for changing this. I was expecting that nobody actually
was using this field. What happened was that since the utp connection
really is orthogonal to whether it's a bitorrent peer or something else,
this was moved to the flags field, as utp_socket

On Mon, Feb 17, 2014 at 8:04 PM, v6bit [email protected] wrote:

libtorrent 1.0.0 built successfully, but qbittorrent failed

D:6xvodqBittorrentsrcpropertiespeerlistwidget.cpp:449: 错误:C2039:
'bittorrent_utp' : is not a member of 'libtorrent::peer_info'

I used the master of qbittorrent git

—
Reply to this email directly or view it on GitHubhttps://github.com/qbittorrent/qBittorrent/issues/1332#issuecomment-35350709
.

Arvid Norberg

[arvidn]

that's great to hear. I'm a bit inclined to rather release 1.0 sooner than
digging too deep into this issue. it may be pretty deep. Please let us know
if what you think, if 1.0 works reliably.

On Mon, Feb 17, 2014 at 8:28 PM, v6bit [email protected] wrote:

Built qbt 3.2.0alpha with libtorrent 1.0.0 and can quit successfully!
It works well so far

—
Reply to this email directly or view it on GitHubhttps://github.com/qbittorrent/qBittorrent/issues/1332#issuecomment-35351638
.

Arvid Norberg

[v6bit]

Wow, 1.0 brings so many new things.

• improved support for web seeds that don't support keep-alive

Already support web seed redirecting for multi-files torrent?

[v6bit]

I find the problem is relevant with network environment.
I have tested several times on the same notebook in different network.
everythins is ok in this network

problem appears in this network

[arvidn]

actually, maybe it isn't the disk thread after all. that screenshot you had with libtorrent in the debugger. Could you do that again but look at the main thread? which thread is it waiting for?

If it's the main thread, running with asio-debugging=on may be helpful. Remember that there were some version before 0.16.14 iirc where asio debugging was broken on windows (with the symptom you posted earlier). Please try a later version. Does it point out any asynchronous operation that libtorrent is waiting for?

[v6bit]

I download libtorrent 0.16.15 and compile using
bjam -q --without-python --toolset=msvc variant=debug encryption=openssl link=static runtime-link=shared logging=none geoip=static dht-support=on boost=source asio-debugging=on define=TORRENT_JOB_LOGGING

There is no debuging information output about the asio like before :(

[jefrotone]

Whats the status on this ? I haven't been at my computer for a while, had to do some networking out of country. Let me know what I can do to help. I'm about to download the latest 3.19 that you have on the site and test it. Will report back here briefly.

[CourtArtanis]

Issue still exists, I'm experiencing this also, as of 18/9/14, latest version of qbittorrent.
Win7 x64

Also, this is not a Bitdefender ONLY related issue. I'm running avast :dancer:

[chrishirst]

Also, this is not a Bitdefender related issue. Nice attempt, but I'm running avast

Avast and BitDefender do the same kind of operation, they BOTH intercept incoming packets which slows them down and/or halts them completely.

[CourtArtanis]

I'm totally aware of that, thanks. I was just saying that it's not specific to a certain brand of software. The previous reference was Bitdefender specific.

[sledgehammer999]

I have encountered this myself a couple of times, both on Windows and on linux. However, in my case the zombification of the qbt process was accompanied by a general OS stability issues or network-hardware issues. It seemed that the zombification was result of that. However my machine was in such a state that I couldn't debug it(nothing worked right at that moment) leaving with the option of restart (or hard reset). Then problem never reoccurs.
So I have no idea what causes this.

[iyx]

I really liked qBittorrent for a while, but it started acting up for me.

After several (quite random) hours of use it won't recover from systray and what's even worse, its process cannot be killed completely, leaving "shadow" processes running, every time I restart/kill it.

I am using version 3.2.5 on Win7 x64, but this forces me to change client until this issues are resolved.

[djon2003]

I experienced it once a while. May I suggest to add a "closing window" that shows the user what QB is doing. So, like that, it removes the impression that the software is hanged and if it really does, than the users could tell what step he is in.

[nonamethanks]

This basically happens to me every single time I close qbittorrent.
I'm on Arch Linux.
It's extremely annoying because i have to spam "killall" after I get annoyed at the process hanging for literal hours and every single time I open it again I have to go to the .torrent folder and reopen all of them, and find that about 20-30 torrents were not saved and have to be readded and rehashed. lsof -i always shows "established" connections that never close.

[zeule]

Do not observe the situation when it's stuck in asio code on exit after updating to boost 1.63.0.

[naarcissus]

Wouldn't exit.
Closed handles in PE.
Still wouldn't exit.
Blocked it with my firewall.
Exited.

[jbruchon]

This continues to happen to me. When the program is asked to terminate, it ought to do so in a timely fashion. I can understand if it is saving fast resume data or purging disk caches but it isn't doing that. If I ask the program to terminate, I want it to terminate, not keep running and then require a forced termination to exit properly.

[GyoMan]

Same problem with qbittorent not exiting (Win7/64) but it also occurs with Deluge. I guess it is a libtorrent problem.

[jefrotone]

Its something in Windows 7 .. if that's what every is using.. its an
update. I'll have a look later, but it's definitely a windows update that's
causing this..

On Sun, Apr 16, 2017 at 4:37 AM, GeoMan [e-mail] wrote:

Same problem with qbittorent not exiting (Win7/64) but it also occurs with
Deluge. I guess it is a libtorrent problem.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/qbittorrent/qBittorrent/issues/1332#issuecomment-294342755,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC0mJuNOwmoXkF7-68gT690wazRrq7QFks5rweFkgaJpZM4Bcyci
.

[jbruchon]

@jefrotone I do not run Windows updates.

[nonamethanks]

@jefrotone I do not even run Windows.

[GyoMan]

I went back to uTorrent 3.3.2 which works fine under Win7/64 until the problem with QBittorrent is resolved. I had to restart my system every time the Qbittorrent process got stuck in the background - as i couldn't terminate it or start Qbittorent again...

[nazar-pc]

Thanks to other comments I've also disabled IPv6 support in qBittorrent and the issue is gone. Would be nice if someone can eventually fix in (I've just updated to v4).

[bhrgunatha]

Arch Linux: 64 bit
qbittorrent 4.0.3 (64 bit)

I had this problem before (forget which version number) but after updating version the problem disappeared.

I've just updated from 3.3.16 which was exiting correctly but now with 4.0.3 this issue of not terminating has returned.

I don't use ipv6.

This is also annoying because it slows down greatly OS shutdown due to the OS timeout period before forcefully killing unresponsive programs like this.

[ontl]

Same problem, Windows 10 x64.

[AlexVallat]

Quick check - people experiencing this, are you using Display Fusion? I was getting this issue where the qbittorrent process never ended and had to be forced "end process" from the task manager, then just by coincidence I noticed that it doesn't happen if Display Fusion isn't running...

Win7 x64

[nazar-pc]

I'm on Linux with this issue and I have no idea what Display Fusion is.

[jbruchon]

This issue has persisted for quite a long time and is probably never going to be fixed. I'm unsubscribing from it and I have to say that I'm sadly quite disappointed.

[thehumandistraction]

libtorrent was updated to 1.1.7 in Arch Linux earlier today and seems to fix the hanging issue for now. However, as others have already stated, this bug seems to continue to crop up every once in a while.

[allanlaal]

similar issue on Ubuntu Mate 16.04LTS with qBittorrent v4.1.alpha with ~6000 torrents - it hangs as a windowless process after shutting down, but will eventually (after minutes or tens of minutes) shut down completely and cleanly

[djon2003]

So as suggested previously: adding a shutdown screen to know where it is still running would be great.

[allanlaal]

I would prefer it not shutting down for that long, a screen would just be a nuisance

[FranciscoPombal]

@allanlaal
I believe qBittorrent takes some time to shutdown with a lot of torrents since it has to save fastresume data for all of them. @sledgehammer999 Correct me on this if I am wrong. I don't know if it is possible to optimize that process, I haven't looked into it.

[allanlaal]

@FranciscoPombal actually the long shutdown is annoying only when I need to restart qBittorrent, because it has stopped downloading anything or fails to find peers for new torrents

[cloudgreen]

I also have the problem that the qbittorrent.exe process freezes after quitting. I'm new to qBittorrent and this seems to be a rather long-lived bug (4+ years...) in the software.

I need to manually try to kill the process (but it doesn't terminate!) via Task Manager before I can turn off my computer.

I'm running qBittorrent v4.1.1 (x64) on Windows 7 (x64).

[cloudgreen]

There seems to be multiple causes of this error - but if you're on Windows and it started for you just recently, the buggy Windows update KB4338818 is most likely the cause.

Installing the Windows Update KB4338821 – "July 18, 2018 (Preview of Monthly Rollup)" fixed the problem for me (download link). I am running Windows 7 x64 and qBittorrent v4.1.1.

Maybe it's the following fix mentioned in the KB4338821 that does it:

"Addresses an issue that may cause some devices running network monitoring workloads to receive the 0xD1 Stop error because of a race condition after installing the July update."

This is more or less a duplicate of issue #5097.

[TheOne320]

I am running Windows 10 x64 with qBitorrent x64 4.1.2.0 and this is still happening to me. Just not always.

[WhatFreshHellIsThis]

Qbittorent v4.1.3 Windows 10 x64 even when explicitly closed remains running and has to be shut down via task manager. Usually started via clicking on a magnet link, have never seen it not do this except just now when I started it from the start menu to get the version and closed it and checked. Maybe something to do with file association opening in Windows? This I would consider a very serious bug and I can see it's ancient and was inexplicably closed some time ago which is just...bizarre... so what's going on here with this?

[WhatFreshHellIsThis]

Just installed latest version, still happening.

To be clear this is QBittorrent 4.1.6 on Windows 10 Pro x64 and I always use it by clicking on Magnet links in FireFox which auto-opens QBittorrent via association. I do not launch it directly and so I can't speak to the issue happening that way.

People also need to be aware that if you think it's closed it is often not closed at all but still running in the background and may actually be hidden from view in Task Manager:

If you go into task manager you may not see it at first but it's there still if you launched it via a click in FireFox for example, when you go into task Manager QBittorrent is hiding in the FireFox entry once expanded. I.E. you might not see QBitttorent but if you expand the browser entry that it was launched from it shows under that browser instead.

This seems very dangerous to have software running with open ports that you think is closed. If it can't be fixed it should display a warning dialog that is displayed on every startup saying that it may not close properly and remain running in the background even if you think it's closed.

The prior cases about this very same issue are all going back years now, has no one coding it been able to replicate this?

For me it's super common, it happens to get stuck about 9 times out of 10, I'm honestly surprised when I don't have to kill the task to shut it down, it's just become part of my routine now and I've upgraded several times both QBittorent and Windows 10 Pro and it's unchanged in this buggy behaviour.

I wonder if the non-replicators have missed it because it's often sitting under the browser entry that needs to be expanded in Task Manager to see it or they haven't tested by launching it from browser via Magnet URL association in Windows?

[Anutrix]

Could it be that the reason for this that it was started by some other process(Like browser via magnet links and explorer via .torrent files) and not as independent program?
In other words, since the origin(browser or explorer) that spawned it is not closed, qBittorrent process also refuses to close.

A way to test this is:
Note: Before starting each case, completely restart your PC(with fast boot and stuff off; qBittorrent on startup off too) so that there's no instance of qBittorrent running.
Case 1: Start qBittorrent from a console. Close the console. Start a few small torrents by pasting magnet links and try all kinds of ways to close it.
Case 2: Start qBittorrent from a browser(e.g, firefox) by opening a magnet link from a site. And try all kinds of ways to close it.
Case 3: Start qBittorrent from the file explorer by opening a .torrent file. And try all kinds of ways to close it.

This should give us some leads.

[slrslr]

Hi guys, here are various Windows system stats when qbt process is running for 2 hours despite clicking to quit qbt:

Qbt 4.2.5 on W10, i see the "Mem Usage (K) is variable roughly 200 000. Page Faults is at 30 million and increasing by 100 each second. VirtualMemory Size is at 10 million (10GB i guess - i have 16GB RAM and it appeared like no big swapping happen during runtime) and sometimes move up and down. During past 30 minutes decreased by 1 million.
IO delta is changing around vaue 24 000 in SystemExplorer and in ProcessExplorer around 3MB/s active reads. I/O writes displayed as none. CPU is near idle. BUT the Windows's Resource monitor shows that the qbt is using swap file C:pagefile.sys around 700kB/s reading with high HDD latency 1 second (when i sort by latency, then i see this is top process, second has only 80ms). System HDD looks fully utilized.
Network activity is shown as zero. But it has two local TCP connections in established state as seen on image below

[arvidn]

@slrslr which version of libtorrent are you using?

[slrslr]

@arvidn in qbt 4.2.5 Help/About i see 1.2.6.0

[xavier2k6]

@slrslr did you try the build that @FranciscoPombal posted in https://github.com/qbittorrent/qBittorrent/issues/12326#issuecomment-690373082

also, are you still using windows 10 version 1511/build 10586?

[slrslr]

@xavier2k6 that is why i was trying to shutdown qbt 4.2.5 release. So i killed the process now. Then i was not knowing which build file i shoul DL of the two, i DLed first one - qBittorrent-nightly-e16aafb_vcpkg-fdac1fc_qt5-lts-5.15.0_libtorrent-release-1.2.10_x64-static-release
It is 4.3.0alpha1 with libtorrent 1.2.10.0. I ran it for 4 hours, then suspend computer and then unsuspend next day, ran it two another hours, after i saw:
400 peers connected, like 150 active uploading torrents
230MB physical memory, 500MB virtual
Then clicked tray icon and selected to quit qbt. After closing i have checked the Windows 10 Resource monitor tool and filtered out qbittorrent.exe disk processes and it displayed reading from swap file and then hundreds fastresume files (located on slow - HDD, having 700 resumed torrents, but only like 4 downloading in slow speed during 6 hours runtime).
fastresume files was disappearing and in 8 minutes none remained and qbt process ended gracefully. Maybe qbt can be faster in keeping fastresume up to date to quit faster.

For me, this issue is solved on Windows (OP had Windows too).

[FranciscoPombal]

For me, this issue is solved on Windows (OP had Windows too).

Indeed - closing this. See also https://github.com/qbittorrent/qBittorrent/issues/5097#issuecomment-637595127

TL;DR: the original report is very old and whatever was causing these symptoms (and other related problems) is fixed in recent master + libtorrent >= 1.2.10 (this is not to say that the the process of saving .fastresumes to disk on close can't be further improved, though). Please open a new issue report if you experience similar issues in the future with recent versions - reports for very old versions are not relevant because the underlying cause will almost for sure be different.