This is the mail archive of the
mailing list for the Cygwin project.
RE: cygwin + windows update = lock up (W2K SP4)
- From: "Dave Korn" <dave dot korn at artimi dot com>
- To: <cygwin at cygwin dot com>
- Date: Tue, 2 May 2006 19:54:07 +0100
- Subject: RE: cygwin + windows update = lock up (W2K SP4)
On 02 May 2006 19:13, Dave Korn wrote:
> On 02 May 2006 18:15, Ludovic Drolez wrote:
>> Any hints on how to debug this problem would be appreciated !
> It's a waste of time posting random tracebacks I'm afraid. What we really
> need to do is attach a debugger to the thread that is eating the cpu time,
> see what it's trying to LPC to CSRSS and why it fails and retries
> continuously. I'm kind of looking at it at the moment but it is a slow and
> tricky process.
...because for some reason, despite attaching the debugger, and despite having
frozen every other thread and only left one running, every time I try to
single step it, it just carries on running as if I'd told it to continue.
Dunno why except perhaps the debugger isn't keen to try and let you
single-step through debugger-related functions in case it breaks itself or
something. This may call for a full two-machine kernel remote debugging
session in the end :-(
Still, I did get at least a dynamic snapshot of the thread in question's
By repeatedly looking at snapshots of the thread's stack with process
explorer, you can see that it's doing this a lot, and making hundreds of
thousands of context switches per second - that's the LPC message going across
to CSRSS and the reply coming back. Hmmm, I wonder whether that APC is part
of the LPC reply completion mechanism.
Oooh, wait aminute. I have a thought. Perhaps this is SEH-vs-DllMain
attach calls again...?
Anyway, it's all a bit speculative. Will post more info once I have
Can't think of a witty .sigline today....
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html