Mail Archives: cygwin/2008/09/17/13:43:40
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.
I will be unsubscribing from the mailing list after making this followup
post, so if you reply, please CC me.
--
Dan Harkless
http://harkless.org/dan/
--
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 -