X-Spam-Check-By:	sourceware.org
From:	"Dave Korn" <dave DOT korn AT artimi DOT com>
To:	<cygwin AT cygwin DOT com>
Subject:	RE: cygwin + windows update = lock up (W2K SP4)
Date:	Tue, 2 May 2006 19:54:07 +0100
Message-ID:	<003e01c66e19$caab4ea0$a501a8c0@CAM.ARTIMI.COM>
MIME-Version:	1.0
X-Mailer:	Microsoft Office Outlook 11
In-Reply-To:	<003201c66e14$0f7decf0$a501a8c0@CAM.ARTIMI.COM>
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Unsubscribe:	<mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

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
stack.

ntkrnlpa.exe!KiSwapContext+0x2f
ntkrnlpa.exe!KiSwapThread+0x6b
ntkrnlpa.exe!KeWaitForSingleObject+0x1c2
ntkrnlpa.exe!KiSuspendThread+0x18
ntkrnlpa.exe!KiDeliverApc+0x124
ntkrnlpa.exe!KiSwapThread+0x89
ntkrnlpa.exe!KeWaitForSingleObject+0x1c2
ntkrnlpa.exe!LpcpRequestWaitReplyPort+0x43d
ntkrnlpa.exe!LpcRequestWaitReplyPortEx+0x21
ntkrnlpa.exe!DbgkpSendApiMessageLpc+0x49
ntkrnlpa.exe!DbgkForwardException+0x84
ntkrnlpa.exe!KiDispatchException+0x38f
ntkrnlpa.exe!KiRaiseException+0x175
ntkrnlpa.exe!NtRaiseException+0x33
ntkrnlpa.exe!KiFastCallEntry+0xfc
ntdll.dll!RtlpQueryProcessDebugInformationRemote+0xa

  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
anything.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


--
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/

- Raw text -