Works in Vista but not on Windows 2008 (is it 64bit?)

Topics: Developer Forum
Jul 8, 2009 at 5:09 PM

I have IIRF working fine in Vista using IIS 7 but when I upload it to my server which is running Windows 2008 Standard on 64bit CPU's I get no response, and am just faced with 404's

Anyone been successful with a similar set up?!?


Jul 8, 2009 at 5:49 PM

I worked out what the problem was....

On 64bit CPU's you need to set the Advanced Setting for "Enable 32bit Applications" to true on the Applicaton Pool

Aug 3, 2009 at 3:02 PM

i am running windows server 2008 web 64 bit, and when i enable 32 bit applications on the website's application pool the site returns 500 errors. server.getlasterror reveals nothing, it's full of empty strings and zeroes.

i will try a few other things to see if i can get this to run on our new server. i really enjoy working with iirf.

Aug 3, 2009 at 3:32 PM

Have you tried running in classic mode?!

If you are getting a 500 error why isnt .net showing you the error?!

Aug 3, 2009 at 4:09 PM

the managed pipeline is in classic mode already.

i believe IIS is not showing error details because i am using a custom ASP script to store the error details in a DB table using server.getlasterror.

i will attempt to disable this error logging so the error is output or saved in the log. i just realized my logs aren't using local times, so i have no idea what i am looking at.

this IIS 7 is such a PITA with all its inconsistencies with 6.



Aug 3, 2009 at 5:00 PM

here is the error:


<fieldset><legend>Error Summary</legend>

HTTP Error 500.0 - Internal Server Error

Calling LoadLibraryEx on ISAPI filter "C:\Windows\System32\inetsrv\IIRF\IsapiRewrite4.dll" failed

<fieldset><legend>Detailed Error Information</legend>
Module IIS Web Core
Notification Unknown
Handler StaticFile
Error Code 0x8007007e
Requested URL
Physical Path D:\InetPub\WebSites\xxxxxxxxxxxxxxxx
Logon Method Not yet determined
Logon User Not yet determined
<fieldset><legend>Most likely causes:</legend>
  • The path to the ISAPI Filter is incorrect.
  • IIS received the request; however, an internal error occurred during the processing of the request. The root cause of this error depends on which module handles the request and what was happening in the worker process when this error occurred.
  • IIS was not able to access the web.config file for the Web site or application. This can occur if the NTFS permissions are set incorrectly.
  • IIS was not able to process configuration for the Web site or application.
  • The authenticated user does not have permission to use this DLL.
<fieldset><legend>Things you can try:</legend>
  • Ensure that the path to the ISAPI DLL is correct.
  • Ensure that the NTFS permissions for the web.config file are correct and allow access to the Web server's machine account.
  • Check the event logs to see if any additional information was logged.
  • Verify the permissions for the DLL.
  • Create a tracing rule to track failed requests for this HTTP status code. For more information about creating a tracing rule for failed requests, click here.
<fieldset><legend>Links and More Information</legend> This error means that there was a problem while processing the request. The request was received by the Web server, but during processing a fatal error occurred, causing the 500 error.

View more information »

Microsoft Knowledge Base Articles:

  • 294807
Aug 3, 2009 at 8:49 PM

The error code 0x8007007e translates to "The specified module could not be found."

This usually means the path you have specified for the ISAPI is invalid.    Do you have a file at C:\Windows\System32\inetsrv\IIRF\IsapiRewrite4.dll and is it readable? I am guessing, NOT.


Aug 3, 2009 at 10:11 PM

I agree or that the file is corrupt

Aug 25, 2009 at 3:49 PM

i am revisiting this issue today. this morning i have recopied the DLL and INI file from our windows 2003 server over to the 64 bit windows 2008 server web. i am confident the file was not corrupted during this process.

the file permissions were successfully changed during the copy to the new machines' users, so i did not make any changes. there are no specific permissions on the DLL located on the 2k3 server that i had to add to the file to make it work there.

