Problems running DLL ISAPI Extension RRS feed

  • Question

  • User1622957740 posted

    Hi all,

    I ran through installation of an older Application Server based on an ISAPI implementation with IIS 7. I was able to get the application configured to run without any major issues using application/script maps, but I can't for the life of me get the DLL to run directly.

    I have several script maps to this DLL which lives in a Virtual directory. Those script maps work fine. However accessing the DLL directly fails with a File Open dialog from IIS.

    • The DLL's directory is marked as Scripts and Executable
    • Anonymous User has rights in this directory via Windows File System Permissions
    • The DLL is allowed in the Application Extensions configuration (it works obviously with script maps)

    What am I missing here so that direct DLL links can run?

    I can make this work by using all script map links, but it there are lots of relative links around that point at the DLL directly so I still need that to work...

    Any help appreciated,

    +++ Rick ---

    Friday, June 16, 2006 5:19 AM

All replies

  • User209782248 posted

    Can you post the detailed http error message you are getting, and if possible the FREB trace for the request?

    You can turn on FREB tracing by following this walkthrough: http://www.iis.net/default.aspx?tabid=2&subtabid=25&i=969&p=1.


    Friday, June 16, 2006 11:28 AM
  • User-75227868 posted

    Rick - I think the most common problem when attempting to use an ISAPI dll for other direct references is the DllMain() entry point. That entry point could be needed for direct access but not required if the dll is being used as an ISAPI extension\filter. If your were able to access those Dlls directly in the past then this might not be the issue but just somethig to look at...

    MVolo - Not sure if he would have those logs since he says that the scriptmaps run fine and the failure only occurs if he calls those dlls directly...

    Friday, June 16, 2006 1:35 PM
  • User1622957740 posted

    Hi Mike,

    Hooked up the Failed Request Logging but nothing is showing up in the log folder. I don't think it's getting there. IIS is serving the file as a binary image - it's not treating it as an application extension.

    IOW, i don't think it's not being treated as a failed request, just not being served as the proper type of request.

    Here's what IIS sends back (minus the binary content <g>):

    HTTP/1.1 200 OK
    Content-Type: application/x-msdownload
    Last-Modified: Sat, 17 Jun 2006 02:24:13 GMT
    Accept-Ranges: bytes
    ETag: "89dfdb1fb591c61:0"
    Server: Microsoft-IIS/7.0
    X-Powered-By: ASP.NET
    Date: Sat, 17 Jun 2006 02:33:30 GMT
    Content-Length: 112128

    which is the content of the file...

    As I mentioned script maps work fine so the ISAPI Extension DLL itself is fully functional and working, but IIS is not treating it as dynamic content.

    I do have Scripts and Executables enabled on the virtual where the DLL lives and the diretory on disk allows the anonymous user read and execute rights. Just for kicks I added EveryOne just to make sure, but same result.

    In IIS 6 without those file system permissions I'd get the behavior like above, but with the permissions set it should work...

    +++ Rick ---

    Friday, June 16, 2006 10:43 PM
  • User1622957740 posted
    Well the DLL is working with script maps so I don't think it's a problem with DLLMain otherwise it would fail on all access...            
    Friday, June 16, 2006 10:44 PM
  • User209782248 posted

    Can you confirm that you have a script-map that looks like the following:

    path=*.dll verb=* modules="IsapiModule" scriptProcessor="" requireAccess="Execute"

    This is what causes the direct access to the *.DLL files to be loaded and executed as an ISAPI extension, as opposed to by the static file handler.

    It sounds like you already have the ISAPI module installed otherwise you would be failing to load the scriptmaps with scriptProcessor set to the DLL.


    Sunday, June 18, 2006 2:17 PM
  • User511787461 posted
    You have probably just not turned on execute permissions for the vdir - find the system.webServer/security/access/flags attribute and add Execute to the Read, Script probably already present there.
    Monday, June 19, 2006 8:59 PM
  • User1622957740 posted

    Hi Mike,

    Yes indeed, this was the problem. I'm not sure how this happened but when I went to the directory I noticed that all handlers were removed EXCEPT for the scriptmaps.Adding the ISAPI-DLL module into the list made it work.

    Eh, operator error <g>...

    BTW I think the naming in the handlers dialog is a little misleading. Add Module Mapping for the adding a built-in HANDLER seems like the wrong naming convention. I suspect the module list that pops also isn't a 1-1 match to what you can actually use. I don't suppose you can use the AnonymousAuthenticationModule as a Handler?

    Thanks for your help,

    +++ Rick ---

    Tuesday, June 20, 2006 4:18 AM
  • User209782248 posted

    Glad to help - btw, with clearing the handler list, you are also losing a number of other handlers you may want so be prepared :).

    Re: the UI dialog, I feel your pain :)  Combining the module and handler notions here is misleading - the fact that you can map a request to some native modules is just an artifact of how native modules provide request handling, and I wish we hadnt exposed it at the top level. 

    Would you be ok with losing the "suggestion" list of modules if that naming went away, and having to type in the native module that provides the desired handling?  This would be equivalent to IIS6 where you had to type in the ISAPI name if you were creating a new handler mapping.  But, as you note you have to know the name of the module you want anyway, since AnonymousAuthenticationModule does not serve any content :)


    Wednesday, June 21, 2006 12:58 PM
  • User1622957740 posted

    Well, it's not me that I'm worried about <g>. I can probably figure it out, but I'm thinking more about our typical customer who's intimidated by IIS Admin anyway <s>... If I'm documenting the settings, it's hard to explain to say module when I mean handler - it gets completed.

    I have to say that the the module list is a nice feature. I've had lots of occasions in the past were I needed to set up custom script maps to the ASP.NET ISAPI DLL and that process is tedious (open the ASPX extension, copy the DLL reference, add the new scriptmap and paste it) - so I can appreciate the module drop down.

    What would be nice if the 'module list' was filtered to show only those modules that include handlers. There's gotta be some sort of marker there (IHttpHandler for managed handlers - something similar in the unmangaged modules) that could be checked by the interface to show only eligable modules. Then you could name them handlers.

    If that can't be done I think I would like to see the dialog reference the 'modules' as handlers.

    +++ Rick ---

    Wednesday, June 21, 2006 1:46 PM