Message-Id: <200611080730.kA87UDDl007884@www.harkless.org>
From: Dan Harkless <cygwin-list AT harkless DOT org>
To: cygwin AT cygwin DOT com
Subject: Re: 1.5.21-1: sshd: "child_copy: linked dll data write copy failed" after computer reboot (Windows 2000 SP4)
In-Reply-To: Your message of "Tue, 07 Nov 2006 21:44:19 EST."              <45514483.3070105@cygwin.com>
Date: Tue, 07 Nov 2006 23:30:13 -0800
Received-SPF: pass (www.harkless.org: localhost is always allowed.)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com


On November 7, 2006, "Larry Hall (Cygwin)" wrote:
> 
> No.  Another application using a different cygwin1.dll would have to be
> running.  As long as it is, the old cygwin1.dll is loaded in memory and
> will cause conflicts.  Kill'em.

Okay.  Good to know.  Would the other copy need to be called cygwin1.dll, or
would the problem still occur if the 3PP renamed their copy to something
else?

> > I did notice that there is a C:\WINNT\system32\cygz.dll file, dated June 21,
> > 2005 (I tried various 'strings' commandlines on it but didn't get anything
> > that looked like a version number).  Is it feasible it could be causing sshd
> > to misbehave after reboot until it's restarted?  Perhaps I should try making
> > a safety copy of it, reboot, and see if sshd allows connections without
> > being restarted.
> 
> Delete all cyg*.dlls you have in the system32 directory.  Whatever is there
> is put there by a <http://cygwin.com/acronyms/#3PP>.  

That was it!!  I copied off and then deleted cygz.dll from the system32
directory and now I can ssh in directly after rebooting!

Tellingly, when I tried to delete cygz.dll, I got an error that it was in
use.  Running Process Explorer told me it was sshd using it, so I had to net
stop it and then kill one remaining sshd process to be able to delete the
file.  A little odd that sshd binding to the wrong copy of cygz.dll would
only cause a problem when run at boot time, but there you have it.

> You don't need'em.  You don't want'em.  They'll just cause you grief (as
> you've noted already).

Well, I don't know that I don't need 'em.  I may have just broken a video
editing related piece of software that I have a need to use.  But perhaps if
the software specifically depends on those older versions of cygwin1.dll and
cygz.dll I can move them into the same directory as its executable.

A little worried about the fact that cygwin1.dll seemed to restore itself
after I deleted it, but I did install some video software last night, so
perhaps it was a new package that stuck in the new (if identical) copy
rather than the original one repairing itself.  I guess I could use Process
Monitor (the successor to Filemon and Regmon -- Microsoft is now redirecting
sysinternals.com URLs to an area on microsoft.com, BTW) or something to find
out who's sticking it there.

One thing I didn't notice until this evening is that the cygwin1.dll and
cygz.dll in system32 had the Hidden attribute on!  Some 3PP really didn't
want me to mess with them.  Luckily I always configure my Windows Explorer
to display hidden files (and I used 'find', which ignores the Hidden
attribute, rather than the error message's suggested Start... Search), but I
can see this causing a lot of consternation for less savvy users.

Thanks to all for your help in solving this!  (Hopefully it'll *remain*
working this time.  ;^>  At least if it doesn't I'll almost certainly know
why.)

-- 
Dan Harkless
http://harkless.org/dan/

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