HOWTO: Diagnose and Fix Common ISAPI Filter Installation Failures

Artikel
06/21/2005

How many of you are familiar with the following scenario of ISAPI Filters on IIS:

You have just obtained an ISAPI Filter DLL (either you compiled/linked it from source, or the binary was given or purchased)
You figured out whether to configure the DLL as a global or site ISAPI Filter
You restarted IIS to load the global ISAPI Filter (site ISAPI Filter load on-demand on first request for IIS6, immediately on prior IIS versions)

And... the filter does not appear to be loaded nor working. Now:

On IIS6, failure to load/run any configured ISAPI Filter results in failing to start the website, which means that you will see "503 Service Unavailable" for the request
On prior IIS versions, failure to load/run any configured ISAPI Filters are simply ignored by IIS, so it just looks like the filter is not working/running on the request

When you see the above situation when you are trying to install an ISAPI Filter, the best way to troubleshoot is to look in the Windows Event Log for error event entries from either W3SVC or W3SVC-WP regarding a failure to load the HTTP Filter DLL. The "data" of the error is the most important piece of information used to diagnose the failure to load/run an ISAPI Filter.

Here are some of the common error codes and resolutions (one big caveat mentioned at the end...):

Data: 02 00 00 00

Win32 error 2 - NET HELPMSG 2 returns "The system cannot find the file specified."

IIS was configured to load an ISAPI Filter, either per-website or globally across all websites, and the ISAPI Filter specified an ISAPI Filter DLL that does not exist.

Prior to IIS6, this sort of configuration slipped by silently because IIS would ignore and not load the configured ISAPI Filter. However, IIS6 treats this sort of invalid configuration as fatal to the operation of the website or web server and will fail loading because of it (leading to a 503 Service Unavailable error)

The right way to fix this issue is to determine if the ISAPI Filter is necessary for the operation of your web server. If it is not, then remove the ISAPI Filter; if it is necessary, then locate the correct ISAPI Filter DLL file and correct the configuration.

Data: 05 00 00 00

Win32 error 5 - NET HELPMSG 5 returns "Access is denied."

Since IIS uses the process identity to load and run an ISAPI Filter, it means that the process identity failed to have ACL to load the ISAPI Filter DLL. For IIS6 in worker process isolation mode, the process identity is configurable and is at least a member of the IIS_WPG group, while for IIS6 in IIS5 Compatibility Mode and prior IIS versions, the process identity is Local System. So, check for either deny or lack of allow ACLs for the process identity identity on the named ISAPI Filter DLL.
The ISAPI Filter DLL returned FALSE from GetFilterVersion() and GetLastError() returns ERROR_ACCESS_DENIED. The reason is completely arbitrary and depends on the ISAPI Filter implementation itself. For example, the ISAPI Filter may have tried to read/write a Registry key or file as the process identity, but unlike prior IIS versions, IIS6 runs as an unprivileged account by default that may fail to read/write with ERROR_ACCESS_DENIED, so the filter errors out by returning FALSE and leaving ERROR_ACCESS_DENIED as GetLastError().

Data: 7E 00 00 00

Win32 error 126 - NET HELPMSG 126 returns "The specified module could not be found."

The ISAPI Filter DLL is linked against some resource(s) that are not on the web server.

One common reason for missing link dependencies is when your DLL is compiled as DEBUG and you do not have the DEBUG CRT/ATL/MFC DLLs on the web server. The DEBUG CRT/ATL/MFC DLLs are installed by Visual Studio, so your filter DLL may magically work on your dev machine but mysteriously "fail" on the production web server.

Another common reason is when your DLL is linked against a newer version of CRT/ATL/MFC DLLs that are not present on the target OS. For example, DLLs compiled by Visual Studio .NET and later use CRT/ATL/MFC DLLs that are newer than available on the latest current version of Windows, Windows Server 2003. So, the DLL will magically work on your dev machine but mysterious "fail" on the production server.

The easiest way to diagnose this issue is to use DEPENDS.EXE from the Windows Platform SDK (or from VS.Net) on the problematic DLL on the OS and see which dependency DLLs show up as red. Then, make sure those DLL dependencies are satisfied on the target OS (DEPENDS.EXE will report all dependency DLLs as green).

Data: 7F 00 00 00

