Hi again, Updated to latest alpha: 25127 EDIT: Seems I spoke to soon.. The CPU usage seems to be directly correlated to the seeding of torrents. It's reproducible, when I stop all torrents, it is ok. When I start seeding them again, CPU usage climbs back up again. EDIT2: Downloading isn't fixed either. I have mirrored a number of different disk caching settings on this forum and all have resulted in the same issues. The first GB downloaded fine, approximately 4MB/s, then 100% disk overloaded issues for like 15 minutes on this 3.0GB file, then back up for 4MB/s again. The RAM cache I've dedicated to this is interesting enough, 1024mb. Did it not write a single thing to disk until it filled up the ram buffer? EDIT3: Haha. At exactly 2GB out of 3GB, it stopped and is at 100% disk overloaded again. I'm not sure what is happening.. Is it seriously not writing while it fills up the buffer? Forgot to mention that in resmon my disk is only writing at 2MB/s-5MB/s so it seems like something kind of major inefficiencies in the way that uTorrent is calling the file copy/chunking. Doing standard tests (http copy, ftp copy, explorer file copy, robocopy, xcopy, and linux dd inside of a vm) my disk is capable of read/writes averaging between 40-70MB/s quite easily. Taking a deeper look at resmon shows uTorrent writing 2kb-3kb/s in each of the directories of each of the torrents that I am seeding. I am seeding roughly 100 torrents so it's the 100x2-3kb/s that is contributing to the 2MB/s-5MB/s usage I see. What is uTorrent doing? Where is the bottleneck that is causing uTorrent to think that my disk is at 100% i/o capacity? Another piece of useful information: every single directory in the set of seeding torrents has been modified today. It seems like uTorrent is going in and either writing a file and deleting it or something? Noticed some change in the way it no longer seems to be constantly updating files. SearchIndexer has calmed down. I also noticed that since updating to 3.0, the start up time seems drastically increased from 2.2. I was wondering if you could give me a high level overview of what's different in the init sequence? It still doesn't seem to exit elegantly though, for whatever reason. I'm typically forced to kill the process tree to get it to stop. One of the possible side effects of not allowing uTorrent to exit elegantly is: a) deleted some of my files that were already complete corrupted the completion status of these files It became evident because I had some torrents that have been complete for months and I've just been seeding them, but now I'm forced to rehash them based on the .torrent files and re download pieces of them. EDIT: I've noticed some interesting behaviour. In the directory structure of all of the corrupt torrents, I see an existing original file named: xxx.file but now I see a seemingly duplicate file named xxx.file.1 of same size but no idea of the content. My concern revolves around, well, what is uTorrent doing playing with torrents that are already complete? What is it shuffling around, at the file level, and why? This type of behaviour would explain why previously my HD i/o was going nuts at an idle and why uTorrent was constantly using ~30% CPU. Let me know if you need more details. Thanks. Ended up downgrading to 2.2.1 with much success. All my tabs were out of wack, but that's to be assumed given the different tab configuration and numbering that was in my registry. 2.2.1 is working as expected, no CPU issues, no disk throttling issues, etc