Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <40AB2792.A4AB6650@dessent.net> Date: Wed, 19 May 2004 02:23:30 -0700 From: Brian Dessent Organization: My own little world... MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: [OT] RE: Problems listing tasks under cygwin. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Reply-To: cygwin AT cygwin DOT com Dave Korn wrote: > [ObCygwin] Sysinternals' tools are invaluable for diagnosing cygwin > problems just as much as windoze problems. Trouble with access perms for > your cron daemon service? See what's going on with tokenmon. Trouble with > file access? Filemon will show you what files are involved. Need lofs > functionality? Use HandleEx or ProcExp. And so on! Although I'd still like to know why using ProcExp to list the handles* of any running Cygwin process causes the CPU to peg to 100%, and not come down until cygwin1.dll is unloaded, i.e. kill all running cygwin tasks and services. I've had to train myself when using ProcExp to never accidently click on any Cygwin process, otherwise I have to go through the annoying process of closing all rxvt's and stopping all cygservices in order to get an idle CPU again... I've seen this reported to the list before but it got no replies. It started several notches back in the 1.5 series when there were a large number of changes to the signal handling code, IIRC. [*] It could be listing DLLs that causes it, but I don't want to find out at the moment. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/