Win32 error 127 - NET HELPMSG 127 returns "The specified procedure could not be found."

In order to load a DLL as an ISAPI Filter DLL, IIS expects certain method signatures to be exported from the DLL. You must export at least GetFilterVersion and HttpFilterProc (TerminateFilter is optional). Using MS LINK.EXE, you do this by specifying a .DEF file with the /DEF switch using the following content as the .DEF file.
```
 LIBRARY MyFilterName
EXPORTS
    GetFilterVersion
    HttpFilterProc
```
If your ISAPI DLL uses an API call that is not actually present on the target OS, you can get this error. This is particularly insidious because you are able to compile/link the DLL successfully, yet the DLL fails to load on an OS which does not implement the API call you linked against.

For example, suppose your ISAPI uses the RegGetValue() API call introduced in Windows Server SP1 (all platforms) and XP Pro x64. You download and use the latest Microsoft Platform SDK, which contains the advapi32.lib and include files for you to link and use RegGetValue(). Now, you try to run this ISAPI DLL on XP Pro 32bit, which has an older version of advapi32.dll that as documented, does not support RegGetValue(). The end result is error 127 since your ISAPI DLL will be looking for advapi32.dll to provide the RegGetValue() that it needs... which does not exist on XP Pro 32bit.

The only way to resolve this is to use an API call that actually exists on the target OS. This is one reason why just because a piece of code compiles does NOT mean it actually works... ;-)

Data: Arbitrary Value

While using the data value to diagnose ISAPI Filter install failures usually works, there is one big caveat you need to know. The ISAPI Filter DLL itself can trigger the exact same event log entry with ANY data value, even for reasons unrelated to what I mention above.

IIS loads and initializes an ISAPI Filter by first calling LoadLibrary() on the configured filter DLL image file path, then verifying that at least GetFilterVersion() and HttpFilterProc() entrypoints exists, and finally invoking the GetFilterVersion() entrypoint. If this entry point returns FALSE, IIS will log the same "HTTP Filter failed to load" event log entry with WHATEVER value GetLastError() returns.

In other words, an ISAPI Filter can generate that event if it succeeded or failed for arbitrary reason - as long as the filter returns FALSE, the last set error gets reported.

//David

Comments

Anonymous
July 01, 2005
HOWTO: ISAPI Filter which sets Cache-Control based on Content-Type
Anonymous
July 08, 2005
HOWTO: ISAPI Filter which sets Cache-Control based on Content-Type
Anonymous
July 11, 2005
The comment has been removed
Anonymous
July 11, 2005
Please read the third paragraph of this blog entry and provide the necessary information to troubleshoot. Quote: "When you see the above situation when you are trying to install an ISAPI Filter, the best way to troubleshoot is to look in the Windows Event Log for error event entries from either W3SVC or W3SVC-WP regarding a failure to load the HTTP Filter DLL. The "data" of the error is the most important piece of information used to diagnose the failure to load/run an ISAPI Filter." You did not provide the "data" of the error, so no one can guide you to solve it. //David
Anonymous
July 19, 2005
The comment has been removed
Anonymous
July 19, 2005
Correct, DEPENDS.EXE is not going to be able to verify if your code makes any LoadLibrary() calls at runtime and whether they would succeed. You will have to do the code review yourself to figure that out.

If DEPENDS says the static linkages are good, and code review shows that dynamic linkages are good, then I cannot think of any more typical reasons. I am going to start with some more random possibilities

1. Are you sure that the failure actually comes from IIS trying to load your ISAPI Filter DLL and not anything else. Could that server have ANOTHER misconfigured/malformed filter from the upgrade that is failing (in other words, run DEPENDS on the actual module IIS reports to be failing to load with error 0x7E in the event log).

2. The event log entry is not unique - any ISAPI Filter can return FALSE in GetFilterVersion(), and the value returned by GetLastError() is what IIS reports as data for that event log entry.

So, it is possible for your filter to fail for arbitrary reason, return FALSE for GetFilterVersion(), and have random error code be logged. You will need to code-review to figure this out.

It looks like you need to do some more source code review on your ISAPI Filter to resolve this issue.

