X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Message-ID: <4B1B0152.1030504@gmail.com> Date: Sun, 06 Dec 2009 00:56:50 +0000 From: Dave Korn User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: [OT] Re: Hippo icon for cygwin... References: <4B1A229C DOT 7090404 AT cwilson DOT fastmail DOT fm> <4B1A4EEC DOT 4030108 AT sbcglobal DOT net> <4B1A6DEC DOT 7010509 AT cwilson DOT fastmail DOT fm> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: 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 Robert Pendell wrote: > Using windbg to identify the culprit helps. Yes, anything else is pointless speculation; these kinds of crashes are way too esoteric to waste time guessing at. Enable full crash dumps in the system preferences, install windbg, trigger the crash, then (after rebooting) open memory.dmp in windbg; the output of "analyze -v" should tell you at once which driver was on top of the stack and so should be suspected. If you're lucky, you'll see the driver name on the BSoD and won't have to go to such lengths, but if it's a level or two up the stack when the crash happens, you'll need a debugger to show you the relevant module name. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple