This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Excessive CPU load (cygrunsrv.exe, tail.exe, etc)

Andrew DeFaria wrote:

> In any event what version of Procexp do you use and suspect is causing
> this problem. I have 5.20 running at home and I forget which version is
> running at work but I know it's a newer version.
> When starting Procexp to check the version I noticed that he problem has
> occurred again. csrss is taking ~20% and cron ~12%. The 2 inetd's are
> taking ~10%. Working around this usually just involves a net stop of
> cron/inetd and restarting it. OK that worked. Restarting Procexp and
> wham! Same problem! Interesting.
> There is no modules view in 5.20 BTW. There is only View: DLLs and
> Handles. Either setting causes this problem in Cygwin.

"View DLLs" is what I meant by "module view."  Same thing.  The two ways
that I've found to trigger it is to have the "bottom pane" active and
set to DLL view and to click on a cygwin app, or double-click a cygwin
app and select the "Threads" tab.

In either case the thing that causes the problem is ProcExp attaching a
thread to the Cygwin process in order to get the loaded modules and
thread info.  I've tried to track this down but it's quite hard to debug
for several reasons: procexp does not come with source, it uses
undocumented API calls, and it works in concert with csrss (which is a
system service not a normal process and therefore harder to debug.)

The closest I've been able to get is the following set of calls as seen
in API Monitor:   Of course, I
can't find any way to export that list to a plain text format, so this
stupid screen shot is about the best I can do for now.  If you look at
the image it starts with a call to OpenProcess on pid 0xc9c which was my
sacrificial Cygwin process.  In this test I had only a single Cygwin
process running, and this process was a brain dead hello-world type
thing (a single call to read(0, buf, sizeof(buf)) so that it would just
sit there and patiently block.)  This test-app and those shown list of
calls are the simplest test-case that I was able to narrow it down to.


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]