php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #44047 IIS Worker Process stopped working
Submitted: 2008-02-04 23:42 UTC Modified: 2008-04-09 18:52 UTC
Votes:11
Avg. Score:4.0 ± 0.6
Reproduced:11 of 11 (100.0%)
Same Version:9 (81.8%)
Same OS:9 (81.8%)
From: matthew dot horner at redprairie dot com Assigned:
Status: Not a bug Package: IIS related
PHP Version: 5.2.5 OS: Windows Vista
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: matthew dot horner at redprairie dot com
New email:
PHP Version: OS:

 

 [2008-02-04 23:42 UTC] matthew dot horner at redprairie dot com
Description:
------------
I am able to reproduce this issue as others have seen reported in other bug reports with no solution.  If you simply
run the following script, the error should reproduce itself.

I have done several different tests using IIS7 and have concluded that
there are no issues with PHP4 but 5.1.6 and 5.2.5 both cause the crash. 
I am using Vista Businesss and confirmed with several other developers
in our organization the same issues with IIS7 on Vista.  Those reporting
this issue to our group reported that the problem was also seen but not
limited to 5.2.3.

I have slightly altered my configuration of IIS to accelerate the crash.
 Using the IIS Manager, I clicked Application Pools, selected
DefaultAppPool and clicked Advanced Settings.  In settings configuration
screen, I changed the Idle Timeout (minutes) under Process Model to 1. 
Do an iisreset, execute the example script above in the brower and wait.
 Within one minute you should see a message stating the 'IIS Worker
Process has stopped working.'

I downloaded the DebugDiag tool from
http://www.microsoft.com/downloads/details.aspx?FamilyID=28bd5941-c458-4
6f1-b24d-f60151d875a3&DisplayLang=en

If you would like the complete log of the crash as reported by the DebugDiag
tool, I would be more than happy to pass it along.  If any assistance is
required, please feel free to contact me and I will do everything I
can.

Thanks,
Matt

Reproduce code:
---------------
<?php

phpinfo();

?>

Expected result:
----------------
The phpinfo page, shows as expected.  However, after the Idle Timeout specified in IIS has been reached, a crash message is displayed.  Expect this message not be display after the offending code is fixed.

Actual result:
--------------
The crash results in the following:
---------------------------------------------------
In w3wp__PID__4852__Date__02_02_2008__Time_09_57_40AM__660__First chance
exception 0XC0000374.dmp the assembly instruction at
ntdll!RtlReportCriticalFailure+5b in C:\Windows\System32\ntdll.dll from
Microsoft Corporation has caused an unknown exception (0xc0000374) on
thread 11

From the DebugDiag tool, I have gathered a stack trace which identifies
that faulting dll, php5ts.dll.
--------------------------------------------------------------
Function     Arg 1     Arg 2     Arg 3   Source 
ntdll!RtlReportCriticalFailure+5b     c0000374     77d1cf50     01c1f838
   
ntdll!RtlpReportHeapFailure+21     00000002     01c1a15c     00000000   

ntdll!RtlpLogHeapFailure+a1     00000008     00110000     037d7148    
ntdll!RtlFreeHeap+60     00110000     00000000     037d7150    
kernel32!HeapFree+14     00110000     00000000     037d7150    
msvcrt!free+cd     037d7150     0143aa70     0313978a    
php5ts!zend_hash_graceful_reverse_destroy+2e     10000000     00000000  
  00000000    
ntdll!LdrpCallInitRoutine+14     1000263d     10000000     00000000    
ntdll!LdrpUnloadDll+3ba     10000000     01c1fa28     01c1a32c    
ntdll!LdrUnloadDll+46     10000000     027fffe4     01c1fa7c    
kernel32!FreeLibrary+15     10000000     00000000     009b07c8    
isapi!ISAPI_DLL::Unload+38     009b07c8     696aa82d     009b07c8    
isapi!ISAPI_DLL::~ISAPI_DLL+10     009b07c8     01c1fa94     696aa93f   

isapi!ISAPI_DLL::`scalar deleting destructor'+d     00000001    
027fffc4     00f56578    
isapi!ISAPI_DLL::DereferenceIsapiDll+37     01c1fac0     732a6bdc    
009b07c8    
isapi!ISAPI_DLL_HASH::AddRefRecord+23     009b07c8     ffffffff    
00f56590    
iisutil!CLKRLinearHashTable::_Clear+6f     00000000     00000003    
00f56578    
iisutil!CLKRLinearHashTable::~CLKRLinearHashTable+19     0011d898    
01c1fae8     732a6e75    
iisutil!CLKRLinearHashTable::`scalar deleting destructor'+d     00000001
    01c1fb04     732a6fe4    
