[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Critical bug: explorer.exe CPU consumption

From: Matthew Ratzloff <matt_at_builtfromsource.com>
Date: 2007-01-25 23:24:34 CET


I've run some more extensive testing to figure out the problem. Here are
the results.

1. I disabled ALL non-Microsoft shell extensions. There were only three:
iTunes, Anapod Explorer, and VDMSound. Only the first two are in common
between this machine and my work machine (otherwise, my home machine and
work machines are fairly different).

I checked out a repository and watched the CPU usage. At first,
TortoiseProc.exe was running at about 50-70%, with occasional spikes from
TSVNCache.exe. About halfway through, explorer.exe (the main process,
controlling the Start Menu and desktop) began to climb until it was about
90%. The download also slowed down considerably. I killed the explorer.exe
process, the checkout sped up, and everything worked fine. When I opened
the folder with the checked-out files, it opened immediately. However, it
only did this because I killed the explorer.exe process.

2. Next, I also disabled my real-time virus scanner. I checked out the
repository. The results were identical. This time, however, I did not kill
the explorer.exe process prior to completion. It completed, and I clicked
on the folder to see the files. No files displayed, and explorer.exe
stability overall began to decline and usage increase. At this point, I
suspected TSVNCache.exe had some role, so I killed it. It didn't do
anything. I killed explorer.exe. The folder and files immediately
displayed fine. Not entirely convinced about TSVNCache.exe.

3. I opened a folder view window and ran "svn co" from the command line.
Briefly, TSVNCache.exe jumped to the top of the CPU usage and then
explorer.exe jumped to 80-90% usage. I killed them all and began again.

4. This time I closed all folder view windows and killed TSVNCache.exe prior
to doing anything (call it a pre-emptive strike). I ran "svn co" from the
command line. No explorer.exe CPU jump. I opened a folder view window
after the checkout completed. No explorer.exe CPU jump. I click in the
folder itself and everything is fine.

And the clincher:

5. I opened a folder view window and killed TSVNCache.exe. I then used
TortoiseSVN to check out a repository as I watched the processes and CPU
usage. The checkout completed normally, and explorer.exe never spiked. I
then clicked on the folder. TSVNCache.exe started up, but still
explorer.exe never spiked. The icons had no overlays. I refreshed the
folder contents and the overlays appeared. Even then, explorer.exe CPU
usage didn't spike.

So the problem is TSVNCache.exe. At a certain point during a checkout or
update, TSVNCache.exe briefly influences explorer.exe in some way that makes
it consume as many cycles as possible. If it's not running, no spike
occurs. I can reproduce this 100% of the time. I also want to stress that
explorer.exe simply does not do this at all unless I run an update or
checkout with TortoiseSVN. I can literally not use the interface for weeks,
and the one time I do it immediately causes a problem.

Finally, even though I'm the only reporting it, that doesn't really mean
anything. Some others might be experiencing this, but it's entirely
possible that I'm the only one who a) didn't immediately uninstall it the
first couple of times it occurred, and b) took the time to report it as a

Thanks for looking into this. I appreciate everyone's hard work.


----- Original Message -----
From: "Stefan Küng" <tortoisesvn@gmail.com>
To: <dev@tortoisesvn.tigris.org>
Cc: <matt@builtfromsource.com>
Sent: Thursday, January 25, 2007 11:54 AM
Subject: Re: Critical bug: explorer.exe CPU consumption

> I seriously doubt that this is TSVNs fault. The fact that it's the desktop
> process that's using all the CPU time is a hint that it must be some other
> shell extension. While TSVN also is loaded by the desktop process, it
> isn't called (or does nothing) during checkouts, updates...
> Also the fact that you're the only one reporting that the shell process
> uses all CPU tells me that it's not TSVNs fault.
> Please check all shell extensions you have installed. To get a list of
> those, you can use e.g. Autoruns
> http://www.microsoft.com/technet/sysinternals/utilities/Autoruns.mspx
> or ShellExView : http://www.nirsoft.net/utils/shexview.html
> Stefan
> Matthew Ratzloff wrote:
>> Ever since I started using TortoiseSVN about a year ago, I've had the
>> same issue. This issue occurs on both my home and work Windows XP
>> machines. I'm using the latest version, 1.4.1.
>> Whenever I update or check out a large repository (hundreds of files), I
>> have to kill the explorer.exe process. That's because CPU usage
>> immediately jumps to 99%--there's a direct correlation between the two
>> events. The problem is so severe that often the Task Manager refuses to
>> come up until I hit Ctrl+Alt+Delete multiple times. The files do not
>> show up in the folder view when I try to look at them; usually it makes
>> the problem worse (Windows becomes even less responsive). Small
>> repositories do not have this effect.
>> After I kill all explorer.exe processes and start it again (run
>> explorer.exe), the problem immediately goes away. I can look at the
>> files in folder view, they have icon overlays, etc.
>> In an effort to at least isolate the problem, I tried to use separate
>> explorer.exe processes (from folder view: Tools | Folder Options | View |
>> Launch folder windows in a separate process). When I do this, the main
>> desktop GUI is the one that jumps to 99%. Once I kill that process, the
>> other one, the folder view, is unaffected. I have to kill it, though, to
>> restart explorer.exe to get the Start Menu and and desktop icons back.

To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Fri Jan 26 07:27:13 2007

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.