Jump to content

µTorrent 1.3 freezes computer


Recommended Posts

I've been getting this problem since I upgraded to 1.3. I've never had that before. It seems that µTorrent is using all of the CPU power and/or memory since the CPU LED stays on when it happens.

Windows XP SP2, no firewalls or antivirus software.

I'm downgrading to 1.2.2 until there is a patch for 1.3

Link to comment
Share on other sites

Thanks guys for the reply.

There is no CPU LED on any system I know of so your likely referring to the HDD LED.

As P2P apps are often responsible for increased file fragmentation, may I ask when you last defraged your drive?

You are completely right; I was refering to the HDD LED, not CPU.

Regarding fragmentation, the disk in which I save my files is not fragmented, however my system disk is 14% fragmented. I do not remember when I had my last defrag :/

Do you have DMA enabled? Do you get a "Disk Overloaded" message in the status bar, ProCD? :| Maybe the automatic cache management isn't working too well for you. Try setting "diskio.write_queue_size" to 2x - 4x your maximum download speed. :)

I do not know what DMA is, I can't find that option, sorry. :( I am not sure if I get that message or not as my computer freezes and I can't use the mouse to maximize µTorrent.

Link to comment
Share on other sites

DMA speeds up your hard disk quite a bit, so it may be possible that your hard disk is still operating in PIO mode. Try this:

Right-click on My Computer ▶ Properties ▶ Hardware ▶ Device Manager. You should look for IDE ATA/ATAPI controllers ▶ double-click on Primary IDE channel ▶ Advanced Settings. Look at the transfer modes, it should read "DMA if available", if not, just select it from the drop-down menu. You might do the same for the Secondary IDE channel as well (if you have it). :)

Link to comment
Share on other sites

It seems like there is a big ? regarding this problem...

There's another thread here:


Same questions, no answers...

Oh, I didn't see a response to this, but increasing the diskio.write_queue_size to 8000 or 16000 doesn't correct the issue. That was my setting before the update (8000), and was the same after the udpate. Changing to 16000 doesn't help, either.

Link to comment
Share on other sites

  • 3 months later...


This topic is now archived and is closed to further replies.

  • Create New...