|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #53140 PHP-CGI (FastCGI IIS) crashes when creating DOTNET instance every second time
Submitted: 2010-10-22 15:59 UTC Modified: 2020-07-05 04:22 UTC
Avg. Score:4.7 ± 0.7
Reproduced:50 of 50 (100.0%)
Same Version:22 (44.0%)
Same OS:40 (80.0%)
From: jeyb88 at gmail dot com Assigned: cmb (profile)
Status: No Feedback Package: COM related
PHP Version: 5.3.3 OS: XP, Vista, Win 7,Win Server 2008
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
Solve the problem:
17 - 2 = ?
Subscribe to this entry?

 [2010-10-22 15:59 UTC] jeyb88 at gmail dot com
The php-cgi.exe will crash after every second refresh when I make an instance of the DOTNET class. The Website is hostet via IIS 7 and PHP is configured as FastCGI module. When I configure PHP on IIS as CGI module everything works fine, but I can not do without FastCGI. I have made a change in the com_dotnet.c file in function php_com_dotnet_rshutdown. The variable called stuff from type dotnet_runtime_stuff will not be released like in the function php_com_dotnet_mshutdown. So I have added this two lines to the function php_com_dotnet_rshutdown:

COMG(dotnet_runtime_stuff) = NULL;

After that I have compiled PHP 5.3.3 with Visual Studio 2008 (VC9) x86 with almost the same configuration like in the PHP 5.3.3 nts version but without zlib:

configure "--enable-snapshot-build" "--enable-debug-pack" "--disable-zts" "--disable-isapi" "--disable-nsapi" "--without-mssql" "--without-pdo-mssql" "--without-pi3web" "--with-pdo-oci" "--with-oci8" "--with-oci8-11g" "--with-enchant=shared" "--enable-object-out-dir=../obj/" "--enable-com-dotnet" "--with-mcrypt=static" "--disable-zlib"

The include and lib files are relative to the configuration file (in the deps folder). I have earned following error and that's why I have disabled zlib:

php5.dll.def : error LNK2001: unresolved external symbol compressBound
php5.dll.def : error LNK2001: unresolved external symbol deflateBound
php5.dll.def : error LNK2001: unresolved external symbol deflatePrime
php5.dll.def : error LNK2001: unresolved external symbol gzclearerr
php5.dll.def : error LNK2001: unresolved external symbol gzungetc
php5.dll.def : error LNK2001: unresolved external symbol inflateBack
php5.dll.def : error LNK2001: unresolved external symbol inflateBackEnd
php5.dll.def : error LNK2001: unresolved external symbol inflateBackInit_
php5.dll.def : error LNK2001: unresolved external symbol inflateCopy
php5.dll.def : error LNK2001: unresolved external symbol zlibCompileFlags

The error in the com_dotnet.c file was the error, because now with the new compiled version, fastcgi will not be terminated. Is the zlib extension necessary for complex php websites like Joomla? Because now the compiled php version can interpret the sample shown below and it can interpret simple php scripts, but when I try to load a Joomla site, the FastCGI will crash. What is wrong with the made configuration? Can you give me an important hint of how to compile php5.3.3 like in the original php version?

Best regards, JeyB

Test script:
		$stack = new DOTNET("mscorlib", "System.Collections.Stack");
 		$stack->Push("Hello ");
 		echo $stack->Pop() . $stack->Pop();
	catch(Exception $lEx)
		echo "Error occurred:<br>".$lEx->getMessage();


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2010-11-16 23:40 UTC] davidphp at limegreensocks dot com
It appears this behavior was intentionally introduced by WEZ back in 2003.

I don't know what problem he was trying to fix back then, so I'm not sure of the implications of adding these two lines back.  But if you are using fastcgi, then jeyb88 is absolutely correct: this will crash every other time the code is run.  

My repro is even simpler than jeyb88's.  I don't even have to call any methods on the .net object.  I have a 1 line php file that calls the "new" against my .net class:


  $class1 = new DOTNET("moo, Version=, Culture=neutral, PublicKeyToken=14ba337483520f7a", "moo.Impersonation");

The constructor for my .net class is empty:

    public class Impersonation
        public Impersonation()
    // more code follows

When I first browse to the page, it (correctly) shows nothing.  Then I hit refresh, and I get the "FastCGI process exited unexpectedly" 0xc0000005.  If I hit refresh again, the page again (correctly) shows nothing, next time, fastcgi AVs again.

I am using php 5.3.3, Windows Server 2003, and I have tried both .Net 2.0 and .Net 3.5.

The pattern here is easily reproducible, causes an unrecoverable access violation, and there is no workaround.  A fix here would be greatly appreciated.
 [2011-08-24 16:18 UTC] johnphayes at gmail dot com
This error only appears to happen when the offending code is run from a web 
server. If I run the offending code directly from the CLI, php never crashes. If 
I run the same code through Apache (via a cURL request), Apache crashes every 
other time. My configuration is:

