Random freezes and hours of startup time.

[Th3MadHatter]

Please provide the following information

qBittorrent version and Operating System

qBittorrent 4.1.4 (issue since 4.1.x), Win 10 64bit

What is the problem

qBittorrent is extremely unresponsive, very similar to issues #9929 and #9845 but turning logging off or on changes nothing (and shows no weird behavior in the logs). I can deal with freezes but the closer I get to 1000 items in my list the worse it gets until it eventually freezes (I noticed a commit buildup from nearly 2GB after having to force close but this was with logging on, I can't confirm if the same thing happens with logging off). The biggest issue however is that AFTER it becomes so unresponsive I have to force close it the program takes hours (i'm not exaggerating, I clocked it at over 2 1/2 hours) to start up again, without weird log entries, it loads 10 resume states, then freezes, loads 50, freezes and so on. No errors show up, with logging turned off I see nearly no I/O, commit and physical use of below 100mb but a high CPU usage around 10-20% on an I7 gen 2 processor, which is fairly high. I see no notices of corrupted fastresumes or anything else. WebUI is also unresponsive. Only way to change settings is through the ini if it happens.

What is the expected behavior

Snappy startups, I can load utorrent with 9943 files in less then 30 seconds.

Steps to reproduce

None, no distinct pattern other then force closing and restarting with "a lot of files". The freezes during use just happen whenever you open it or at random when it's being used, it seems like going to tabs with less (10 or less) files in it makes it happen slightly less.

Extra info(if any)

Reboots sometimes fix the issue but it is usually just waiting... for hours..

Edit:

To give an idea how long it takes to load, I started this instance at 8:42:23 AM so it has been running for over an hour, using 8-10% CPU, 91MB Commit, 25MB Physical, the window shows (Not Responding) and the WebUI is unreachable.

[sandersaares]

It might be insightful to have an understanding of what the CPU usage during this "hang/load time" is about. Do you know how to capture a stack trace with symbols? If so, please post a few of the busy thread (at different points in time).

If you do not know how to do that, here are some step by step instructions.

1. Download and run Process Explorer.
2. Open qBittorrent properties in Process Explorer and make a note of the TID of the thread that is using CPU.
3. Create a few minidumps at different points in time when your process looks to be stalled behind CPU-bound work. Post these as attachments here (you may need to zip them).

From the dump files, we might be able to detect what qBittorrent is doing when it is keeping your CPU busy when it should not be.

Note that the dump files may expose parts of the qBittorrent memory (configuration, paths, data about torrents in progress etc). Do not post them if you have any sensitive data you may want to keep from strangers on the internet.

[Kygies27]

I have the same issue, full details in: https://github.com/qbittorrent/qBittorrent/issues/9929#issuecomment-450859028

Will post minidump asap

[Kygies27]

