This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 1.5.21-1: sshd: "child_copy: linked dll data write copy failed" after computer reboot (Windows 2000 SP4)

Dan Harkless wrote:
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?

Yes, the problem would still occur.  See the email archives for details if
you're interested.

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

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

I suspected.

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.

It's highly dependent on the order you did things.

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.

Trust me.  You're better off without them.  Add the path to bin to your
PATH variable for Windows and everything that needs cygwin1.dll will just
work.  Same for cygz.dll, as long as you've installed that package.

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 URLs to an area on, BTW) or something to find
out who's sticking it there.

Right.  Unfortunately, you'll have to do this every time you install from a

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.

Setting the hidden attribute on DLLs is now standard Windows procedure.

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

Right. You're welcome. :-)

Larry Hall                    
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
216 Dalton Rd.                          (508) 893-9889 - FAX
Holliston, MA 01746

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]