What do you mean by "recycled"? A new request coming in? MSHUTDOWN is only called when the PHP process terminates. RSHUTDOWN is the one being called after each request at request shutdown.

I mean when php-cgi.exe terminates MSHUTDOWN is not being called. This happen when running in FastCGI mode under IIS.

Are you talking about the parent or childs? (And I can not reproduce this on linux, shutdown for every extension is definately called..)

I don't understand the question about parent and child. It is simply the PHP_MSHUTDOWN_FUNCTION not being called (in FastCGI in IIS).

You cannot duplicate it in linux because it does not happen in linux. The bug never mention linux.

The problem is when using PHP in FastCGI mode using IIS (in Vista, not linux)

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

5.2.10 (April 21) has the same problem.

Have the same problem in PHP5.3.0

Will verify this issue once I'm back from vacation.

It is called as expected (tested on vista/iis and in the console).

If you still experiece this problem, then please provide a detailed way to reproduce:
- what are you doing exactly in IIS
- values of PHP_FCGI_MAX_REQUESTS and instanceMaxRequests (IIS setting)

To answer the question, the values of PHP_FCGI_MAX_REQUESTS and instanceMaxRequests ar eboth 10000. But they do not come into play to duplicate this problem. The problem could be duplicated before number of request reach these numbers.

I will try to explain the detail using just the standard extension (php_date).

1. Setup PHP FactCGI in IIS. Everything default.
2. Try to run a test.php with this code     <?phpinfo();?>
3. Attach the debugger to php_cgi.exe and make sure it loaded the debug symbol of php_date.
4. Put a break point in PHP_MSHUTDOWN_FUNCTION inside php_date.c
5. Go to IIS Manager, Application Pools. Select DefaultAppPool and click "Recycle..." on the right hand pane.
6. Notice that the php_cgi.exe will exit but your breakpoint in php_date.c is not triggered.

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

More information.

Using the latest FastCGI update on IIS7 (KB980363) which support 
SignalBeforeTerminateSeconds, PHP_MSHUTDOWN_FUNCTION is still not being called.

Look into the code in sapi/cgi/fastcgi.c
A thread fcgi_shutdown_thread has been created to trap the "_FCGI_SHUTDOWN_EVENT_" 
event but the code simply set in_shutdown to 1. After that, PHP_MSHUTDOWN_FUNCTION 
in the extension code is still not being called.

I cannot re-open the bug.
There are more info on handling of SignalBeforeTerminateSeconds

Please refer to http://forums.iis.net/t/1167753.aspx

Please post the relevant information here ( > feedback again).

Using Vista64 IIS7 with the update (KB980363).

1. Setup PHP FactCGI in IIS. Everything default.

2. Open C:\Windows\System32\inetsrv\config\applicationHost.config
Edit the <fastCgi> section and add signalBeforeTerminateSeconds="30"

<fastCgi>
            <application fullPath="C:\Program Files (x86)\PHP\php-cgi.exe" maxInstances="2" idleTimeout="30001" activityTimeout="3000" instanceMaxRequests="10000" signalBeforeTerminateSeconds="30">
                <environmentVariables>
                    <environmentVariable name="PHP_FCGI_MAX_REQUESTS" value="10000" />
                    <environmentVariable name="PHPRC" value="C:\Program Files (x86)\PHP\" />
                </environmentVariables>
            </application>
</fastCgi>

3. Create a test.php with <?phpinfo();?>. Browse it.
4. Attach debugger to php-cgi.exe process (with debug symbol).
5. Put a breakpoint in sapi/cgi/fastcgi.c (after WaitForSingleObject)
static DWORD WINAPI fcgi_shutdown_thread(LPVOID arg)
{
	HANDLE shutdown_event = (HANDLE) arg;
	WaitForSingleObject(shutdown_event, INFINITE);
	in_shutdown = 1; <--------------breakpoint here
	return 0;
}
6. Put a break point in ext/date/php_date.c
PHP_MSHUTDOWN_FUNCTION(date)
{
	UNREGISTER_INI_ENTRIES();

	return SUCCESS; <----------------breakpoint here
}
7. Open a command prompt and do a iisreset.

Notice that the breakpoint in fcgi_shutdown_thread will get hit but the PHP_MSHUTDOWN_FUNCTION(date) function is not being called.


Before the IIS updates, FastCGI module always force kill php-cgi.exe, make it impossible for php-cgi.exe to properly call PHP_MSHUTDOWN_FUNCTION for each extension. 
With the new setting signalBeforeTerminateSeconds, "_FCGI_SHUTDOWN_EVENT_" will be triggered to give php-cgi.exe a change to do proper cleanup. There are actually code in fastcgi.c (PHP) to wait for that event. However, it still does not properly call PHP_MSHUTDOWN_FUNCTION for all the loaded extension.

See also bug #51760.

I cannot reproduce the reported behavior.  If you still experience
this issue, please re-open.

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.