X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Message-ID: <48D14427.1080102@cygwin.com> Date: Wed, 17 Sep 2008 13:53:43 -0400 From: "Larry Hall (Cygwin)" Reply-To: cygwin AT cygwin DOT com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20070505 Remi/2.0.0.0-3.fc4.remi Lightning/0.8 Thunderbird/2.0.0.0 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: cygwin AT cygwin DOT com CC: cygwin-list08 AT harkless DOT org Subject: Re: 1.5.21-1: sshd: "child_copy: linked dll data write copy failed" after computer reboot (Windows 2000 SP4) References: <200809171742 DOT m8HHgT5N008044 AT www DOT harkless DOT org> In-Reply-To: <200809171742.m8HHgT5N008044@www.harkless.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com 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 . >>> 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 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/