Hi

I added a script map to a virtual directory in IIS 10 but every time I try to run a request using the mapped extension IIS uses the Static File module. My script map has the mapped to a file feature disabled and the execute feature enabled.

The same configuration runs fine on my local computer but not on my server which is running Windows Server 2016. I just installed it on a another Winddows 2019 Server and it worked perfectly.

I have tried adding the script map at the machine level, the website level and the virtual directory level and none of them work. I have reset IIS numerous times but nothing changes. Does any one have any other ideas? Is there a configuration file that might corrupted that I should check?

Thanks, Simon

Local web.config settings always override any global settings so if you have a mapping in web.config of the application it should work. If it doesn't it most likely means that your Virtual folder mapping is wrong.

It shouldn't be a virtual BTW, it should be an IIS application or root Web site.

If you go to the IIS Admin interface and drill into your application, and the configuration hierarchy it will show you what values are active and whether they are inherited or local to the app.

If you have multiple mappings (ie. your overriding .html for example) then order declarations may matter and you may have to make sure you remove the script map first, then add it using <remove> then <add>.

  <remove name=".wc_wconnect-module" />
  <add name=".wc_wconnect-module" path="*.wc" verb="*" type="Westwind.WebConnection.WebConnectionHandler,WebConnectionModule" />

You can remove any handlers here that are named higher up in the hierarchy including the html mapping.

+++ Rick ---

I converted the virtual directory to an application as you suggested. However, nothing changed. The ISAPI extension is load because I having a logging turned on in the AttachProcess method. However, HttpExtensionProc method never gets called. I turned on the Failed Request Tracing and I can see that the StaticFile module is called and errors out on file not found which would be expected since the file does not actually exists. I do not understand why the StaticFile module gets called since the script map is not connected to a file as I turned on the "Invoke handler only if request maps to:".

I have a number of other script maps setup under the same application and they all work. I can even access the web page directly without using the script map. It is just this one script map that is not working. I tried the same thing on several other servers and it works perfectly. I just cannot find the reason that causes the StaticFile module to be used.

Simon

Don't know without looking at your exact setup.

StaticFile Module should be the last handler in the chain, so if it gets there for your file extension the extension is not mapped.

Make sure the processor architecture is not set to the wrong CPU. There are overrides. Also make sure if you are using ISAPI the application pool is set to 32 bit explicitly.

+++ Rick ---

My ISAPI extension is 64bit so I have not enabled the 32bit application flag.

What ISAPI Extension are you talking about exactly? This is not the Web Connection ISAPI extension clearly?

+++ Rick ---

First off I apologize as I have my message in the wrong forum. It should probably be in the IIS forum.

I have both 32 bit Web Connection ISAPI extensions and other 64 bit extensions created using other software. This particular one was written in Purebasic 64bit. I have a number of these 64bit extensions running on multiple servers.

Extensions are mapped to a specific bitness and you may have to explicitly provide the bitness as part of the handler reference. I can't remember why that might be required in some cases not others but it can bite you if the extension is not explicitly 64 bit but supports both 32 NS 64 bit.

+++ Rick ---

Hi

So I have dug a little deeper and if I compile my ISAPI extension as 32bit and set the bitness to 32bit for the application then the extension works. However as soon as I compile it as 64bit and set the bitness to 64bits it fails. It seems to some how get stuck in memory because if I shutdown the server it takes a long time and may take several retries before the dll is unloaded. In 32bit mode is unloads the dll right away and shuts down.

I am not sure what is different between Windows Server 2016 and Windows Server 2019 but everything works flawlessly on 2019. So maybe I will have to convert the server to 2019 if cannot find away around this issue.

Thanks for letting me know about the bitness.

Simon

Two things:

• You can't mix 32 and 64 bit extensions. Extensions have to match.
• The application pool bitness has to match the extension bitness (or multi-target)

I've had problems with bitness before but it's usually because for some reason or other the handler mapping defaulted to the wrong bitness. make sure you explicitly specify the bitness in the handler mapping and see if that helps.

+++ Rick ---

I finally found the problem. One of my included files was using GetCurrentProcessId_() which does not work unless it is in the AttachProcess method. I moved it into the AttachProcess method and everything works perfectly.

Simon