//David
Anonymous
July 20, 2005
The comment has been removed
Anonymous
July 20, 2005
If you are sure the error is not coming from the ISAPI Filter code itself (i.e. either failing to dynamically load another module or return FALSE from GetFilterVersion() ), then you want to look up MSDN documentation for LoadLibraryEx ( http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/loadlibraryex.asp ) for assistance on how to troubleshoot DLL load failures. The problem seems really far away from IIS/ISAPI at this point. //David
Anonymous
August 03, 2005
got this resolved. turns out it was an SP1 issue after all.

rebuilt test without SP1 and the same issue we were seeing in production started showing (we had previously just removed SP1 from test, which apparently doesn't really remove everything (filter still worked with SP1 removed)).
Anonymous
August 04, 2005
I am glad that you got the issue resolved.

If you do not mind me asking - what was the dependency that was causing your problems?

However, to be clear, this does not sound like an SP1 issue to me. Hear me out...

When a filter fails to load due to dependency failure, it is usually the fault of the filter author for requiring a dependency that the filter user did not fulfill. An SP cannot be the issue.

I can think of plenty of cases where user error can cause this situation, and only one situation where it is an SP1 issue -- if the uninstall failed to copy back the original file the SP overwrote. That is very improbable.

For example, here is one possible explanation for your situation.

Suppose your filter had a dependency on MSXML4.DLL which is not part of WS03RTM but is (hypothetically) included in WS03SP1.
- When you first built the test machine with WS03RTM you had to install MSXML4 Redist to get your filter to work.
- Then, when you applied WS03SP1 to the test machine things continue to work.
- You forget about this dependency when building the production machine and it fails to load the Filter because MSXML4 is not on WS03RTM
- You go back to the test machine and uninstall WS03SP1. The Filter still works because the MSXML4 Redist is there. So you think that SP1 uninstall apparently does not remove everything

Note: SP1 uninstall is NOT going to remove MSXML4 to get back to WS03RTM state because it was ALREADY installed on the system. The only issue I see in this scenario is user error. :-)

//David
Anonymous
August 09, 2005
The comment has been removed
Anonymous
August 14, 2005
The comment has been removed
Anonymous
August 23, 2005
You can find out the return code from any ISAPI extension by calling it in your browser explicitly and then look in the webservers logs. Here is an example logline

2005-08-23 18:41:01 W3SVC1 127.0.0.1 GET /myVirtFolder/myISAPIExt.dll - 80 - 127.0.0.1 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.2;+SV1;+.NET+CLR+1.1.4322) 404 0 2

The last two numbers 0 and 2 represent sc-substatus and sc-win32-status respectivly. The logs are usually located in: D:WINDOWSsystem32LogFilesW3SVC1
Anonymous
August 23, 2005
Absolutely. The IIS log file for a website is generally your friend when troubleshooting IIS, especially runtime errors during request processing.

In this case, we are talking about ISAPI Filters and specifically install/load time failures, and the event log entry is the only mechanism to troubleshoot.

Basically, no one has made a request to IIS, so errors have no place to go but in the event log.

On the other hand, ISAPI Extensions can only be triggered by a request, thus its errors can be found in the IIS log file for the website.

//David
Anonymous
August 25, 2005
The comment has been removed
Anonymous
August 25, 2005
lee - this error happened because you have misconfigured PHP.EXE as an ISAPI Filter. Since PHP.EXE is a CGI Executable that should be configured as an Application Mapping and NOT an ISAPI Filter, it does not export the necessary function exports that IIS expects of an ISAPI Filter.

This is not a problem with any Microsoft update - human editing of IIS configuration caused this.

The right thing for you to do is remove PHP.EXE from being configured as an ISAPI Filter.

See http://www.visualwin.com/PHP for help on correctly setting up PHP on IIS.

//David
Anonymous
January 09, 2006
Very good explanations, hanks for the help! The depends.exe tool worked beautifully.
Anonymous
February 09, 2006
Is there way to script a check on the success or failure of the Filter, ie a vbscript object that contains the state of loaded DLL's?

One can get the list of filters installed from the metabase, but how would one get the state? The metabase doesn't seem to contain that.

Doesn't necessarily validate it but if I look in the UI, the green up arrow tells me enough not to scurry off to the event viewer to see what went wrong. Some COM object contains that, right?
Anonymous
February 10, 2006
The comment has been removed
Anonymous
February 28, 2006
The comment has been removed
Anonymous
February 28, 2006
Jonathan - Error code 0x45A = Win32 Error 1114

