[pywin32-bugs] [ pywin32-Bugs-2609380 ] Cannot load .pyd files in ISAPI Extension

[SourceForge.net <no...@so...>]

Bugs item #2609380, was opened at 2009-02-17 10:12
Message generated for change (Comment added) made by jaraco
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2609380&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: win32
Group: None
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Jason R. Coombs (jaraco)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot load .pyd files in ISAPI Extension

Initial Comment:
Under IIS 7 (Windows Vista SP1) 32-bit or 64-bit and Python 2.6, I'm unable to load .pyd modules, including those in the standard library (e.g. _socket, _hashlib), from an ISAPI extension. I'm attaching a minimal use case that reproduces the issue.  To reproduce, install the ISAPI extension and then request http://localhost/pyd-fails/.  The issue does not occur in Python 2.5.  The issue was discovered with pywin32-212 but also is found in pywin32-213.

The output reported by the win32traceutil is the following:

trace on
Internal Extension Error: Factory function '__ExtensionFactory__' failed
Last Windows error: The specified module could not be found.
Traceback (most recent call last):
  File "C:\inetpub\isapi_test\pyd_fails.py", line 7, in __ExtensionFactory__
    import _hashlib
ImportError: DLL load failed: The specified module could not be found.

The underlying windows error code (found by calling LoadLibrary directly) is 126.  I used the Dependency Walker (depends.exe) to open Python\DLLs\_hashlib.pyd and depends.exe reports that msvcr90.dll is missing.  This DLL is part of the Windows Side-by-Side library management stuff that I still don't fully understand, and the DLL can be found in \Windows\winsxs\x??_microsoft.vc90.crt_*\msvcr90.dll (in two locations on each of my two machines).

As a test, I tried copying msvcr90.dll (tried both versions) to \python\dlls and retried the test. In this case, I get a different error: LoadLibrary returns error 1114: A dynamic link library (DLL) initialization routine failed.  This error seems to indicate that the msvcr90.dll is trying to load code at the same addresses as something that ISAPI has already loaded into its code space.

As expected, loading the _hashlib.pyd or _pyd_fails.dll files from a standalone python process has no problems.  Only in the context of ISAPI do the .pyd files fail to load.

I'm going to investigate AppPool and Security Settings to see if I can find a configuration that works in Python 2.6.

In the meantime, any suggestions would be appreciated.

----------------------------------------------------------------------

>Comment By: Jason R. Coombs (jaraco)
Date: 2009-02-19 16:01

Message:
Confirmed the fix in the yet-unreleased Python 2.6.2.  Also works in Python
3.0.1.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2009-02-17 17:34

Message:
I fear this problem is related to how Python loads the DLLS; Python 2.6's
svn tree has a fix in but is yet to be released.  Possibly the best way to
confirm this is to try it out with Python 3.0.1 - that has the fix in it,
so if that does work, I'm afraid the only real solution is to wait for the
next 2.6 build or use a patched python26.dll (contact me for this if you
want to try that)

----------------------------------------------------------------------

Comment By: Jason R. Coombs (jaraco)
Date: 2009-02-17 10:26

Message:
I experimented with different App Pools, running under Admin credentials
and with no .Net Framework and a Classic Pipeline, but the same error
occurs.  An environment-based workaround does not seem promising.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2609380&group_id=78018