Took a surprisingly long time to freeze (I didn't want to encourage it as it was the first time to run properly in 4-5 days) but here we are:

qbittorrent dmp (1-2-19 8-46pm).zip

@sandersaares

[sandersaares]

@Kygies27 is it using CPU when frozen? If so, did you make a note of the TID of the thread that was using CPU? What was the number?

I took a look at this dump but it was inconclusive. Please post several dumps taken during the problem, and the TID of CPU-using thread (if any) so a comparison can be made.

[Kygies27]

Retested today. Unwanted behavior can be recreated by being connected to the internet while starting the program (Minidump #1). Disconnecting from internet instantly resolves the issue (Minidump #2). Reconnecting to the internet does not cause and immediate issue (Minidump #3). Program will from time to time freeze (not crash). If I catch it in the act I will post another minidump.

TIDs:

1 (~1% usage)

4232 (I think this was the predominant thread as it used more CPU on average than 6776) 6776

2 (~4% usage)

7060

3 (~7-10% usage)

6776

Minidumps Qbittorrent, (1-4-19 12-50pm).zip @sandersaares

P.s: Using a rather old laptop (Core 2 Duo, 4GB Ram) so CPU usage might not be the same on other pcs. Been using the program for a year without any other issue than the current one)

[sandersaares]

I am not seeing anything abnormal in the minidumps. Going by the relation to the internet connectivity, I would tentatively point the finger at Comodo Firewall. I suggest uninstalling any custom firewall software and trying again.

[Kygies27]

Did a new test with Comodo Firewall processes killed (not turned off). Same behavior on startup but different TIDs. Did 2 more tests and the TIDs change on 2nd test and then back to first test. So far today only freezes on startup and behaves well even completing many torrents and adding others.

TIDs 5844 7816

(different freeze that I couldn't dump) 3864 4380

Minidups Qbittorrent (1-4-19 8-15pm).zip

[sandersaares]

I recommend uninstalling the firewall. Firewalls tend to eat themselves deeper into the system that just the processes you can see. The process is generally just a GUI to control the firewall drivers that actually do the firewalling.

[Th3MadHatter]

I completely forgot about this so I didn't make a dump but it's similar to the other user most likely, I still have the same issue and yes Comodo user as well.

@sandersaares don't, just don't tell people to uninstall their firewall to make things easier. Yes I completely agree with you a completely fresh windows install this more then likely works perfectly fine without any issues but are you going to build in recognizers for crypts and similar things? I don't even use my Comodo as a normal firewall but as a default deny shield, qbt is completely ignored by it as a default (as per settings even in the behavior shielding). Firewalls (and any form of antivirus) eats itself into the system as far as you let them but by default it's as a final system process to protect their users with basic settings. These settings are often incorrect and far too aggressive but that's why a lot of user use "hardened" modes as well, they have no idea, so better safe then sorry. Do keep in mind that, even those that figured out how github works, can still be complete newbies, don't have a pfSense box and have NO IDEA how to monitor faulty behavior even if you logged it for them and let them read it.

I personally run malware/virus tests for a living in VM's on a daily base so I know how important it is to have one set up (even in idiot mode).

That being said, they could share Dynamic Link Libraries or notice certain behavior that isn't natural (like how my browser freaks out when I try to go to the qbt download area or wiki because they're HTTPS but the certificate is declined by a hardened browser) so, not to attack you (I really do love your product) but in general, don't remove security software to make something work, make security software run smoothly by making your software trusted by said security suits.

If there happens to be an issue with Comodo and this is an issue that is only mentioned by Comodo users I know for a fact that the Comodo staff would be happy to add the entire structure of the software to their ignore list because like I said, the files itself can be completely harmless, passed virus total, GPG, etc. but if the behavior seems malicious (even if it isn't) it will keep throwing it in the check queue.

*rant over^ lol

To get back to my point however, the problem I have and had, the issue seems to be qBt's handling of DNS queries, if you just start your system there is not much in it so it can spam as much as it wants but after restarting while it has been running for a few days it's entirely different. I tried to mimic the behavior using a build up VPN from one box to the other (in my home) and it just flooded the system, this wasn't an issue at first boot but afterwards it just locked up. Changing Eth to Tun/Tap device while running smoothly caused a major lock up every single time. It also doesn't query Eth or Tun/tap device for new connections other then to show basic statistics in the interface (e.g. "Eth 3 allowed all sub connections" connected to 10.1.1.1 pass, connection breaks, connects to 10.1.1.2 fail, no connection while the status in settings is shown that Eth 3 has one sub 10.1.1.2). I tested this at least 20 times in win 7,8 and 10 VM's, all results are the same, complete lockups.

It might help in dev of the routing table, or I hope it does at least :)

[slrslr]

@sandersaares @sledgehammer999 it takes hours for the qbt to start responding after start and sometimes it does not and i resign and kill the process and wait for another qbt version. This problem happens to me across several recent 4.2.x versions. qbt 3.3.16 works though. Currently i am on 4.2.3 (latest) and Windows 10. Here and here i created minidumps per your instructions. (pass-w0rd is qbt) Thread ID (TID) where CPU is heavily utilized is: 42244 (this thread shows "Cycles Delta" to be around 5 billion). Thank you very much in advance. I hope this issue can be identified.

[ghost]

There's been many improvements made to startup in upcoming 4.5.0 release and also to GUI stutters. Closing this as this was reported on a very old version. If you can still reproduce it with latest version please comment to re-open the thread or create a new thread.