NET HELPMSG 1114 returns:
A dynamic link library (DLL) initialization routine failed.

This issue is similar to the one described by this KB:
http://support.microsoft.com/?id=821157

Basically, your ISAPI Filter DLL is linked to load in a particular memory address that something else also wants, so these two binaries conflict over it. Whoever loads first wins.

In KB821157, some DLL is linked to load at one address that .Net Framework also wants, so ASP.Net ISAPI DLL fails to load because it was not first.

I have also seen variations where an ISAPI Filter compiles with /clr switch to load CLR at load time, but its Base address prevents CLR from loading... so the Filter DLL literally prevents itself from loading since CLR fails to load due to where the ISAPI Filter DLL is based.

Easiest solution is to change the Base memory address of whichever DLL you can recompile so that it does not conflict. You can also attach a debugger onto the w3wp.exe where the Filter fails to load, and since you know what Base address the Filter wants, use the debugger to see what DLL is loaded at that address at the point of failure.

//David
Anonymous
March 03, 2006
The comment has been removed
Anonymous
March 03, 2006
Jonathan - If your issue is what I think it is, then what is going on is that your DLL is choosing to locate itself at a virtual memory address which while in the middle of nowhere, conflicts with .Net Framework's desires over the same memory address... so .Net Framework fails to load up. If this filter also has dependencies on .Net... then the filter also fails to load up.

Can you tell me if this Filter DLL uses the .Net Framework in any way, or if .Net Framework is used within the process the filter DLL fails to load?

This can be fixed by recompiling the DLL to choose some other address as its base address and letting the OS relocate it if in conflict.

Using the debuggers from Microsoft Debugging Toolkit should be pretty painless to observe- after the filter load fails, run:
ntsd -p <w3wp's PID>
Then on the debugger's commandline, type:
lm
And press enter. It should dump out a list of module names and memory addresses. Copy/Paste that into a text editor. Then on the debugger commandline, type:
.detach
And press enter. You should now be detached from the process and can close that ntsd window without crashing anything.

//David
Anonymous
March 07, 2006
I don't believe I'm using anything from .NET.

I'm using just standard c stuff: windows.h, httpfilt.h, stdlib.h, stdio.h. I'm also using Sun's LDAP dev kit for C: ldap.h, ldap_ssl.h, lber.h, ldapauth.h.

depends.exe lists my isapi filter .dll preferred base address as: 0x61A40000.

Your debugger directions worked great and I've got the following listed in/around the above address after a .dll load failure (excerpt of full output):

5b640000 5b658000 strmfilt (deferred)
5f270000 5f2c9000 hnetcfg (deferred)
608f0000 60901000 ADMWPROX (deferred)
60ba0000 60bb1000 wamreg (deferred)
61200000 61215000 MSDATL3 (deferred)
62da0000 62da7000 LONSINT (deferred)
64700000 6472d000 IISUTIL (deferred)
647b0000 647d7000 IisRTL (deferred)
67150000 67159000 HTTPAPI (deferred)
68000000 6802f000 rsaenh (deferred)

I should be able to re-base the .dll if that would help, but I'm not sure how one would go about picking a "better" address than the one I'm currently using.
Anonymous
March 08, 2006
I've re-compiled my .dll three times at different preferred base addresses (depends.exe lists 0x6C1C000000, 0x6C3C0000, and 0x6FFC000000) and am still experiencing the same errors.

Is this a problem with how capable Windows is at relocating .dlls when the .NET framework is in use?

Based on my readings, Windows should be able to rebase this .dll dynamically when it loads (though at some performance cost).
Anonymous
March 09, 2006
Jonathan - No, the problem is not with Window's ability to relocate DLLs nor .NET Framework.

Please read KB 821157 carefully. The issue mentioned there is NOT with ability to relocate DLLs but rather with basing of DLLs that affect .Net Framework which happen to fail DLL load:
1. You compile the DLL with /clr for native/managed interop, which hooks .Net Framework initialization when the DLL is loaded
2. .Net Framework initialization has requirements for available memory block size for GC, caches, etc
3. The DLL has to be based at some location in memory

