PHP Access Violation Error on Win 2008 R2, PHP 5.2.12

We’re experiencing an occasional PHP Access Violation error. It is becoming more frequent but usually takes 14 days or longer to present.

Our server is running:
- Windows Server 2008 R2
- PHP 5.2.12 via ISAPI
- MySQL 5.1.51 Community
- Plesk 9.5.2
- Sites using MODx Revolution, various versions from 2.0.4-pl2 to 2.1.1-pl

I know the MODx requirements state PHP via FastCGI so my first query would be is FastCGI an absolute requirement or is this recommendation for speed and because PHP and Microsoft recommend FastCGI on Windows Servers?

When running a MODx site the FastCGI Module on our server throws the following error:



On a none MODx site the trigger appears to be MySQL interactions, somewhere between connecting to, querying and closing a database connection, possibly while executing mysql_close(). However, since MODx uses PDO I wonder if this is not the actual trigger for the error. Websites set to use FastCGI will respond to basic commands like phpinfo(); and echo ’something’;.

Further details from Event Viewer are:
Faulting application path: C:\Program Files (x86)\Parallels\Plesk\Additional\PleskPHP5\php-cgi.exe
Faulting module path: C:\Program Files (x86)\Parallels\Plesk\Additional\PleskPHP5\php5ts.dll

Does anyone have any experience running Plesk on a Windows Server with MODx successfully on PHP5 via FastCGI? The engineers at our data centre are suggesting that Plesk may not be capable of running this setup but I don’t see how since it ships with this option available.

I know this covers a lot if issues but if anyone can comment it would be appreciated.

Thanks,

Chris

Update: I looked back through my email history and according to correspondence with the engineers at the data centre the PHP5 FastCGI issue first presented one day after MySQL was updated from 5.0.45 to 5.1.51.

Coincidence? Or does it sound like the first thing we should do should be to roll back to the original version of MySQL seeing as the minimum MODx requirement is MySQL 4.1.20 or higher (excludes 5.0.51)?

- Sites using MODx Revolution, various versions from 2.0.4-pl2 to 2.1.1-pl

This issue has changed in the past week and is now limited to only two sites running:
- 2.0.5-pl (traditional)
- 2.0.4-pl2

It used to take out all sites running MODx so I thought it may be a bug/conflict between a particular version and our server setup. However, there are two sites running 2.0.4-pl2, one goes down, the other doesn’t. Plus there’s the one on 2.0.5-pl (traditional) that goes down.

I did find that the Manager area remains working when the frontend goes down so I tried clearing the Site Cache when the PHP Access Violation error displays but this doesn’t resolve the frontend issue.

Does this prompt any thoughts from anyone?

This is mostly just a note to myself since nobody has responded yet.

I moved the site running 2.0.4-pl2 into a dedicated application pool in IIS. Next time the site running 2.0.5-pl (traditional) went down it didn’t take the other site with it.

I’ve moved the 2.0.5-pl (traditional) site into it’s own application pool now as well and we’ll see if it gets the PHP Access Violation error again.

I have a Revo site in its own Application Pool and still continue to get this Access Violation error. I got the same error when hosting a Drupal site. No other PHP applictions/websites (Zend, Wordpress, Bistro cms) get this error.

Just an expression of solidarity. I am having the same problem with a website built in MODX Revolution 2.1.5 installed on a server running IIS. Occasional (not every) clicks to save work in the manager error seem to trigger the error, which appears as "PHP has encountered an Access Violation at 01AFADD9". The people handling the server inform me that they also see lots of error messages like the following: "PHP Fatal error: Cannot redeclare class modX in distinctiveportugal\accommodation\core\model\modx\modx.class.php on line 2101".

Quote from: cottagestuff at Dec 28, 2011, 10:01 AM

Just an expression of solidarity. I am having the same problem with a website built in MODX Revolution 2.1.5 installed on a server running IIS. Occasional (not every) clicks to save work in the manager error seem to trigger the error, which appears as "PHP has encountered an Access Violation at 01AFADD9". The people handling the server inform me that they also see lots of error messages like the following: "PHP Fatal error: Cannot redeclare class modX in distinctiveportugal\accommodation\core\model\modx\modx.class.php on line 2101".

That error is non-sensical as far as I can tell. Can we start with some details here? Are we running IIS7.5? I assume this is using FastCGI and that the appropriate PDO drivers are installed and up-to-date? Have you tried logging the FastCGI errors?

Also I have to assume this is IIS 7.5 with MySQL (a version on MySQL server and clients being used might be relevant) since no one here has indicated otherwise.

I am not in direct communication with the people responsible for the servers, but by running a check on domaintools I gather the server is running IIS/6.0.

I have access to a PHPAdmin interface, which flags up the following warning:

Your PHP MySQL library version 5.0.45 differs from your MySQL server version 4.1.22. This may cause unpredictable behavior.

I am wating for an answer from the server people (in Portugal) about Fast CGI, etc.

Thanks for getting back to me.

Just to fill in some of the details:

The version of IIS is 6.0.

There is no Fast CGI on this server.

The errors all refer to a problem redeclaring class modX. E.g. PHP Fatal error: Cannot redeclare class modX in ...\distinctiveportugal\accommodation\core\model\modx\modx.class.php on line 2122

The servers are using PDO drivers from PHP 5.2.13

Regarding the access violation problem: Here are some details from phpInfo:

PHP Version 5.2.13

MySQL Client API version 5.0.45

MySQLI Client API library version 5.0.45

MySQLI Client API header version 5.0.51a

PDO drivers mysql, odbc

PDO Driver for MySQL, client library version 5.0.45

ODBC Connection Pooling Enabled, strict matching