xinted rsync bluescreen

[Dan Holmsand]

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 
<http://www.cygwin.com/ml/cygwin-xfree/2002-03/msg00060.html>, 
<http://sources.redhat.com/ml/cygwin/2001-11.t/msg00167.html> and 
<http://sources.redhat.com/ml/cygwin/2002-11/msg01369.html>

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/