Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows (zip):
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip

For Windows (installer):

  http://snaps.php.net/win32/php5.2-win32-installer-latest.msi

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.

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.

I removed all extensions and re-tested with the same results.

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

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

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.

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

Same issue here on Vista Ultimate and PHP5.2.5 with IIS7

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

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

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

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.

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.

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?

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.

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

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.