I have been reading all of these posts about Limewire slowing down people's computers, to the point where it consumes 100% of their CPU resources. For a lot of you, I suspect that it may not be Limewire at all that is doing it. You may be infected with a virus, as I was. One quick way to tell if you are infected with this virus, is to try hitting CTRL-ALT-DEL once. If the Task Manager DOES NOT appear, then you are infected, and it's a virus that is slowing your computer down. I have posted these steps elsewhere in the forum, and I am going to repost them here. They take less than 20 minutes to complete, and once you're done them, you will be SOOOOO happy!

My problem originally was that Limewire was not only appearing to slow down my computer excessively, but I also had Limewire opening on Startup without me having specified that as an action in the Preferences. It took me literally 24 hours to run through the files and registry on my computer before I figured out this solution. Every single antivirus program I tried failed to detect this virus. What a great $80 spent! Useless!

Anyways, here are the steps:

1) Uninstall Limewire. You can reinstall it at the end of these steps.

2) Disable System Restore in Windows. This can be done by right
clicking on My Computer, selecting Properties, and then clicking on the System Restore tab. Then check the box Turn Off System Restore. Hit

Apply, and then OK. If you are prompted to restart Windows, do so.

3) Now we need to fool the virus into allowing us to open the Task Manager. This can be done by copying the Task Manager executable file from the Windows directory. To do this, go to c:\windows\system32, select the file taskmgr.exe, right click on it, and select Copy. Go to the desktop, and click on an empty part of the desktop. Then right click on the desktop, and select Paste.

4) Double click on the taskmgr.exe file on your desktop. This should open the Task Manager. Click on the Performance tab. If you are in fact infected with a virus, you will likely (although not necessarily) see close to 100% CPU usage!! Now click on the Processes tab, followed by clicking twice on the CPU column header. What this does is order the files running on your computer based on the amount of CPU resources they are consuming in real time. If there is a process, other than System Idle Process, that is consuming close to 100% of the CPU, then
it is this process (or file) that is infecting your computer. For me,
and likely for a lot of you, that file will be winupdates.exe. Don't
be tricked. This is not a Microsoft program. It's a virus masking
itself as a legitimate file. Please remember the exact name of this
process, because you will need it in a later step.

5) Click on this process to highlight it, then click the button End
Process. A warning prompt should pop up. Click on Yes.

6) Now that this process is killed, we need to remove any references to it from the Registry. Once again, because this virus is blocking us from opening the Registry Editor, we need to trick the virus by copying the file to the desktop. Follow the same steps as in number 3, except this time, copy the following two files from their respective directories, and paste them on the desktop.

c:\windows\regedit.exe
c:\windows\system32\cmd.exe

7) Open regedit from the desktop. In the left window, click on My
Computer so that it is highlighted. Now select Edit from the menu, followed by Find. In the Find box, type the name of the process that you ended from the Task Manager. If you recall, mine was winupdates. Do not include the .exe, just winupdates. Then click Find.

8) For the item that it found in the right window, click it to highlight it if it isn't highlighted already, and then right click on
it, and select Delete. If a prompt pops up, select Yes or OK to
confirm the delete.

9) Now, hit the F3 button once. This will find the next reference to
that bad file. Follow step 8 again to delete the reference. Repeat steps 9 and 8 until the editor indicates that there are no more references to this file. Then exit the editor.

10) Finally, click on cmd.exe which you copied to the desktop. It will open the Command Prompt (which looks like DOS). Type the following commands in order, and hit Enter after each line:

cd c:\
cd program files
rd /s /q winupdates

11) 1) Go to the following directory and delete any file with winupdates in the name.

c:\windows\prefetch

12) Now restart your computer. Reinstall Limewire.

13) Please make sure to go back into the System Properties by right clicking on My Computer, and unchecking the Turn Off System Restore box under the System Restore tab.


This should hopefully fix your problem.

For those of you who can't seem to find taskmgr.exe, cmd.exe, or
regedit.exe, I would suggest you do the following if you have not
already done so:

Open My Computer. Select Tools from the menu, followed by Folder Options. Click on the View tab. Make sure that there is a check mark next to the following items:

Display the Contents of System Folders
Show Hidden Files and Folder

Now, make sure there are no checkmarks beside the following:
Hide protected Operating System Files.

Also, if you are using the Search function in Windows to locate these files, make sure that you do it in the following way:

1) Click on the Start button in Windows, and then select Search.

2) Select All Files and Folder

3) Enter the file name in the first box.

4) Click on More Advanced Options.

5) Make sure that the following all have checkmarks next to them:
Search System Folders
Search Hidden Files and Folders
Search Subfolders