iisutil!CLKRHashTable::_FreeSubTable+13     00f56578     01413938    
0011d898    
iisutil!CLKRHashTable::~CLKRHashTable+18     014052b0     01c1fb28    
696aaee6    
isapi!W3_RESTRICTION_LIST::`scalar deleting destructor'+e     00000001  
  696ab318     01437a90    
isapi!TerminateIsapiModule+16     01437a90     72798822     01437a90   

isapi!CIISModuleFactory::Terminate+14     01437a90     727988a6    
01437a90    
iiscore!VIRTUAL_MODULE::~VIRTUAL_MODULE+3e     01437a90     01c1fb70    
72797755    
iiscore!VIRTUAL_MODULE::`vector deleting destructor'+d     00000001    
0000000e     727988e0    
iiscore!VIRTUAL_MODULE::DereferenceVirtualModule+20     00000000    
732a6cb0     01413758    
iiscore!MODULE_LIST::FreeModules+21     01413bdc     01413758    
7279a798    
iiscore!W3_SERVER::TerminateGlobalModules+49     013f01fc     013f021c  
  013f01fc    
iiscore!W3_SERVER::Terminate+120     01385578     727945c8     01c1fb90 
  
iiscore!IISCORE_PROTOCOL_MANAGER::StopListenerChannel+58     01385584   
 01385578     00000000    
w3wphost!LISTENER_CHANNEL::HandleStopListenerChannel+65     00000000    
03778b48     73e83e43    
w3wphost!LISTENER_CHANNEL_STOP_WORKITEM::ExecuteWorkItem+10     013eedd8
    01c1fbd8     73ea2567    
w3wphost!W3WP_HOST::ExecuteWorkItem+13     00000000     00000000    
03778b58    
w3tp!THREAD_POOL_DATA::ThreadPoolThread+73     00000000     01385680    
73ea0000    
w3tp!THREAD_POOL_DATA::ThreadPoolThread+24     013eedd8     00000000    
00000000    
w3tp!THREAD_MANAGER::ThreadManagerThread+39     01385680     01c1fc50   
 77c8a9bd    
kernel32!BaseThreadInitThunk+e     01385680     01c1a534     00000000   

ntdll!_RtlUserThreadStart+23     73ea1e3c     01385680     00000000    

Additionally, a section of this log shows a lock being held.  Not sure how relevant this is to the actual issue.
--------------------------------------------------------------
Locked critical section report
Critical Section    ntdll!LdrpLoaderLock  
Lock State   Locked 
Lock Count   1 
Recursion Count   1 
Entry Count   0 
Contention Count   6 
Spin Count   0 
Owner Thread   11 
Owner Thread System ID   3192 



Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-02-05 14:17 UTC] matthew dot horner at redprairie dot com
I have tested with the latest and the crash is still occurring with the exact same stack trace.  The build date of the current installation is Feb 5 2008 08:04:21.
 [2008-02-05 15:01 UTC] scottmac@php.net
Do you have any extensions loaded via php.ini or this is purely whats statically built into PHP?

If you do have extensions can you disable them all and see if you can reproduce the problem.
 [2008-02-05 16:17 UTC] matthew dot horner at redprairie dot com
I removed all extensions and re-tested with the same results.
 [2008-02-29 04:37 UTC] nonya at spam dot this
To elaborate on Matthew, (Every PHP5\Vista\IIS7 machine I have every worked on does this; 20+ machines)

The same error can be achieved back-to-back simply by running any PHP, which in turn will add 1 active application to the DefaultAppPool.  This is visible in the IIS7 Manager.  You can select the DefaultAppPool and click "Recycle...", wait 3-5 secs (because WerFault.exe kicks in, Windows Error Reporting Service) and you have a "IIS Worker Process has failed" message with the event in the windows event log the way Matt described which says the fault came from c:\windows\system32\ntdll.dll

If the PHP dev guys are trying to recreate this issue, you need to be using Latest PHP5/IIS7/ISAPI-Configuration/Vista

This has been going on since Vista RC1.  Everyone who is not getting this error may not be complaining because the error doesn't seem to do major damage.

The closest thing to a resolution I have seen since the release of Vista is to just adjust the timing of the automated recycle cycle.  Since the error is only occurring during recycling, they have been scheduling 1 recycle per day, hence 1 crash per day.

There are many, many, many, MANY forums and support threads with people having the same problem, they just aren't posting here.
Here are a few:
forums.techarena.in/showthread.php?t=686723
www.developersdex.com/asp/message.asp?p=592&r=6057007
www.issociate.de/board/post/468636/IIS_+_PHP_--_Worker_Process_alert_&_w3wp.exe_crash?.html
forums.techarena.in/showthread.php?t=821723
groups.google.com/group/comp.lang.php/browse_thread/thread/93aef1ff2f0ba3b0
www.thescripts.com/forum/thread742344.html
 [2008-03-02 12:27 UTC] satan at dclxvi dot nl
lol, your test is the solution... where you set it idle time out to 1 to test it earlier, just set it to '0'. it will error out once more and the next time it starts it will stay on.. there is no problem with leaving it on..
 [2008-03-03 13:52 UTC] matthew dot horner at redprairie dot com
