Matti Suuronen wrote:
Running 0.10.12 with WinPCap 3.1 beta4 on an XP SP2, 2.4GHz/1.5GB RAM.
Everything worked ok for years, but a few weeks ago Ethereal became extremely
slow.
I have the impression that SP2 hasn't been around for years; did the
behavior change occur after an update, or did the update occur before
the behavior change?
Starting a capture (with "Display packets in real time") takes abt 20
secs, and all this time CPU is at 100%. Two processes, svchost.exe and services.
exe are eating all the CPU. After capture is running and no packets arrive, the
CPU usage drops to <5% and the Ethereal GUI is usable for checking the packets.
When a *single* packet is captured, the CPU goes back to 100% with "services"
and "svchost" eating cpu for a few seconds, and the GUI freezes. With this setup
I can analyze about 0.25 packets per second, which is not quite up to par with
my previous experience ;-)
Sysinternal's "filemon" shows that while the CPU is high, ethereal and svchost
do abt. 800 accesses/second to the file system, to places like C:\Documents and
Settings\All Users\Application Data\Microsoft\Network\Connections\Pbk\rasphone.
pbk (which is empty) and writes to c:\windows\debug\userenv.log the following
kinds of lines:
"USERENV(7d8.704) 17:00:01:287 ProcessAutoexec: Cannot process autoexec.bat.
USERENV(ef0.484) 17:00:01:319 ProcessAutoexec: Cannot process autoexec.bat.
"
I've seen similar kinds of wacky behavior reported by filemon when
running Ethereal in "Display packets in real time" mode; I don't
remember whether it was svchost.exe-related.
Is svchost.exe thrashing like that even when Ethereal *isn't* running?
If so, that *might* be virus-related - Googling for "svchost.exe" shows
some pages suggesting that it ight be virus-related.
If it's only thrashing when Ethereal is running, does it happen even
with non-"Update list of packets in real time" captures, or does it only
happen with "Update list of packets in real time"? If it only happens
with "Update list of packets in real time", does it happen if, for
example, you read in a large capture file? If it happens with
non-"Update list of packets in real time" captures, does it happen with
captures done by WinDump? Try running WinDump both without "-w" (so it
prints packet dissection) and with "-w" (so it saves packets to a file
without dissecting).