Mail Archives: cygwin/2008/09/17/13:55:10
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/
- Raw text -