At startup: Unable to initialize module

[Hjort16]

On my Win2003 server I receive this warning from PHP about 8 times during startup after rebooting:

[red]Unknown(): (null): Unable to initialize module. Module compiled with module API=20060613, debug=0, thread-safety=1 PHP compiled with module API=20020429, debug=0, thread-safety=1. These options need to match.[/red]

Googling revealed that many asks for help on similar warnings and rarely useful advice is returned. However it came clear that this type of PHP-warnings indicate that 2 dll-files loaded by PHP try to do the same thing. In my case API=20020429 points to the bad guy being php4ts.dll - a PHP 4 file - even though I just installed PHP 5.2.3.

So how could this happen? I found php4ts.dll hiding among the HP Proliant Support Toos (since this server is a HP Proliant ML350). HP bundles an old version of PHP into their 2007 upgrade of Proliant tools! I downloaded v 7.80A dated 27 Apr 2007, and it still contains php4ts.dll.

Renaming the offending php4ts.dll to php4ts.dll.old and rebooting the machine gave no warnings. Hurrah. And the HP tools are perfectly able to use the PHP 5.2.3 files installed in Program Files\PHP.

 

[jpadie]

this is simply a mismatch of libraries. you are trying to load a library that has been compiled on a different version of php to the one that you are running. so the interfaces [probably] do not match.

the solution, thankfully, is also easy. just download the installation package again from php.net and reinstall.

 

[Hjort16]

May gives similar advice like jpadie's but unfortunately installation or upgrading php with one of the installers from php.net do not relieve the problem. Why not? Because HP places their php4ts.dll in a directory out of reach for the php-installers, and therefore this old dll stays on forever. The only way to get rid of it is to rename (or delete) it manually.
And here is the core problem: The warning text gives no indication of what to look for, or where to look.

 

[jpadie]

remove all dll files with php prefixes from c:/windows and system32 directories

make sure that there is nothing in the path environment variable that could be causing php to find its libraries elsewhere