I downgraded to µTorrent 2.2.1 and I had no trouble downloading very big torrents. I created high disk I/O with another program so that µTorrent had a lot of "disk overloaded 100%" whenever allocating one of the big files in the torrent, but µTorrent always recovered and continued downloading. This is the part where 3.3 just stalled making any downloading impossible. Until after exiting and then killing the process and deleting or not resuming the torrent that caused it after a restart. I may upgrade to the last good 3.x version, but honestly apart from the quicker and asynchronous program startup which is quite usefull when you have a lot of torrents shared, I don't see any real benefit of 3.2 over 2.2.1. Citation needed. Sparse files will only fail to be created if the user has a quota and that is not the case by default. My user account has no quota, enabling this option should work without running µTorrent as an Administrator. Besides while enabling sparse file creation may help with my problem, I actually can't be bothered dealing with 3.3 anymore, it has stolen me enough of my time already. I assume this was because you didn't follow the guideline to adjust it per your connection rate' date=' and test it with my "gold standard" torrent: [url']http://releases.ubuntu.com/13.04/ubuntu-13.04-desktop-i386.iso.torrent You recommended me your settings.dat and never mentioned any guideline. I have tried to adjust some settings after I noticed the 1/3 download speed, but curiously none helped, not even resetting all of the network and cache related ones back to the default. And yes, I did a restarts for the changes to take effect. Also I've tested two very popular torrents, one having over 6000 seeders (150 in my swarm) with both µTorrent 3.3 and your settings.dat and with Deluge 1.3.6. In contrast to µTorrent the later gave me the maximum download rate I was used to. It may be some hidden setting eventually? Apparently your settings.dat file has some non-default settings which are not accessible without special tools. Logon with a normal user account and try deleting something in the Users folder, try changing permissions in the root of the %systemdrive% Try making an application save a file in the root of the %systemdrive% you will soon find out that YOU are WRONG!!!! All of which has nothing to do with disk I/O. Apart from the fact that none of your examples matter for µTorrent, since it doesn't rely on write accessing those folders. Only during installation are higher privileges are required to copy itself into "Program Files" or "Program Files (x86)". Woohoo, correct but non sequitur. Since my problem is most likely cache related. Thank you very much for the link! Many of the settings are self explainatory based from their short names even, but this "manual" helps clear things up a bit more. Sure, I have looked at the Advanced settings of his myself. I found some of them to be quite odd, unnecessary and even harmful to performance, for example net.low_cpu and net.max_halfopen (unless you are running an outdated version of Windows and a very slow CPU), bt.no_connect_to_services (set to false... why would I want to connect to default internet services when µTorrent offers me the default option to not connect to them?!? actually that list of ports should be augmented with many more ports) or net.utp_dynamic_packet_size (so their auto adjustment code is broken, or why disable it?). Unfortunately the link you provided has no information about these settings... I can't even find much with Google. I have a hunch this may throttle net throughput with a big swarms. Anyway, those settings aren't my problem, it was a mere distraction from my real problem. If this problem even persists in the next stable release of µTorrent I might look into µTorrent's advanced cache and file system settings a bit and see if any of them have any influence. I'm aware that this is triggered by something on my system. My temporary and finished downloads are stored on a Truecrypt encrypted HDD. While straight throughput is acceptable, I doubt with many I/O requests this drive performing adequately, although my high I/O test didn't raise the CPU load caused by the truecrypt.sys threads to exceed 1%, maybe that it isn't very high, should be cause for concern? Although random seek performance of HDDs is so bad, that Truecrypt probably is able to cope. So here's the thing I do know: until the disk I/O code rewrite of 3.3, this was never a problem for µTorrent. Having said that I also remain sceptical whether Truecrypt is one factor, I doubt it for the observations stated above but I just don't know, it could be locking up disk writes in some rare cases, but I don't know, it's all assumptions without much substance to back them up, so it's not suitable for dismissing or proving anything. What I do have seen is that µTorrent wrote incoming blocks into memory but not flushing them to disk until it either ran out of memory and crashed. Or when the torrent was was small enough, it fully downloaded not crashing µTorrent, but only to freeze up, not getting flushed, with µTorrent hogging that extra physical memory indefinitely. Very nicely observable with Process Explorer, a linear increase in physical memory allocation by the µTorrent 3.3 process right up to the moment the download finished. The overall increase being the delta of the size of the completed torrent and the size of the parts that actually have been written to disk until the cache fuckup initiated, which usually occured around the ~400-500MB mark. So I assume it's µTorrent's fault, but I cannot say that for certain. Why could it be that µTorrent 3.3 is the only application on my system that is being denied cache flushing by a supposed bug in a system driver? Or could it be the disk cache code of µTorrent itself? Which happens to undergone a major rewrite with just the version I seem to have so much trouble with... See, that's the part where a professional computer science major who's able to actually debug (for real!) such an issue should have a look. I don't see that happening unless I self train myself some serious debugging skills. But why should I do that when BitTorrent Inc. isn't paying me for doing their work? So I'll resort to the remaing options I have left: use an older, working version of their software or not use their software at all but software instead that does work for me, like Deluge for example. Goodbye for now, problem solved by workaround: µTorrent < 3.3. Thanks, Beasly for providing information!