now, i have the files in place, and the filter added to some websites in my iis. i visited one of the sites that is set up with the filter, and this file has not been created:

RewriteLog  c:\windows\temp\iirfLog.out
RewriteLogLevel 1

and i still get the 500 error when i change enable 32 bit applications to true on the website's application pool. if i delete the filter from the website's profile, enable 32 bit applications does not cause a problem, but the error comes back when i add the IIRF filter once again.

Nov 27, 2009 at 9:21 PM

i am still trying to get IIRF running on my windows server 2008 with SP1.

today, i verified that the file is in place, not corrupt, and the internet guest account has permissions on it and the ini.

then, i installed dependency walker and found out that these two DLLs are not present:



i can get LINKINFO.DLL by installing the Desktop Experience feature, easy enough. the other DLL i am stilll looking into.

also, dependency walker says my copy of IIRF.DLL is x86

Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
Error: Modules with different CPU types were found.
Warning: At least one delay-load dependency module was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.

the time stamp on my dll is 11/11/2009 12:32pm. i downloaded it from this link:

must i compile from the source to run on 64 bit windows?


Nov 27, 2009 at 11:42 PM

I don't know how to run on x64, but this is what I think

  • there is a checkbox for "run in 32-bit compat mode" or something, on IIS configuration in a 64-bit Windows, in order to enable it with the downloadable, 32-bit IIRF  binary.
  • you can also re-compile IIRF for 64-bit. 

I know this only from reading the forums and the "issues" for IIRF.  You can search it yourself, to get the full story.

good luck.




Dec 3, 2009 at 8:52 PM

since my last post, i have installed the Desktop Experience feature on the server and rebooted it to adjust the configuration. LINKINFO.DLL is now in place.

i found 2 versions of IESHIMS.DLL on the server, one in c:\program files (x86)\internet explorer and one in c:\program files\internet explorer

i copied the second file into c:\windows\system32, and now dependency walker doesn't allege any missing DLLs.

it still doesn't work, but i have new clues.

apparently, ISAPI filters and ISAPI extensions are unique beasts. i am about to dive into this: to see which i should be using.

what turned me on to this difference was this unrelated article about someone else having a similar problem while migrating to iis7

cheeso: yes, there is a checkbox on each website's application pool to enable 32 bit applications. when i set this to True, the above errors persist. if i leave it False, then the site runs correctly without IIRF, even though i have IIRF added as an ISAPI filter in the site configuration. i have not explored the possibility of compiling the DLL to run on a 64 bit yet. i have already gotten my feet wet with this current adventure and the context switch is not appealing to me at this time.




Apr 14, 2010 at 6:55 PM

So, Corey, whatever happened with this?  Did you get it to work? give up? 

Care to share?


Apr 14, 2010 at 7:26 PM

sadly, i have not succeeded. i often think about how nice it would be to run IIRF on our windows server 2008 machines, though.

after my last failed attempts, i wanted to try compiling a 64 bit version of the DLL. i have not done so.

Apr 14, 2010 at 7:34 PM


Well there's another person who's got a similar problem, and it may be the same problem as you, on the IIRF forums right now.  (See   You two might be able to help each other. 

Separately, I've received an offer of a x64 server machine that I can use for builds and tests.  I haven't done that yet, but I need to look into that. 

If I get that machine and am able to sort this issue, I'll post an update.   Actually I think if I had the build machine I would just try to build an x64 (supported) version, rather than sort out how to run the x86 IIRF.dll on x64.


Apr 14, 2010 at 7:44 PM

i read the other thread. yes, that is the same problem.

i agree that a 64 bit dll would be a smarter solution to pursue.

i will subscribe to that thread and start thinking about this issue once again so i may contribute if possible. it's been a few months  : )

Apr 24, 2010 at 4:31 PM
i installed Failed Request Tracing on the web server to see if it would reveal some more details about the errors. it does not. i set up a FRT rule on status code 500.1-999 to cover all 500 errors. no log is created as a result.
Apr 26, 2010 at 5:07 PM

Ya,  I myself never got much utility out of FRT.