Now, suppose the DLL is based (or rebased) in memory in such a way that prevents .Net Framework from obtaining the size of memory block that it wants. Furthermore, suppose this DLL is the one that triggers .Net Framework to load (it is compiled with /clr). What happens when you try to load the DLL?

Well, LoadLibrary loads the DLL into memory. Because it is compiled with /clr, this load triggers the .Net Framework to load. But this DLL is based in memory in such a way that prevents .Net Framework from getting the memory block that it wants, so .Net Framework bails on initialization. And since this .Net Framework initialization is triggeredby the DLL with /clr, this failure causes the DLL to fail to load as well. This results in LoadLibrary reporting error 1114.

In other words, due to how the DLL is based, it literally prevents itself from being loaded. Strange but true.

Now, the issue that KB 821157 mentions can be hit as soon as you use /clr to compile. Your DLL does not need to be using anything from .Net at all.

Of course, your issue may have nothing to do with .Net nor DLL rebasing; I am just pointing out one easily plausible way to get to error 1114.

The next troubleshooting step involves getting the debugger attached onto the process but BEFORE your ISAPI Filter is loaded. Type in:
sx e ld "filter DLL name" <ENTER>
g

And then trigger your ISAPI Filter to load with a request. You will now break into the debugger right on the LoadLibrary call and you can step through things to see what actually causes your DLL to fail to load.

//David
Anonymous
March 14, 2006
I recently sat down and thought a little about the typical user experience when troubleshooting IIS6,...
Anonymous
March 16, 2006
Hurray! Another blog entry makes it past the 10K page-browsed mark...

//David
Anonymous
March 20, 2006
The comment has been removed
Anonymous
September 28, 2006
I would just like to say that your tip to use the DEPENDS.EXE utility was very useful indeed! It helped me identify a misconfiguration in the server's PATH variable (of all things).

Thankyou for the tip.

