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

[Larry Hall (Cygwin)]

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/