Then once these are checked, click on Search.

I hope this helps! :-)

Bobby Naini

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?

Hey guys,

I'm a computer programmer at the Uni. We're running a pretty top-shape comp here, with an Athlon 3600 and 1 gig of RAM. Everyone in my lab could write their own virus if they chose, so I'm definitely not infected. We're firewalled, but the firewall isn't the issue. Also, we're using the absolute latest builds of Java because some of us develop in Java. And yet, Limewire slows down the computer to the point where the whole thing is unusable if it isn't hidden in the tray.

I can run a Java app like Eclipse that takes twice as much memory as Limewire, and that runs at decent speed.

The weird thing is that I've had limewire working at normal speed, a week ago.

Any clues?

-Thomas

One of the things about Java is that the older APIs encouraged/forced the use of many threads. MS Windows, in particular, bogs down when there are tons of threads.

Java didn't even have non-blocking TCP sockets until Java 1.4. Now that most Macintosh users have a Java 1.4 JVM, LimeWire can start using the more efficient 1.4 APIs without leaving anyone stranded.

The new LimeWire beta version uses one thread to handle all of the TCP connections, rather than needing two threads for each and every TCP connection.

You might want to try the new LimeWire beta version. It's much more efficient with large numbers of connections.

There is no beta link on the main Limewire page, which says the current version is still 4.8.1. Where is the beta available?

http://www.limewire.com/english/content/beta.shtml

Hrm, the link just appeared today on the main limewire page. :P

This thing is supposed to be LESS resource intensive and perform BETTER?

With unchanged options and the same download list:

4.8.1 4.9.0
170meg 225meg!
High cpu use High cpu use
70-odd threads 40-odd threads

Fewer threads, at the expense of needing more RAM and no less CPU than earlier versions.

Also, 4.9.0 has a nasty habit of hanging for several seconds (sometimes a couple DOZEN seconds) after completing any download. It simply stops responding completely for this time -- whatever it is doing consumes 100% of a 1.5GHz CPU during this time and takes priority over UI event handling(!) -- if it's like that for 10 seconds that means it performed around 15 billion calculations to do whatever the heck it's doing. What the devil is an event-driven app doing performing 15 billion calculations in response to a network event? The previous version (same size library, same size downloads list, and only the search/download tab visible) didn't exhibit this behavior -- though it did if the library tab was visible, queerly enough.

It also seems to be quicker to give up on a file and say "Awaiting sources", although it seems to be quicker (when it isn't hung, that is) to do some other things also...

Just checked out the beta myself -- I notice the same performance problems, including the lengthy pause after each download completes, but turning off the new "automatically share downloaded files" and always manually deciding what to share seems to fix that one. There's a couple weird/funky bugs though.

1. The green check symbol most definitely doesn't work as intended. I saw one I was sure I didn't have and went to download it -- nothing. No file overwrite prompt, nor the new "the file matches content in your library" one. There's maybe one file like this per search, given a bogus green check. So grabbing everything in some group of files still means selecting them all, regardless of green check, hitting "download", and wading through the resulting overwrite prompts. Otherwise you risk missing something. Sigh.

2. Downloads sometimes get stuck at 100%. Once in a while a download finishes but doesn't go to "Complete" status (and then, if auto-clear is on, disappear) -- instead it stays saying "downloading", 100% progress, 0kb/s throughput. Hitting "pause" and then "resume" results in the file being stuck "queued" with 100% progress, rather than it doing whatever it's supposed to do and granting it "complete" status.

3. It seems to be much harder to get files from a "reluctant" host. You know the type -- you find some interesting files in a group that prove to be co-hosted; select them all; and three of them download and the rest say "Need more sources". Hit "find sources" on these, and three more download and the rest say "Awaiting sources". Previously (4.8.1 and earlier) you could select these and hit resume, and you'd get another three files, and so forth, eventually getting them all. In the 4.9.0 beta, this doesn't work -- the files will go to "queued" very briefly, and then back to "awaiting sources", or even fail to change status at all. Apparently if a host does the wrong thing and pretends to have gone offline in lieu of sending a civilised busy signal, 4.9.0 will forget it ever existed. Repeating the search that found the files will usually (but by no means always) cause the next three to download. It should be noted that some of the 4.x Limewires are among the hosts with the bad busy-signal behavior described above, where they act like they've gone offline rather than are merely busy when the max concurrent downloads per downloader is reached.

What about 2 or 300, or even 2 or 3000? With the default max of 5 active at a time?

In theory, it shouldn't matter how many are pending if the machine has plenty of RAM; CPU use should depend solely on the number active at a time. In practise...