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:
I wanted to follow up to the below thread from 2006 because I came across
another situation that had the same symptoms but a different solution.  More
info below the old post.

On November 8, 2006, Larry Hall (Cygwin) wrote:
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 <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!
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
sysinternals.com URLs to an area on microsoft.com, 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
3PP.

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
why.)
Right. You're welcome. :-)

Here was my original post on this topic:


http://www.cygwin.com/ml/cygwin/2006-11/msg00120.html

In the new case, it was on a Windows XP system rather than a Windows 2000
system. I was using Cygwin 1.5.25-12 and OpenSSH 5.0p1-1. The errors were
almost the same, except this time in sshd.log, it had "Win32 error 87"
rather than "Win32 error 487".


In this case, it turned out that there were no extra cyg*.dll files in the
Windows directories.  Instead, the culprit turned out to be McAfee VirusScan
Enterprise 8.0i.  There were no settings activated in it that should have
stopped sshd from working correctly -- merely being installed caused the
problem (not sure if it embeds portions of Cygwin or if it merely caused
similar problems).  As before, while sshd would not work after a boot, doing
a 'net stop sshd; net start sshd' would fix it temporarily.

Uninstalling VSE 8.0i fixed the problem.  VSE 8.5i was subsequently
installed on the system and sshd works after a reboot with it.

Good to know that a later version seems to help and/or solve the problem. The situation you describe has been reported in the past in various incarnations and has been characterized under the term BLODA. See <http://cygwin.com/faq/faq.using.html#faq.using.bloda> for more info.


-- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746

_____________________________________________________________________

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

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


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