Setting the recycle time to 0 would not be considered a solution, but rather a workaround.  The solution to the problem would require a code change.  That change would resolve the issue, so that the workaround would not have to be applied.  This change to standard code would also avoid changing standard configuration of the IIS server for _every_ instance that has a PHP 5 installation.
 [2008-03-04 00:57 UTC] nonya at spam dot this
Yea, that is a horrible idea.  You are literally telling IIS to never clean it's caches or do garbage collection on the AppPools.  I am sure that there are more critical consequences on high-volume web servers if you decide to do this.

PHP just fix it
 [2008-03-04 15:25 UTC] nick at databasedevelopments dot com
Same issue here on Vista Ultimate and PHP5.2.5 with IIS7
 [2008-03-06 09:39 UTC] satan at dclxvi dot nl
it will still recycle if you set it to 0, it just won't time out.. on higher traffic servers it will will never timeout and there's no problem there, is there? the recycling is another setting..

besides, this has little or nothing to do with php, as it also occurs after running asp..
 [2008-03-06 10:13 UTC] satan at dclxvi dot nl
Also, I found out the solution that it won't error on recycle...

go to the advanced settings of the appPool you are using and set "Disable Overlapped Recycle" to "True". 

PHP5 can't seam to run multiple instances so it errors out when it starts a new instance before it recycles the old..

And again with the idle timeout set to "0", it will still recycle..
 [2008-03-06 10:36 UTC] satan at dclxvi dot nl
to be clear, these are my settings:

Recycle time is set to the default every 1740 minutes.
Idle timeout is set to '0'
Disable Overlapped Recycle is set to 'True'

never had the error again...
no horrible workarround whatsoever.. it's just that IIS7 is defaultly configured to run MS stuff like ASP.NET etc..
 [2008-03-06 14:00 UTC] matthew dot horner at redprairie dot com
I would still consider this a workaround, as this is not standard procedure for installing ISAPI modules in IIS7.  Furthermore, this issue is not an issue with PHP 4.  Which to me, would indicate there is something coded differently with PHP 5 to cause the crash when recycling the process.  Also, reconfiguring the Application Pool, affects more than just your pool hosting PHP driven applications.  What side effects  there are, is unclear to me, but certainly not something I would like to find out about once a site is in production.

I posted this bug because I would like to have the PHP developers debug this issue and determine if there is indeed a code problem or a problem with IIS7.  Not to have a workaround to avoid crashes on IIS7.

I am not disputing the fact that your solution works.  However, this appears to be an issue and should be addressed at the PHP level first.  

Thank you for your suggestions.
 [2008-03-19 04:22 UTC] jaedsm at hotmail dot com
Having the same issue here too. Installed IIS7 and PHP 5.2.5 the other day on my home system running Vista Home Premium. Didn't consider it would have been caused by some timeout but after reading here that makes sense.

No crash message has appeared while I've been working for hours on end, once I stop though it appears a little while later and doesn't appear again unless I load another php page.
 [2008-04-03 20:20 UTC] nonya at spam dot this
I see this topic has been labeled an IIS issue and there was no response from PHP staff.

If it is a IIS7 issue, why was it not occurring in PHP4?
 [2008-04-07 18:21 UTC] matthew dot horner at redprairie dot com
Thank you for your observation.  I am not sure if I had originally set it this way or not, but I have changed the category to hopefully represent the issue better. Maybe this will get noticed by someone who will engage the issue and provide a fix.
 [2008-04-08 11:02 UTC] jani@php.net
We are aware of PHP's problems with stability under IIS and are working 
to rectify the problem. Unfortunatly your bug report does not contain any
extra useful information and we already have enough bug reports open about
this issue. If you can provide more detailed information such as a 
reproducable crash or a backtrace please do so and reopen this bug. 
Otherwise please keep trying new releases as we are working to resolve 
the problems on this platform
 
Thanks for your interest in PHP.

It's safest to use FastCGI. Even IIS supports it nowadays..
 [2008-04-09 18:52 UTC] matthew dot horner at redprairie dot com
Am I missing something here?  I posted code to reproduce the crash as well as back trace.  I initially open the report with that information.  At which time, you and one other developer suggested taking the latest snapshot and removing all extensions.  Didn't appear to be bogus at that time.

Was moving the report to a reproducible crash the reason you decided to call this a bogus issue?  I can reproduce a crash with the most basic PHP script.  As nonya and I have found, this issue is not specific to IIS but the IIS and PHP 5.1/5.2 code branches.

I opened this report 2 months ago and haven't seen any progress.  If you are addressing this issue on another report, then can you please provide the bug #?  I understand that I am reporting this issue with Windows Vista/IIS 7.  Windows Server 2008 has been released and deploying IIS 7.  I can only figure this is going to become a much larger issue in the coming months.

FastCGI is an option, but is not the only option.  Apache is also an option, but I can't force all implementations to require Apache.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 14:01:29 2024 UTC