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 X-Injected-Via-Gmane: http://gmane.org/ To: cygwin AT cygwin DOT com Path: not-for-mail From: Dan Holmsand Subject: Re: xinted rsync bluescreen Date: Mon, 13 Jan 2003 19:18:33 +0100 Lines: 126 Message-ID: References: <59A835EDCDDBEB46BC75402F4604D5528F75CC AT elmer> <005001c2b841$b3f55520$4d1f1cac AT THEODOLITE> <000401c2b846$48882a60$0201a8c0 AT sos> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet AT main DOT gmane DOT org User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en In-Reply-To: <000401c2b846$48882a60$0201a8c0@sos> Sergey Okhapkin wrote: > net start init > chkconfig rsync on > chkconfig rsync off > > bluescreen... Win2000. I have no rsync installed. > > I set system environment variable CYGWIN to "nontsec", restarted init > service and the problem went away... I've seen this occasionally as well, but it doesn't stop there. Any access of files under /etc seems to be able to occasionally trigger a blue screen while init is running. A particularly sure fire way of causing the BSOD seems to be running /sbin/telinit, but even viewing a file under /etc with vim can sometimes be enough. The BSOD happens both using 1.3.18 and the latest snapshot, on W2K SP3, with no anti-virus software running. I've seen BSODs on quite different machines (both on a Compaq Proliant and on a couple of Compaq Armadas): the common denominator seems to be that init is running. Init is in turn running sshd, cron, xinetd, ipc-daemon and postgres. However, it might not be init (directly) that causes the BSOD; the bugcheck analysis (below) seems to be at least somewhat similar to the ones posted in , and My guess is that cygwin does something that sometimes triggers a windows (or, rather, ntfs) bug when files under /etc are used. This is of course just a wild guess. Another observation: it seems (according to Process Explorer from sysinternals.com) that cygwin programs started from init keep a handle to the /etc directory open. That shouldn't be needed, should it? I have no idea if this has anything at all to do with the BSODs, of course... Hopefully this information might be useful to someone more familiar with Cygwin and Windows internals than I am. /dan Here is a typical bugcheck analysis from windbg: IRQL_NOT_LESS_OR_EQUAL (a) An attempt was made to access a pagable (or completely invalid) address at an interrupt request level (IRQL) that is too high. This is usually caused by drivers using improper addresses. If a kernel debugger is available get the stack backtrace. Arguments: Arg1: 00000014, memory referenced Arg2: 00000002, IRQL Arg3: 00000000, value 0 = read operation, 1 = write operation Arg4: 8045505d, address which referenced memory Debugging Details: ------------------ READ_ADDRESS: 00000014 Nonpaged pool CURRENT_IRQL: 2 FAULTING_IP: nt!PsChargePoolQuota+50 8045505d 0374bb10 add esi,[ebx+edi*4+0x10] DEFAULT_BUCKET_ID: DRIVER_FAULT BUGCHECK_STR: 0xA TRAP_FRAME: bddd6710 -- (.trap ffffffffbddd6710) ErrCode = 00000000 eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=00000020 edi=00000001 eip=8045505d esp=bddd6784 ebp=bddd6798 iopl=0 nv up ei pl zr na po nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246 nt!PsChargePoolQuota+50: 8045505d 0374bb10 add esi,[ebx+edi*4+0x10] ds:0023:00000014=???????? Resetting default context LAST_CONTROL_TRANSFER: from 80495801 to 8045505d STACK_TEXT: bddd6798 80495801 ff974b40 00000001 00000020 nt!PsChargePoolQuota+0x50 bddd683c bfeed999 81a73368 81a49bc8 e27e2b98 nt!FsRtlNotifyFullReportChange+0x46d bddd6ab8 bfeeaa06 bddd6b00 ff93c508 81a49800 Ntfs!NtfsCommonCleanup+0x2061 bddd6c30 8041f79f 81a49800 ff93c508 ff93e108 Ntfs!NtfsFsdCleanup+0x113 bddd6c44 8049bb90 80067c64 81aa9040 00000001 nt!IopfCallDriver+0x35 bddd6c78 804a50e5 ff93e1c0 81a49800 00120196 nt!IopCloseFile+0x275 bddd6ca4 8044f718 ff93e1c0 ff93e0f4 ff93e108 nt!ObpDecrementHandleCount+0x13c bddd6d58 80465091 000000bc 00000000 00000000 nt!NtClose+0x1f0 bddd6d58 77f8376e 000000bc 00000000 00000000 nt!KiSystemService+0xc4 WARNING: Frame IP not in any known module. Following frames may be wrong. 0022fc0c 00000000 00000000 00000000 00000000 0x77f8376e FOLLOWUP_IP: nt!PsChargePoolQuota+50 8045505d 0374bb10 add esi,[ebx+edi*4+0x10] FOLLOWUP_NAME: MachineOwner SYMBOL_NAME: nt!PsChargePoolQuota+50 MODULE_NAME: nt IMAGE_NAME: ntoskrnl.exe DEBUG_FLR_IMAGE_TIMESTAMP: 3d366b8b STACK_COMMAND: .trap ffffffffbddd6710 ; kb BUCKET_ID: 0xA_nt!PsChargePoolQuota+50 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/