Thanks to another user mentioning problems he was having as being related to DHT, I tested it and found that indeed DHT was causing the exasperating handles leak that I have been twisting over.

The full comic story documented in these screenshots:

http://imgur.com/a/XQNUh

Due to other life activities, I haven't been able to focus on troubleshooting the handles leak that is triggered by Tixati's DHT function. The unclosed handles build up is in windows svchost.exe, not tixati itself.

This week another user mentioned they were experiencing this also. It is a very gradual process and excess handles might take days to accumulate before having a direct detrimental impact or crash, so many might also have this issue but not know it. I run system monitoring utilities (taskinfo and abpmon) that graphs core system functions so I can easily become aware of such anomalies.

I wanna thank you, even if I have nothing to do with the dev team, for such an search to fixes.

No it looks like I'm getting it too... Ubuntu 14.04. It only takes a little while, 1-2 hours before software starts locking up and it takes about five minutes to move the mouse cursor across the screen. v2.48 is the last one I can use.

Keep up the good work.

Thank you.

Thanks for this.  Good to know I'm not the only one having these issues.  For now I turn off DHT after a half hour and let it run off for many hours until it slows down.  Then I turn DHT back on briefly.

I tested this on my Win x64 machine.  The transfers are much faster with DHT off.  With DHT on everything slows to about half normal rate and many peers are not connecting.

This would explain the recent issues I've been having, after a while all other net traffic (Firefox, Steam etc...) just dies off but Tixati happily chugs along, In all cases a quick reboot of the system and all is well. Hopefully this will be resolved in the near future because as others have mentioned DHT is needed for so many trackerless torrents/magnets nowadays. In the meantime I shall try rolling back to an older client version to keep things running along.

Win 10 Pro x64 on Tixati 2.53 if that helps.

A temporary fix for Win x64
1) run tixati with DHT on for a while (10 minutes)
2) turn DHT off
3) disconnect VPN (1 minute)
4) reconnect VPN (keep DHT off)

This will allow tixati to run at full speed when it has enough peers already discovered.  It will of course slow down over time.  When it does repeat the process.

I am running an experiment with a different version of OpenVPN. It is possible Tixati is not causing the problem.

just noticed my outgoing BW was in the tank.

I enabled DHT and gradually my BW rose to my max limit of 8mb/s. I forgot to keep track but my system monitor alerted me to excessive handles. Within 30 minutes the number of handles had creeped up (soared?) to over 100,000 from 24,000 where it had flatlined for days. I can't share effectively without DHT but I can't run DHT for any length of time without this problem

The slowdown may have something to do with TCP connections.  On win x64 and the TCP connection attempts set at 8 there is a slowdown with DHT on.  If I set Outgoing and Incoming peer connection protocols to UDP only there is no slowdown.

Anybody know what version(s) of Tixati have the handle leak?

I prefer to downgrade until this issue is resolved :)

But what is the last known good version?

Thanks!

Interestingly enough, I haven't had any issues with it for quite some time, ran tixati with DHT off for a couple of weeks, then started turning it on manually, and eventually just changed to auto on. So far no issues, which is awkward.

not sure of any slowdown effects other than failure to connect with many peers but When I set both incoming and outgoing connections to UDP only the handles leak still occurs.

iF you are on Windows Creator Update, go to your OpenVPN Network Adapter. Choose properties of IPv4. There you will find an option Advanced. In Advanced set Automatic Metrics to a value of 15. Repeat this for all your other Network Adapters but for those change Automatic Metrics into a value of 25.

Autometric Metrics changed a lot in Windows Creator Update. All your outgoing requests like a connection setup or a DNS lookup or an incoming TCP/IP connection queries all Network Adapters even when you want only 1 active connected to The Internet Network Adapter.

The manual metric value 15 means it is cheaper and faster to use OpenVPN Network Adapter, the OpenVPN Network Adapter will always have to use the physical Network Adapter despite it is higher in manual metric costs with the value 25.

For Ubuntu I do not know.

This is well known to anyone visiting Virtual Private Network forums. All VPN software currently suffers from Windows Creator Update and most are waiting for a new OpenVPN Network Adapter driver that currently still is from in the middle of year 2016.

