This is different from the usual case, where task manager works fine and shows Limewire to be the process hogging the CPU, rather than winupdates or some such thing.

Also, don't use symantec for antivirus. Norton anything is a piece of **** -- Norton used to be synonymous with quality, around the same time "this year" was synonymous with a number starting with the digits 198. :P

F-prot and AVG are frequently recommended and both have free-for-personal-use editions. Ad-aware and Spybot S&D also do, and should both be used to sweep one's system for additional categories of malware.

As for the Limewire bugginess, AFAICT it's just that Java scales extraordinarily poorly. All large Java apps seem to bring my Athlon 1800+ 1.53GHz with 1GB RAM to its knees from time to time. It seems there's two aspects to this. One is inefficient memory usage (what kind of object structure does sun's java use, anyway?) -- Java apps seem to slow down and get cranky way before an equivalent-functionality application written in C does on my machine, as if the machine has a fraction the memory it does, suggesting Java takes several times as much memory to do a given job as C or even C++. Possibly as much as 10 times(!). Even so, I rarely see Limewire's process size bloat up much above a measly 100 meg or so, and with lots of physical ram free Java apps seem to be quite capable of slowing down and flaking out as if they were running low on mem and having to swap. And this with no visible disk activity to indicate pagefile usage. I don't know what Sun's engineers were thinking, but they seem to have made Java emulate a late-90s computer's speed, capacity, and swapfile (to a ram disk?!) in their VM for some reason... The other aspect is CPU use. I don't know if it's Java itself, or poorly-designed Java apps, but big Java apps seem to have CPU usage when idle, and increasing in proportion to the amount of "stuff" open in the app, as though just about every live object is associated with its own thread and those threads do a lot of polling or busy-waiting. My personal prime suspect in this case is Swing, which is event-driven and involves threading heavily...in any case, the observed behavior seems to mean that more objects translates into not merely mem use, but also CPU use. Which is odd -- I've dabbled in Java a bit myself and made small apps, and other than Runnable objects passed to thread creation methods it didn't seem to me from the API docs or from experience that objects automatically translate into CPU activity even when they are just sitting somewhere and not being acted on at the time. Maybe LW does a lot of stuff with runnables and creating lots of runnable objects scales poorly?