Max.
Anonymous
April 10, 2007
Thanks for all the info here. I'm not looking just to be "fed" (given the answer like youhave nothing else better to do than to) here, but to learn how to troubleshoot my own issues. I've installed WordPress on IIS. Now trying to get the PermaLinks set up. I'm installing an ISAPI filter now. I've followed http://www.juryriggin.com/2006/11/07/fixing-permalinks-when-using-wordpress-windows-2003-iis-60 to the letter and am getting the error indicating "Data: 05 00 00 00 -Win32 error 5 - NET HELPMSG 5 returns "Access is denied."" So according to what I think I've learned from your posts is that this is a "Process Identity" and ACL issue? right? My question now - is what is the next step I should take? I'm not familiar with dealing with IIS from a programmatic or scripting scenario.
Anonymous
April 10, 2007
Thanks for all the info here. I'm not looking just to be "fed" (given the answer like youhave nothing else better to do than to) here, but to learn how to troubleshoot my own issues. I've installed WordPress on IIS. Now trying to get the PermaLinks set up. I'm installing an ISAPI filter now. I've followed http://www.juryriggin.com/2006/11/07/fixing-permalinks-when-using-wordpress-windows-2003-iis-60 to the letter and am getting the error indicating "Data: 05 00 00 00 -Win32 error 5 - NET HELPMSG 5 returns "Access is denied."" So according to what I think I've learned from your posts is that this is a "Process Identity" and ACL issue? right? My question now - is what is the next step I should take? I'm not familiar with dealing with IIS from a programmatic or scripting scenario. mark.mills@desktop-assistance.com
Anonymous
April 10, 2007
The comment has been removed
Anonymous
June 19, 2007
The comment has been removed
Anonymous
July 09, 2007
I'm getting the 0000: 05 00 00 00 error. I am unsure as to how to fix this problem. Can anyone help?
Anonymous
July 17, 2007
The comment has been removed
Anonymous
September 11, 2007
The comment has been removed
Anonymous
October 01, 2007
Hi, I got one problem when loading an ISAPI filter. The filter runs well on WinXP and Windows Server 2003, SP1 but when I deploy it on my test server( also windows server 2003 SP2 std edition ) it fails with the error message: "Error in code", ID: 2214, and Data: b1 26 00 00 Win32 Error code is then 14001, and the source is W3SVC-WP. Any idea of what this can be, and how I can solve this? Thanks, Petri Wilhelmsen
Anonymous
October 30, 2007
The comment has been removed
Anonymous
December 04, 2007
I am receiving a 0000: 02 00 00 00 Data error when trying to load the websphere 6 iis plugin. I have checked NTFS security, and everything seems to be set ok. We currently have 2 webservers, 1 server loads the DLL successfully. When trying to set up the second webserver we receive the 2214 event id with data error above. thanks
Anonymous
March 10, 2008
I am trying to install the asp.dll filter but it will not load. I am getting this in the error log: 7f 00 00 00.
Anonymous
March 13, 2008
Chip - asp.dll is not a filter, thus what you see in the event log is exactly correct. Do not install asp.dll as an ISAPI Filter because it is not an ISAPI Filter. ASP.DLL is configured as an Application Mapping to handle .asp requests, which should be pre-configured by default. //Davi
Anonymous
March 13, 2008
Patrick - Make sure you configured the correct pathname to the Filter DLL. This is really a support issue for WebSphere, not IIS/Windows configuration issue. //David
Anonymous
March 13, 2008
The comment has been removed
Anonymous
April 16, 2008
The comment has been removed
Anonymous
April 18, 2008
Rahul - You are seeing the last case I mentioned, arbitrary value. It means the error came from the WebSphere ISAPI Filter iisWASPlugin_http.dll itself, which means you have to contact your support personel for that software. This seems like WebSphere configuration issue, unrelated to IIS. //David
Anonymous
May 29, 2008
I also got this 0000: 05 00 00 00 error. In my case, i just installed PHP (via installer) and loaded the php5isapi.dll , rebooted the machine and then got this Service Unavailable message. Can you, please, tell me what could i do for solve it? Best Regards from Brazil. Celso Bessa
Anonymous
May 30, 2008
Celso Bessa - If you used the PHP Installer, you need to obtain community support for PHP - it is supposed to setup everything for you. If it is doing this incorrectly, then you need to notify the PHP community and have the community correct it because the problem will likely affect everyone else that uses the installer. //David
Anonymous
June 17, 2008
Hi All, I have found one more scenario where IIS 5.1 raises an 127 "The specified procedure could not be found." error when attempting to start the WWW service on a Windows XP SP2 machine. I also have a working instance of IIS with the same configuration. I used the depends.exe to analyse the difference between the working and the non working instances. The file infocomm.dll should have the version 6.0.2600.2180 which seems to be the correct file version shared by all files in SP2. The service was able to start once i had this version installed. Please note: reinstallation of IIS did not solve the problem, which might indicate it justcopies whatever is present in the cab files and these are not from SP2. Thanks David for the tips here which helped me to resolve this. Regards Santhosh
Anonymous
June 18, 2008
santhosh - Thanks. Actually, Win32 Error 127 is pretty generic and happens whenever one piece of code tries to call a method in another piece of code and it fails to find that method. In the context of ISAPI Filters, the usual causes are as I describe above. In your specific instance, it was due to mismatched DLL versions, which do not have anything to do with ISAPI Filters. That specific problem happens for a small number of users with certain QFEs installed. //David
Anonymous
August 06, 2008
We are using IIS6. The ISAPI filter has been added to log the original client IP address in the log files. After adding the ISAPI filter, the status of the filter is shown with neither a red arrow nor a green arrow. It is blank even after several page requests. However all the pages were served successfully and we have not faced any issue with the site. The surprising part is, the ISAPI filter DOES it's expected functionality though the status of the filter in the site is blank. The log files do have the expected values. No error is logged in the event log (application + system) reg. the failure to load. Could you please help me in finding out where it goes wrong?
Anonymous
August 09, 2008
Premkumar - if the Website which loads the ISAPI Filter is not created with the IIS UI or ADSI CreateWebSite() (i.e. you just CreateNode the entire structurue), then an ACL will be missing on the /Filters node of that website, which will prevent IIS from providing Filter Status (which is just a volatile metabase property) even though the filter is loaded and running. This is really a corner case introduced with IIS6 when the worker process ran as unprivileged Network Service -- which may not be able to modify all metabase properties. The Filter Status is one of those volatile metabase properties used by the UI to display status, so when Network Service is unable to modify the /Filters node (which is completely reasonable), you end up with the situation where the filter is running fine but no status shows up. //David
Anonymous
August 12, 2008
Hi David, Thanks for the reply. Yes, the websites were not created using IIS UI. As you mentioned, ACL is missing from the filter node when I look at metabase.xml. If I continue with the filter (though the status shown in UI is blank), Will there be any issues ? Thanks & Regards, Premkumar Subramanian
Anonymous
August 13, 2008
Premkumar - if you do not observe any issues, then there is none to worry about. //David
Anonymous
September 01, 2008
The comment has been removed
Anonymous
October 14, 2008
The comment has been removed
Anonymous
October 14, 2008
Marcos - the blog entry already explains it - the ISAPI Filter returned a custom status code when failing to load. The reason completely depends on the ISAPI Filter, so you will have to obtain support for the ISAPI Filter. //David
Anonymous
October 18, 2008
I have not-standard question. I want to have an object (wrapper around native object) to survive app-pool recycling and to only be reloaded on iisreset. If I implement ISAPI filter/extention (native or managed, doesn't metter) to load this object, will it live in its own app-pool (app domain) that will not be subject to normal IIS health-check app-pool recycle? In other words where within w3wp.exe process do ISAPI filter loaded? Once we load it in ISAPI, I assume we will be able to marshal by ref the calls into and from w3wp app pool itself (I hope). Any thoughts? Thanks, Alina
Anonymous
November 26, 2008
Wow thank you! I had 7F 00 00 00 and my isapi worked in 32 bit and not 64 bit. I missed the /def for the 64 bit compile. Thanks again for all the help!
Anonymous
December 12, 2008
David, thanks for the great info across your site. I am having an issue loading an ISAPI filter for Tomcat (isapi_redirect-1.2.26.dll). I am running IIS 6.0 on Windows 2003. I checked the Windows event viewer, and I am getting a W3SVC-WP error, or 02 00 00 00. The ISAPI filter points to an existing DLL, so it is trying to load the right DLL, it is having some other error. I ran Dependency Walker on isapi_redirect-1.2.26.dll and it is showing a failure loading dwmapi.dll. I looked this up online and it is a Windows Vista DLL and should not even be on Windows 2003. I've also heard that it is a bug in IE7 since the IEFRAME.DLL looks for dwmapi.dll. Do you know how I can fix this problem? This is a shared development server so I would rather not uninstall IE7 if possible. Is there any other answer? Is dwmapi.dll really necessary to load my Tomcat connectors DLL? Thanks.
Anonymous
December 22, 2008
Chris C - the bug is in the Tomcat ISAPI filter. It should not be linked to have dependency on dwmapi.dll, which cannot be fulfilled on Windows Server 2003 without IE7. This issue has nothing to do with what you have heard with IE7 and dwmapi.dll -- it is the ISAPI Filter's fault for having extra dependencies... //David
Anonymous
February 04, 2009
Hi David, I've got really peculiar problem. I've got my own ISAPI Filter which works perfectly installed on two servers (Win 2003 Ent R2), but on other two it does not want to load. What is the most strange it's that it seems not to load but the page starts and there is no 503. Filter status is not showing any arrow (red or green) after first hit. IIS log shows the request as processed. Event viewer says nothing. Filter's log file is not created but it's one of the first tasks in GetFilterVersion. When log file is not created GetFilterVersion should return false. So my question is. In what situations IIS does not return 503 when the Filter is not loaded? Any help is welcome even a sentence that it's written in the documentation. Just to know that it's something known. Here is the code of GetFilterVersion (I'm very fresh to the VC++ so any constructive criticism of the code is welcome): BOOL CASFilter::GetFilterVersion(PHTTP_FILTER_VERSION pVer) { // Call default implementation for initialization CHttpFilter::GetFilterVersion(pVer); // Create buffer for logging char logBuffer[AS_BUFSIZE] = "TIME;TICK_COUNT;PROCESS;THREAD;LOG_LEVEL;TEXTn"; char szLogFile[ MAX_PATH ]; // Initialize COM CoInitialize(NULL); // Initialize some locks InitializeCriticalSection(&rulesInitLock); InitializeCriticalSection( &logFileLock ); // Initialize Configuration BOOL ret = ASConfiguration::Initialize(); if (ret == FALSE) { return ret; } //Initialize logger Logger::Initialize(ASConfiguration::logLevel); CASFilter::bRulesInitialized = FALSE; wcstombs(CASFilter::pchLogFileName, ASConfiguration::logFilePath, AS_BUFSIZE); CASFilter::logLevel = ASConfiguration::logLevel; CASFilter::hLogFile = INVALID_HANDLE_VALUE; sprintf( szLogFile, "%s.%d.log", CASFilter::pchLogFileName, GetCurrentProcessId() ); // Create file here hLogFile = CreateFile(szLogFile, GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL); if ( hLogFile == INVALID_HANDLE_VALUE ) { return FALSE; } DWORD writtenBytes; ret = WriteFile(hLogFile, logBuffer, (DWORD)strlen(logBuffer), &writtenBytes, NULL); if (ret == FALSE) { return FALSE; } // Clear the flags set by base class pVer->dwFlags &= ~SF_NOTIFY_ORDER_MASK; // Set the flags we are interested in pVer->dwFlags |= SF_NOTIFY_SECURE_PORT | SF_NOTIFY_NONSECURE_PORT | SF_NOTIFY_PREPROC_HEADERS;// | SF_NOTIFY_SEND_RESPONSE | SF_NOTIFY_SEND_RAW_DATA; // Set Priority pVer->dwFlags |= SF_NOTIFY_ORDER_LOW; _tcscpy(pVer->lpszFilterDesc, "..."); if (Logger::isInfo) logger.Info(logBuffer, AS_BUFSIZE, "Filter loaded successfully."); ret = logger.WriteToFile(hLogFile, logBuffer); return ret; }
Anonymous
February 04, 2009
The comment has been removed
Anonymous
February 04, 2009
The comment has been removed
Anonymous
March 04, 2009
Thanks for the great page, which didn't completely solve my problem but did point me in the right direction. When trying to set up isapi_redirector-1.2.27.dll with IIS 6.0, I was getting errors 2268 and 2214 with data 02 00 00 00 (system cannot find file). I thought it meant that IIS could not find the DLL I had specified. The key on this page that helped me is that the error was thrown by the ISAPI filter DLL itself, not by IIS trying to find the DLL. The file that was missing was a properties file that isapi_redirector-1.2.27.dll expects. See http://tomcat.apache.org/connectors-doc/reference/iis.html for full details. That page claims that you can use either the registry or a properties file called isapi_redirector-1.2.27.properties in the same directory as the DLL. The registry didn't work for me, but once I started using a properties file instead of the registry, the redirector started working. I hope this will be helpful to someone.
Anonymous
March 09, 2009
Gary S. - Glad that the blog entry helped resolve your issue. I do not expect a blog entry to resolve all possible issues with ISAPI Filters, but it should point everyone in the right direction and keep digging. I would use a tool like Process Monitor (or the older FileMon/RegMon) from SysInternals.com to sniff what file and/or registry key that isapi_redirector is querying at start up. Perhaps the Application Pool Identity running the isapi_redirector ISAPI Filter did not have permissions to read that registry key or file system resource. The FileMon/RegMon/ProcMon tool will tell you what happened. //David
Anonymous
April 07, 2009
The comment has been removed
Anonymous
June 30, 2009
I have a website "RootSite" use AppPool#0 and there are two virtual directories ("vdir1" & "vdir2") in "RootSite" vdir1 uses AppPool#1 and vdir2 uses AppPool#2. And then when IIRF rewrites requests to vdir1 or vdir2, it shows HTTP403 ERROR
Anonymous
August 26, 2009
The comment has been removed
Anonymous
August 27, 2009
I am able to load ISAPI dll file in IIS but getting error 404 file not found error after installing ISAPI in IIS. I am using IIS 5.1
Anonymous
September 06, 2009
The HTTP Filter DLL C:Program FilesWebSphereAppServerbiniisWASPlugin_http.dll failed to load. The data is the error. Data: 0000: fc 2a 00 00
Anonymous
December 22, 2009
We have this issue on SharePoint with the error data: 0D 00 00 00. Any thoughts?
Anonymous
April 22, 2010
Gary's comments on March 4 hit home. The Tomcat page he refers to was the eye opener.

Freigeben über