This also occurs with MicroWeb-Server on Windows. So I reclassified it to WebServer-Problem.

MicroWeb specific:
Setting the extension_dir is not possible. Specifying a directory in the php.ini has no affect, although other settings can be configured fine...
Microweb supports PHP only over CGI-Interface.

Is there a chance to use the strace tool [1] to track what's going on/wrong here? This tool may help tracking down which directory/files are really accessed.

[1] http://razor.bindview.com/tools/desc/strace_readme.html

To mficher:

If you can give me some cookbook instructions on how to use this tool, then I would be glad to give it a try.  It looks as though it needs a running process, but the error occurs when I start IIS.  How can I accomplish what you need?

Oh yeah, I forgot to add that all the pertinent files for this extension are in the %system% directory!

try changing 'c:\php\extensions' to 'c:\\php\\extensions' or 'c:/php/extensions' and see if it begins to work.

Same issue. However, its it a requirement that the php directory be on the c: drive?

I have the same problem with any php version I install on the Win2k Server.

No php.ini does not have to be on the c: drive. 

However please make sure you are using the c:\\ or c:/ syntax. Also make sure that your php.ini file is in the correct location (look at the output of phpinfo()). With the cli and cgi versions you can often get away with putting the php.ini file in the same dir as the executable and it will find it there.

- James

I'm using the ISAPI version on Win2k IIS.

My install drive for php is I:\php\

My php.ini is in the H:\winnt\ directory (the phpinfo() function reports that is were it found it).

Php.ini coding :
----------------
; Directory in which the loadable extensions (modules) reside.
extension_dir = I:/php/extensions/
----------------

As long as I don't specify a extension to load, php works fine. But, once I un remark an extension (ei. php_mssql.dll), it gives the "unable to load dynamic library 'I:/php/extensions/php_mssql.dll' The support module not found" message.

I've tried both ways, I:\\ and I:/

Is the assumption that if no directory is specified, that it will automaticlly look in the c:\WINNT\System32 directory for the extension dlls, correct?

I had the same problem, after some hours of struggeling, I finanaly got it !!!!

This doesn't work : extension_dir=c:\php

This works :  extension_dir=c:\php\

It doesn't matter what dircotry the extension_dir is pointing to, you must put the last '\' there to make it work.

Good luck all :)

Should be mentioned in the manuel...

Derick

Well, since I thought I might have something miss installed, I've gone ahead and re-started my Win2000 Server installation.

I'm back to the same problem however. Any directory I specify for the extension dll, won't work. I've tried, d:\php\extensions, d:\php\\extensions\, d:\\php\\extensions, d:\\php\exetensions\\, d:/php/extensions, d://php//extensions,
d://php/extensions/, d://php//extensions//

I've attempted as well to move the dll into the system 32 directory, and in the same directory has the php.exe file. No luck.

Below are my specifications:

Server: Dell Power App 120 Server, SCSI hard drives.
OS: Window 2000 Server running IIS 5
PHP: Version 4.2.3 running ISAP installation

Php ini file : c:\WINNT\php.ini
Php directory : d:\php
Extension directory : d:\php\extensions

Note: I've installed this same version on 6 other Win2000 clients (Pro and Server) with IIS 5, and have not run into this problem before. The only main difference is that its a Power App Server, with SCSI drives.

The only thing I noiced you didn't do was what groet@yahoo.com said he tried and worked.  That was to put a single backslash \ after the directory name.  I haven't tried this, but here is what worked for me:
extension_dir=
Uncomment the php_xslt extension.
Place all these files in either the %SYSTEM% or %SYSTEM32% Directory: iconv.dll, js32.dll, libexpat.dll,php_xslt.dll, php4ts.dll and of course sablot.dll.

The js32 is only needed if the expat version has been compiled with the JavaScript extension.  Unless you have all the files in the system directory, you will continue to get errors when loading that point to your tail.  In other words they mean nothing except failure and unless you use a tool such as Dependency Walker to open the php_xslt.dll, you will become frustrated fast.  I saved all these files to a separate directory when I first installed xslt on my development system, then just copied them over to my production server and was up in no time!  I hope I didn't forget any of them, but if I did, just search this site for it and you will find many people who have used it (and the URL, I have forgotton it) successfully.  I am writing a Content Management system using XSLT as my chief means of XML processing, transformation and search engine.  I really like using it to build snipets of PHP logic that use XSLT to generate HTML or XML.  It's much more flexible than writing my own parser routines and objects, and the XSL languange is highly flexible.  I have even worked out some datetime math with it.  It could use some help in the extension department for that one!  Anyway, have fun at work!

Curtis

I'm running Win2k & IIS and I've been having the same damn problem.  Dumping everything plus the kitchen sink, dll-wise into %system32% fixed this issue for me, as well.  Good call, cdfisher!!  :-)

Part of my problem was actually reading the instructions that came with all these distributions.  (Stupid me.)  For instance, the Gingerall folks tell you to rename whatever dll you get from expat to expat.dll.  Even though I think they were referring to some old release that had the version number in its name, it's easy to apply this overbroad rule to the libexpat.dll library that expat's releasing now.  

Anyway, what worked for me was this:

In PHP.ini:
-Extensions_dir=
-Remove the ";" from in front of "extension=php_xslt.dll"

Then dump ALL the necessary dll's in %system32% without altering any file names. 

(ie, iconv.dll, js32.dll, libexpat.dll,php_xslt.dll, php4ts.dll and of course
sablot.dll.)

I have had this trouble for 3 days and now I found the problem.

I just moved php.ini from c:\winnt\system32 to c:\winnt and it worked.

I hope this information is usefull.

All the suggested solutions don't work in my case, I'm not shure, what it means if a bug has the status closed, but it is obviously not fixed. The phpinfo() shows the correct path for the extension_dir like it does for session_data etc. but the errormessage "can't load dynamic library -  modul not found", remains the same.

I was experiencing the same problem and was unable to find resolution.  However, it was not clear to me whether the problem was that PHP could not locate the module based on extension_dir= settings or a module problem.  Therefore, I tested the extension_dir setting by commenting out the extension=php_xslt.dll line and uncommenting another extension such as extension=php_zip.dll.  After resetting IIS and checking I found that the extension loaded correctly.  So it must be a problem with php_xslt.dll loading.  

I noticed that someone posted a message about installing expat's dlls in the system32 directory.  I downloaded the latest expat win binary and copied libexpat.dll and libexpatw.dll to the system32 directory.  Then I uncommented extension=php_xslt.dll in php.ini and restarted IIS.  It worked.  I believe that php_xslt.dll requires the expat dlls.

Hope this is helpful.  Good luck