LoadLibrary error 487 (was Re: Please test latest developer snapshot)

Corinna Vinschen corinna-cygwin@cygwin.com
Sun Feb 27 21:37:00 GMT 2011

On Feb 27 12:05, Christopher Faylor wrote:
> On Sun, Feb 27, 2011 at 10:46:27AM +0100, Corinna Vinschen wrote:
> >Thanks, but your code only works on XP, not on Winodws 7.  In fact,
> >on Windows 7 Cygwin is now entirly broken since every single fork
> >segfaults.
> It works for me.  I had tested it on Windows 7.  My simple test case was
> just using ssh which always seemed to break when I got the code wrong.
> It works fine on Windows 7.  The crash reported on the mailing list also
> worked with my changes on Windows 7 and Windows XP.

That's weird.  It doesn't work for me.  As soon as winmm is loaded with
the DONT_RESOLVE_DLL_REFERENCES flag on Windows 7, my shell becomes
unusable.  The shell itself runs, but every single try to start another
application (including the stuff in startup scripts) fails with a SEGV,
sometimes with, sometimes without creating a stackdump.

Maybe that's because I'm running tcsh.  Probably tcsh does something at
every fork which triggers loading the winmm multimedia timer functions,
while bash doesn't.

> I just tried it on NT4 too and, bash, at least works.  I don't have
> enough stuff loaded to test ssh but I'll do that.
> >dll_load can't just call LoadLibraryExW(DONT_RESOLVE_DLL_REFERENCES) on
> >winmm just because it's in a forkee.  It has to check if a prior call to
> >LoadLibrary (or LoadLibraryExW(0) failed with ERROR_INVALID_ADDRESS since
> >only an OS on which that happens is affected by the problem.  Otherwise,
> >as I wrote in http://cygwin.com/ml/cygwin-developers/2011-02/msg00012.html,
> >it's plain wrong to load a DLL with the DONT_RESOLVE_DLL_REFERENCES flag
> >set, if you need a working copy of that DLL.
> If you were actually implementing what I meant then what you wrote in
> http://cygwin.com/ml/cygwin-developers/2011-02/msg00012.html was that it
> was "expected" that using DONT_RESOLVE_DLL_REFERENCES would result in a
> SEGV if applied to every dll in a forkee.  My code doesn't (or at least

Oh, hmm, right.  My pointer to my own mail was a bit misleading,
apparently.  I had tested both variations (all DLLs vs. only winmm),
and both SEGVed my shell constantly.  I'm sorry I wasn't more clear
in the mail I pointeed to.

> Oh and I forgot to respond to this:
> On Sat, Feb 26, 2011 at 07:40:45PM +0100, Corinna Vinschen wrote:
> >On Feb 26 13:14, Christopher Faylor wrote:
> >>(Of course Microsoft says not to use this flag so I wonder if it will
> >>be gone or broken in Windows 8)
> >
> >Where did you read this?  I only saw the text which says to be careful
> >because following calls to LoadLibrary won't call DllMain, just return
> >the existing module handle.
> http://msdn.microsoft.com/en-us/library/ms684179%28v=vs.85%29.aspx
>   "Note Do not use this value; it is provided only for backwards
>   compatibility.  If you are planning to access only data or resources in
>   LOAD_LIBRARY_AS_IMAGE_RESOURCE or both.  Otherwise, load the library as
>   a DLL or executable module using the LoadLibrary function."

Thanks for the pointer.  I have an offline version of the MSDN man pages
installed, and in this version the Note sounds quite different:

  Note  Use extreme care when using this value. If LoadLibrary or
  LoadLibraryEx is called for the same DLL after the DLL is loaded, then
  the DLL references will not have been resolved. This is because the
  second call to LoadLibrary or LoadLibraryEx simply returns a handle to
  the already loaded DLL. In this case, the process is likely to
  terminate abnormally.

  If you are planning only to access data or resources in the DLL, it is

The online version has changed a bit, apparently...


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

More information about the Cygwin-developers mailing list