* Windows Server 2003 R2
* Apache 2.2
* PHP 5.3 configured as an Apache handler, not under FastCGI (see
* The following 2 files:


// testCrash.php - file #1
$stack = new DOTNET("mscorlib", "System.Collections.Stack");
echo "success";


// testCrashClient.php - file #2
$endPoint = 'http://localhost/testCrash.php';

$client = curl_init();
curl_setopt_array($client, array(
		CURLOPT_URL => $endPoint
$response = curl_exec($client);

echo 'done';


Use case #1 - run locally, we get no crash:
1. Open command prompt
2. Execute:
   php.exe testCrash.php
3. Observe that we get the expected resulting output: 
4. Repeat step 2. Expected result will always be obtained.

Use case #2 - run through the web server, we get the crash:
1. Open command prompt
2. Execute:
   php.exe testCrashClient.php
3. Observe that we get the expected resulting output:
   string(7) "success"
4. Repeat step 2.
5. Now observe that we get an error:
6. Repeat step 2.
7. Expected successful output is obtained again.

Repeating step 2 will cause the crash every other time. When the crash occurs, 
apache's error log gets:

[Wed Aug 24 12:13:25 2011] [notice] Parent: child process exited with status 0 -
- Restarting.
[Wed Aug 24 12:13:25 2011] [notice] Apache/2.2.19 (Win32) PHP/5.2.17 configured 
-- resuming normal operations
[Wed Aug 24 12:13:25 2011] [notice] Server built: May 20 2011 17:39:35
[Wed Aug 24 12:13:25 2011] [notice] Parent: Created child process 2624
[Wed Aug 24 12:13:26 2011] [notice] Child 2624: Child process is running
[Wed Aug 24 12:13:26 2011] [notice] Child 2624: Acquired the start mutex.
[Wed Aug 24 12:13:26 2011] [notice] Child 2624: Starting 64 worker threads.
[Wed Aug 24 12:13:26 2011] [notice] Child 2624: Starting thread to listen on 
port 80.
 [2011-08-24 16:23 UTC] johnphayes at gmail dot com
Can this bug's summary be edited to remove "(FastCGI IIS)?" My comment above shows 
that it can be reproduced under Apache as an Apache handler as well.
 [2011-08-24 17:02 UTC] johnphayes at gmail dot com
Here is the Application Event log entry in Windows Server 2003 when this crash 
occurs in my test case above:

Source: .NET Runtime 2.0 Error

Faulting application httpd.exe, version, stamp 4dd6eda8, faulting 
php5ts.dll, version, stamp 4d25fb49, debug? 0, fault address 

This source is a little odd, because I have .NET 4.0 Runtime installed. Note 
that although I have PHP 5.2.17 installed at the moment, I have experienced this 
with 5.3 as well.
 [2012-03-26 16:18 UTC] andrew dot king at simail dot co dot uk
I can confirm that this problem also exists on PHP 5.3.2 on Windows Server 2003 32-bit with IIS running FastCGI. Problem also occurs on WAMP server, Windows 7 64-bit running PHP 5.3.8, Apache 2.2.21 with PHP loaded as a module, not CGI.
 [2013-01-08 09:35 UTC] xandra_18ro at yahoo dot com
Is there a hotfix for this problem? Or a workaround perhaps.
 [2013-01-08 15:08 UTC] johnphayes at gmail dot com
You may be able to fix this issue by recompiling PHP with the 

void php_com_dotnet_mshutdown()

defined in /ext/com_dotnet/com_dotnet.c. IIRC the problem was that that function 
was removed in this revision:

So if you can download the latest source, put that function back into 
com_dotnet.c, and recompile you should be good to go.
 [2013-03-19 15:34 UTC] ben at imperialwebdesigns dot com
Any update on getting this resolved?
 [2013-10-18 05:23 UTC] igorhmm at gmail dot com

I found a poor workaround: on IIS7 I've fixed just one request to recycle

I did this on specific application pool that uses this feature.

Hope this helps :)

 [2013-12-01 20:11 UTC] jzdd at o2 dot pl
This issue still exists on PHP 5.5.6 run on Windows Server 2012/R2 and IIS 7/8.

It makes php_com_dot_net USELESS for production, why can't you fix this?????
 [2015-10-30 11:49 UTC] nicholas dot owens at Seiko dot co dot uk
I have also experienced this.

I am trying to use the WinSCP .net object.

I am using PHP 5.3 on Windows 2008R2, it crashes exactly every other time.

I avoided the problem by using COM instead of DOTNET.
It is my understanding that any .NET to be used from PHP must be registered in COM anyway so would this always work?
 [2018-01-22 18:58 UTC] rodman dot tim at gmail dot com
I also had this issue. My PHP script failed every other time I executed it on FastCGI IIS. I was able to get around the problem by setting ".NET CLR version" to  "No Managed Code" in the Application Pool like this:
 [2020-06-25 14:57 UTC]
-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb
 [2020-06-25 14:57 UTC]
I cannot reproduce the crash with PHP 7.3. Can anybody else
reproduce it with any of the actively supported PHP versions[1]?

[1] <>
 [2020-07-05 04:22 UTC] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Sun May 29 09:05:45 2022 UTC