After you install a default PHP 5.0.x – 5.3.x on a standard Apache 2.0 or 2.2 or Internet Information Services on Windows you get numerous “PHP Warning: PHP Startup: Unable to load dynamic library ‘c:\\php_path\\ext\\php_libname.dll’ — The specified module could not be found. in Unknown on line 0“. Great! Starting out on a fresh install and things just don’t work well. Looking up the filenames of these dlls, you’ll see that they’re all available in the right directory. So what’s the problem?
Quite likely, you leave the warnings as they are because most things just work with PHP, or you disable some of the extensions in php.ini and you’re not bothered with it anymore. This is a bug with PHP as long as I know it and it annoys me a lot that nobody ever bothered to even try a default install and check whether it worked problem-free. This article explains how you can get rid of these errors. It is not much work, but be prepared to spend about half an hour at least.
You download a full package, leave everything on and then click Install. It is the most basic configuration. After which you get all of the following errors in either your log or on the DOS prompt when you run it from the console:
PHP Warning: PHP Startup: Unable to load dynamic library 'C:\\Program Files\\PHP\\PHP5.2\\ext\\php_mssql.dll' - The specified module could not be found.\r\n in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library 'C:\\Program Files\\PHP\\PHP5.2\\ext\\php_oci8.dll' - The specified module could not be found.\r\n in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library 'C:\\Program Files\\PHP\\PHP5.2\\ext\\php_openssl.dll' - The operating system cannot run %1.\r\n in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library 'C:\\Program Files\\PHP\\PHP5.2\\ext\\php_pdo_mssql.dll' - The specified module could not be found.\r\n in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library 'C:\\Program Files\\PHP\\PHP5.2\\ext\\php_pdo_oci.dll' - The specified module could not be found.\r\n in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library 'C:\\Program Files\\PHP\\PHP5.2\\ext\\php_pdo_oci8.dll' - The specified module could not be found.\r\n in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library 'C:\\Program Files\\PHP\\PHP5.2\\ext\\php_pdo_pgsql.dll' - The specified module could not be found.\r\n in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library 'C:\\Program Files\\PHP\\PHP5.2\\ext\\php_pdo_sqlite_external.dll' - The specified module could not be found.\r\n in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library 'C:\\Program Files\\PHP\\PHP5.2\\ext\\php_pgsql.dll' - The specified module could not be found.\r\n in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library 'C:\\Program Files\\PHP\\PHP5.2\\ext\\php_pspell.dll' - The specified module could not be found.\r\n in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library 'C:\\Program Files\\PHP\\PHP5.2\\ext\\php_sybase_ct.dll' - The specified module could not be found.\r\n in Unknown on line 0
When you run the command PHP from the command line, you get to see the same warning and on top of that you get many popups of libraries that cannot be found.
All these files are available on the said locations, so what’s this “The module could not be found” all about? Placing the libraries in the PHP root directory obviously doesn’t work. Going to the php.ini and changing the settings for each and everyone of these to not load them helped, but that isn’t really a solution. So you google a bit. Just googling for the first line only already gives many PHP bug hits and other then a lot of babble, none of these offer a serious solution. Due to the tedious PHP bug system, bugs are considered “closed” when there’s a week of inactivity, which may come in handy for keeping the system clean, but also results in many bugs unresolved and repeated submission from the same bugs.
When I first encountered this problem, 2 years ago, I managed to solve it by changing the installation to only include the extensions for mysql, but that’s not really a good solution if you need some of the others, like OCI, P-Spell, Sybase or OpenSSL. Some of the manual sites have notes on this issue with partial resolutions in an English comment: in French, Hungarian and Brasilian Portugese does so too. These are all doubles (don’t bother to look them up) which won’t lead to a full resolution.
When you first install PHP with all defaults set, some of the libraries cannot be installed. Either because the necessary files are not in the MSI package (they are in the ZIP package, see below) or because some extensions need libraries that are part of larger distributions or are not licensed under the GPL.
The following section describes how you can analyze these errors yourself. This can be useful if you have similar errors, but for different libraries, or when the steps below do not remedy your situation.
The errors you see are deceptive. It mentions a filename and then it says “the specified module could not be found”. The module is there, so the error seems wrong. What next? I started the Process Monitor from SysInternals to analyze what was going on under the hood to find out what file could not be found.
In the next solution, I present a way to use all these extensions without errors. But as you will find out, apart from three or four of them, this is quite a bit of work. If you do not need these extensions, you don’t have to turn them on. However, if you do need Oracle, Microsoft SQL Server or SQLite connectivity, SSL access or the p-spell spelling control, you’ll have to take the long road.
Locate the following lines and place a comma in front of them (use search in your editor, it’s usually near or at the bottom, ordered mostly alphabetically):
[PHP_OCI8] ; extension=php_oci8.dll [PHP_OPENSSL] ; extension=php_openssl.dll [PHP_PDO_OCI] ; extension=php_pdo_oci.dll [PHP_PDO_OCI8] ; extension=php_pdo_oci8.dll [PHP_PDO_PGSQL] ; extension=php_pdo_pgsql.dll [PHP_PDO_SQLITE] ; extension=php_pdo_sqlite.dll [PHP_PDO_SQLITE_EXTERNAL] ; extension=php_pdo_sqlite_external.dll [PHP_SQLITE] ; extension=php_sqlite.dll [PHP_SYBASE_CT] ; extension=php_sybase_ct.dll
As the previous section showed, the files mentioned are not the ones that are gone. Instead, the message seems to say “Hey, I’m php_mssql.dll, but I cannot find something, I’m not gonna tell you what that is, but I’m just gonna end myself with a useless and confusing error. Bye bye!”. If this were a commercial package, I would ask my money back. But because this is a community effort, I can understand that in six years of development nobody of the thousands of testers have ever tried to do a normal installation with all settings set to default. Well, why would you, after all, none of the noobs would ever use the defaults, right? But that’s going to change as I’m about to bug them each month or so with a link to this post to tell them how to fix it, because I was one of those noobs that didn’t see the hidden instruction that said “remove all extensions in the setup and then click only very sparingly some extensions that maybe are in this distribution, possibly, if you are lucky”.
Enough babble on the subject of sneering. As some posts have shown, it is already quite a help if you install the ZIP package isntead of the MSI and then follow these instructions. But that’s not enough. It will remove three of the 11 messages you receive on a 5.2.x installation (even more on the 5.1 and 5.0 installations). So, I did some homework for you to make this easy. Here’s for each package that you can select in the installation but that does not install correctly (yes, that’s about almost every package!) what you can do to resolve it:
The following table lists all the missing libraries that a typical default installation on Windows Vista encountered. The list with wrong versions may be different for you. If you’ve installed some of these on an earlier encounter you may not have the same errors. But the basic method for resolution is the same: add the missing libraries and copy (not move!) the libraries with a wrong version to the base directory of the extensions.
description of problem
|ntwdblib.dll||available inside ZIP package of PHP|
|libeay32.dll, ssleay32.dll||wrong version of libeay32.dll in system32 dir|
|ntwdblib.dll||available inside ZIP package of PHP|
|libpq.dll||ssleay32.dll||wrong version of ssleay32.dll in system32 dir|
|sqlite3.dll||must be downloaded|
||ssleay32.dll||available inside ZIP package of PHP, but then still wrong version of ssleay32.dll in system32 dir|
|aspell-15.dll||available inside ZIP package of PHP|
|libcs.dll, libct.dll||see text (libct.dll only showed up in dep. walker, not in the process monitor)|
To get all modules working, just follow three simple steps (may take a while to finish up though):
- The green bold marked libraries are inside the ZIP package of the Windows PHP distribution. Download this ZIP package (must match the version you have of the MSI installer!) and simply copy these three libraries to the PHP root directory.
- The red bold libraries are not available in the ZIP package and are not part of the MSI distribution. In fact, apart from
sqlite3.dll, these dlls require special installation. See the section on each file.
- The red cursive bold libraries (third column) may or may not give errors on your system, it depends on whether you have other Open SSL libraries installed that already used earlier versions. If these files are inside the
c:\windows\system32directory, either replace them with the new version from your PHP directory or copy these two libraries to the
Not all files are delivered with the MSI installer. The green dlls in the list above are all available through the ZIP distribution. Go to the PHP Download page and locate the ZIP distribution that matches your current PHP version. Simply copy these libraries to the php base directory.
The totally un-understandable error that Apache shows — on behalf of PHP — that belongs to an extension trying to load another dll which appears to be of the wrong version:
PHP Warning: PHP Startup: Unable to load dynamic library ‘C:\\PHP52\\ext\\php_pgsql.dll’ – The operating system cannot run %1.\r\n in Unknown on line 0
Though the correct version is installed inside the PHP directory, the extensions are not correctly looking there, instead, they look in their base directories. Because they are loaded by Apache, the base directory is
ApacheDir\bin, which is not where these libraries are. In fact, the order in which libraries are searched is:
- everything in the
As far as I know, it is not possible to modify this order (for instance, it shouldn’t be too hard to add a preferred dll search path in the php.ini on a per-extension basis). In my case, the ssleay32.dll and the libeay32.dll files with a version from the year 2007, were found in the system32 directory. Since this is about the first directory that is searched, there are only two solutions here:
Solution 1: copy the correct dll from
%php_home% to the
%apache_home%\bin directory has the advantage of keeping everything closer together, in the case of moving the website to another system, this is easier.
Solution 2: update the dll in the system32 directory with a more recent one.
Normally, these files are backward compatible as long as their names do not change. In this case, it would be quite safe to update the files in the
It won’t work to simply download only
oci.dll from some site (you can download it from several). The file
oci.dll is part of the Oracle C Interface. Unless you need to use Oracle, I suggest you go to the relevant line inside the php.ini file and uncomment the loading of this extension. However, if you need to use this extension, you’ll need to install the free Oracle Client libraries and add them to the path. It is a bit more involved then that, though, but Oracle has a nice article describing how to install PHP and the Oracle Instant Client on Linux or Windows.
The most recent version of sqlite3.dll can always be found on the SQLite download page, where a small zip package with a precompiled dll version for Windows is available. For convenience, I made the sqlite3.dll available for download as well, just place it in the root of your PHP installation.
These dlls are part of the Sybase ASE distribution. The Sybase issue is very old and was already submitted in 2001 with PHP 4.0 but not resolved.
libct.dll cannot be offered through Open Source canals because they are not available as Open Source. If you need interaction with a Sybase Adaptive Server, you should check the installation for the Open Client tools, which are part of the Adaptive Server Enterprise License.
I’m not certain whether it is possible to connect to Sybase legally with these dlls when you do not have a license. Sybase does support Open Source efforts that need connectivity to their servers, but the SDK only comes licensed with the paid packages. It seems odd to me that you need a license of the SDK to use tools that are developed with that SDK. I’d find it normal if dlls come in a redistributable version, just like with Microsoft’s SDK’s: once you develop your tool you can distribute the needed dlls as part of your application. If I find such a way, I’ll update this post.
Hope this helped you the way it helped me. I’m not a PHP specialist (I can program in it, but that doesn’t make me a specialist), but this problem should be solvable by any non-PHP programmer. Network administrators and system administrators will encounter these problems and possibly hire somebody to get rid of these odd looking errors, or they’ll ban PHP altogether because they can’t get it installed the first time around.
I really like open source projects, but this little part of the PHP open source project has shown a years long negligence, maybe even decadence towards the vast group of Windows users that try to install PHP on Windows. These errors will go unnoticed sometimes simply because many people do not know where to look for errors after installation. But creating a clean environment right from a fresh installation is vital to success and should be taken seriously by the development team. Despite many efforts, the PHP community has not taken that leap yet.
Is this one of the reasons why so many people still frown upon PHP as a serious language? Possibly so but I don’t know. For me, it doesn’t add to the admiration I might have had for this environment but for some useful tools I just need to have it running (WordPress, WikiMedia software etc).
– Abel –