No longer is the current directory searched first when loading DLLs!
This change was also made in Windows XP SP1. The default behavior now
is to look in all the system locations first, then the current
directory, and finally any user-defined paths. This will have an impact
on your code if you install a DLL in the application's directory
because Windows Server 2003 no longer loads the 'local' DLL if a DLL of
the same name is in the system directory. A common example is if an
application won't run with a specific version of a DLL, an older
version is installed that does work in the application directory. This
scenario will fail in Windows Server 2003.
The reason this
change was made was to mitigate some kinds of trojaning attacks. An
attacker may be able to sneak a bad DLL into your application directory
or a directory that has files associated with your application. The DLL
search order change removes this attack vector.
The SetDllDirectory
function, also available in Windows XP SP1, modifies the search path
used to locate DLLs for the application and affects all subsequent
calls to the LoadLibrary and LoadLibraryEx functions by the application.
LoadLibraryEx On Tue, Aug 4, 2009 at 8:01 AM, Tamas Nepusz
<address@hidden> wrote:
> > Hmm, I'm not very familiar with Windows debugging either. Can you obtain
> > a full stack dump somehow at the point where the application crashed?
> It is 13MB compressed (7zip). Send it to you directly?
Is it from the crash inside the Python interpreter? If so, can you try
to reproduce the issue using plain C igraph first and then send me the
stacktrace from the C program (if it crashed)? Please try it with and
without the experimental C attribute handler attached -- it would help
me isolate whether the problem is in the Python interface, in the C
attribute handler, in the C core or in libxml2 itself.
Thanks,
--