PHP 4.1.2, ISAPI, IIS 5.1, XP - NUTS!!!

[Anon]

I know from reading this newsgroup that installing the combination below is always problematic but please have mercy, I am going completely nuts with this one. I have PHP4.1.2 on Win XP trying to run with the ISAPI module on IIS 5.1. Here's the story so far.

Unpacked standard PHP dist to C:\Php.
Added some extra dlls and extensions from the PHP4Win people.
Copied php4ts.dll to C:\Windows\system32.
Added C:\Php, C:\Php\dlls, C:\Php\extensions to the PATH environment variable.
Applied read and execute permision for the Users group (which includes IUSR_xxx and IWAM_xxx)
to C:\Php, subfolders and files.
Renamed the php.ini-recommended to php.ini and copied to C:\Windows.

Modified php.ini file as follows:
allow_call_time_pass_reference = On
display errors = On
display_startup_errors = On
log_errors = On
track_errors = On
html_errors = On
error_log = "C:\Php\error.log"
variables_order = "EGPCS"
gpc_order = "GPC"
default_charset = "iso-8859-1"
include_path = ".\"
doc_root = ".\;C:\Inetpub\wwwroot\"
extension_dir = "C:\Php\extensions\"
cgi-force-redirect = 0
extension=php_bz2.dll
. ;Several extensions enabled
. ;too many to list
extension=php_zlib.dll
tab-width=4

Also added a [debugger] section for DBG:
[debugger]
debugger.enabled = true
debugger.JIT_host = clienthost
debugger.JIT_port = 7869
debugger.profiler_enabled = true

Well thats the setup, now here's my results so far.
This setup works perfectly from the command line and from IIS in cgi mode.
However, as soon as I switch to ISAPI mode (which is the one I need) it breaks.
I get the dreaded message boxes 'Unable to load xxx.dll'. One for each of the enabled extension dlls.
I have used the Filemon tool from sysinternals.com to see what is going on with the ISAPI and can see
nothing wrong. The IIS server process opens and loads php4isapi.dll and then opens and reads the
browscap.ini file. The IIS process then starts to load the extension dlls and correctly indicates the
directory as C:\Php\extensions\ but after reading each dll image IIS accesses C:\Php\error.log which
is when the 'Unable to load' dialog is displayed. Apart from the error sequence the actual access and
reading of each dll as displayed in FileMon looks the same as for the cgi. I thought it might be a permissions problem and granted Full control to Everyone for the C:\Php folder but without success.

Anybody have any ideas or hints. I've been asked to get PHP4 running on XP using IIS specifically
in ISAPI mode (they have enough of a clue to know its faster). If it turns out to be unstable, etc thats
ok since this is an evaluation exercise. But I don't really want to lose face by admitting defeat on just
the installation. Remember this works fine from the command line and for cgi mode so that would
seem to rule out a path or general permissions problem. I think this must be a more specific
permissions problem to do with the ISAPI mechanism in IIS and in particular may only occur on an
XP/IIS5.1. I thought it might be the IUSR_xxx deny ACLs in C:\Windows\system32 which are unique
to XP I think. I removed the deny ACL from C:\Windows\system32\cmd.exe but that didn't help either.

Anyway, my neurons are completely burnt out on this one and I need a helping hand.
Any kind soul got any bright ideas ???

[Anon]

Try this....

Copy all the .dll files from the php\dlls directory in to the system32 dir as well.

[Anon]

Also....when setting up the ISAPI filters did you select C:\PHP\sapi\php4isapi.dll (or your correct path)?

Also make sure that on the Home directory tab you have gone to "Configuration" and added "C:\PHP\sapi\php4isapi.dll" in the executable line and given it the .php extension.

After all that is done, best thing to do is drop to the command line and type "net stop iisadmin". Once the service stop then type "net start w3svc" and start it all up again. Then I would go into IIS admin and look at the ISAPI filter tab to make sure that there is a green arrow next to your entry.

[Anon]

Didn't copy dlls to system32 since C:\Php\dlls added to the system path. And since command line and cgi modes working these dlls seem to be getting loaded. Did try putting in system32 before, made no difference, just tried again and still makes no diference.

Yes, I did register the php4isapi.dll with correct path and set the .php extension to php4isapi.dll under Home:Configuration.

I also just tried monitoring IIS startup using the sysinternals.com process viewer. The extension dlls actually get loaded into IIS's process space momentarily and then get dropped with an error. Point is the php4isapi.dll must be getting called and then attempting to load the extension dlls which are being found but failing to load for some reason.

Right now I am just examining php4isapi.dll with Depends to see if I can get a hint as to what is going on.

Any further input welcome!!

[Anon]

Finally got this one sorted and as usual it was something simple and very stupid. Here goes with an explanation.

On my system sometime ago I prepended '.;' to my system search path so that exes, dlls. etc in the current directory would always be found first. It was this that was indirectly tripping me up.

Just to recap I have PHP4 in C:\Php. In the end I did NOT copy the dlls to C:\Windows\system32 (no need - read on) nor did I copy php4isapi.dll to the C:\Php folder. However I did copy php4ts.dll to C:\Windows\system32 (and this was part of the problem). Since I did not copy dlls to the system32 folder, I added C:\Php and C:\Php\dlls to the system path environment variable. Did all the remaining usual stuff eg. edited php.ini, copied to C:\Windows, added ISAPI filter to IIS, added .php extension to IIS. And this worked fine for command line and cgi modes but blew up in my face ('Unable to load xxx.dll' messages for every extension dll) in ISAPI mode.

Remember the '.;' on my system path. Well in command line and cgi modes C:\Php\php.exe is called and the '.;' would map to the C:\Php directory. So php.exe when looking for php4ts.dll would find C:\Php\php4ts.dll before finding C:\Windows\system32.php4ts.dll. In ISAPI mode C:\Php\sapi\php4isapi.dll is called and the '.;' would map to the C:\Php\sapi directory. No php4ts.dll would be found in this directory so Windows continues to search and finds C:\Windows\system32.php4ts.dll. So the comand line/cgi modes and the ISAPI mode call different copies of php4ts.dll.

So what I hear you cry!! The two php4ts.dll files are the same, whats the difference. As it turns out they were not the same. Somehow when adding some extra dlls to the standard PHP4 distribution, I managed to copy a rogue version of php4ts.dll to C:\Windows\system32 and this rogue version did not export all the functions expected by php4isapi.dll. This caused all the error messages when loading the extension dlls. Since the 'C:\Php;' in my system path would pick up C:\Php\php4ts.dll, I just deleted the rogue copy from C:\Windows\system32. And like magic it all started working!!!

And it works with out copying any dlls to other folders!! If you set your system path correctly the only file you need to copy is php.ini to C:\Windows. Add '.;' to the beginning of your system path, add 'C:\Php;C:\Php\dlls;' to the system path AFTER the 'C:\Windows\*' entries and thats it. Make the IIS changes and all should work.