It's a Windows Feature, or Bug. I consider it a Bug. It requires knowledge to modify advanced IPv4 Protocol section Automatic Metrics by hand.

I'm more and more stumped by this.

A few daye ago I rebooted and restarted Tixati. I needed to enable DHT for a minute to join channels. But I forgot to turn it back off. Too my astonishment, my handles count remains at 23K.

Got some intermittent weird science going on here. Maybe it was fixed by a recent windows update? Will continue to monitor the situation but for now Transfer outgoing is maxed out and all is well.

Hi Bugmagnet, I think there is more than meets the eye. And it might be good news. I ran Tixati for 2 days. On Windows 10 and I will list the handles below.

Handles 611
Peak Handles 611
GDI Handles 601
User Handles 796

This is with 55 connections simultanious time 6 = 330 running UDP connections. (And at most 8 TCP times 6 = 48 TCP connections)


The problem might that your Antivirus has installed a virtual network driver protocol handler inside all your Network Adapters. Therefore every connection you do if you installed for example Avast, or AVG, or any antivirus with a Network Shield this causes overhead for every connection attempt, and even packet inspection is a normal thing for antivirus.

If you have installed a Webshield with your antivirus, and you still have this problem, uninstall your antivirus completely and install it again, but this time make sure to not install the Webshield.

The same applies to a third party software firewall. Your firewall causes overhead too. But you cannot just uninstall it and throw it away. What you can do is just hope third party software firewall does not have memory leaks.

Software Firewalls usually inject there code in every running process in the system. You see for example the Firewall injecting a .DLL with its executable code into TIXATI.EXE for example. However any leak in such a thing would make it look like TIXATI.EXE is at fault.

Even more modern Antivirus has Sandbox with Hardware Paravirtualization. This is also a common feature of 64 bit CPU's that can lead to excessive overload. For example with Hardware Virtualization enabled in Avast antivirus on a 64 bit CPU host with a 64 bit Guest with Virtual Box the Virtual Machine like a Virtual Windows 7 or Windows 10 will run unbelievable slow. Fortunately most antivirus at least AVG and Avast have an option to turn of Hardware Paravirtualization in Exceptions.

I hope for you that it is Hardware Paravirtualization that causes it. Then the solution is simple to go to your antivirus settings.

Usually this setting is at 'Problem Solving' or 'Exception'.

Please list your Antivirus like product, most Antivirus use a standard shared technology, like Avast and AVG both have this Hardware Paravirtualization problem.

(I disabled Paravirtualization in the Virus Scanner since otherwise I cannot run Virtual Machines at normal speed.) Since Hardware Virtualization is only for around a year a more standard thing in Antivirus products I think it still has bugs.

Conclusion: I cannot test your scenario since my scenario works just fine for days, no excessive GDI for example.

* In your network adapter look for a possible Protocol from an Antivirus provider
* Look if you have a Webshield or something like that
* Does your software firewall also exist as a Protocol inside your hardware Network adapter?
* Disable Hardware Paravirtualization in your antivirus product. (NOT IN BIOS!) Currently it is known both VMWare and Virtual Box have problems since Hardware Paravirtualization running over a sandbox created by antivirus that does Hardware Paravirtualization too, well you understand.

Verdict: Most likely your antivirus or a possible firewall updated itself, or maybe Microsoft, or you are just lucky.

Hi guest

Is it safe to assume that the handles count you listed are those related to Tixati.exe process?

When I experienced the handles leak, it was not reflected in the number of handles directly in use by Tixati.exe. see the link to images in my original post. The handle leak is linked to svchost.exe but caused by tixati DHT.

I am currently at 5 days, 9 hours uptime since reboot, now running DHT constantly and my total system handles count is just 23K. Being able to use DHT allows me to find enough peers to keep my upload BW maxed out. Without DHT running, much of my BW remained idle since it wasn't so easy for others to find the files I am serving up. Life is good.

In reply to the Guest post above I added Tixati.exe to the excluded processes in Avast's Webshield component, downloading a 10GB+ torrent and my other web traffic seems to be behaving. Will keep an eye and report if it still goes all wonky on me. :)

arghhhh!!!!!!!!!!!!!!!!!
life has taken another turn....

I restarted my system and the DHT leak returned.

Tracking this down I think will take more time than I have available for it right now.