It appears this behavior was intentionally introduced by WEZ back in 2003.  

http://svn.php.net/viewvc/php/php-src/trunk/ext/com_dotnet/com_dotnet.c?r1=137794&r2=146718

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:

<?php

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

The constructor for my .net class is empty:

    [ComVisible(true),
    ClassInterface(ClassInterfaceType.None),
    Guid("53C74B01-EC09-45a4-A741-42727858B2A1")]
    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.

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 
http://www.php.net/manual/en/install.windows.apache2.php)
* The following 2 files:

----------

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

----------

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

$client = curl_init();
curl_setopt_array($client, array(
		CURLOPT_FRESH_CONNECT => TRUE,
		CURLOPT_RETURNTRANSFER => TRUE,
		CURLOPT_URL => $endPoint
	));
$response = curl_exec($client);
curl_close($client);
var_dump($response);

echo 'done';
?>

----------

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

Use case #2 - run through the web server, we get the crash:
Steps:
1. Open command prompt
2. Execute:
   php.exe testCrashClient.php
3. Observe that we get the expected resulting output:
   string(7) "success"
   done
4. Repeat step 2.
5. Now observe that we get an error:
   bool(false)
   done
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.
----------

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.

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

Description:
Faulting application httpd.exe, version 2.2.19.0, stamp 4dd6eda8, faulting 
module 
php5ts.dll, version 5.2.17.17, stamp 4d25fb49, debug? 0, fault address 
0x000ea66d.

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.

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.

Is there a hotfix for this problem? Or a workaround perhaps.
thanks!

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: 

http://svn.php.net/viewvc/php/php-src/trunk/ext/com_dotnet/com_dotnet.c?
r1=137794&r2=146718. 

So if you can download the latest source, put that function back into 
com_dotnet.c, and recompile you should be good to go.

Any update on getting this resolved?

Guys,

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 :)

Regards

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?????

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?

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: https://i.imgur.com/PzWPClD.png

I cannot reproduce the crash with PHP 7.3. Can anybody else
reproduce it with any of the actively supported PHP versions[1]?

[1] <https://www.php.net/supported-versions.php>

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.