Please try using this CVS snapshot:

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

Please try _official_ snapshots.

I've tried with php5.1-200603252330.tar.gz, but unfortunately no positive effect.

Debug Diagnostic Tool also gives the same result.

I'm using Microsoft Visual C++ 6.0 to build PHP.
The configure command I used is:
cscript /nologo configure.js --enable-isapi --enable-cli-win32 --with-config-file-scan-dir=c:\php5 --with-mysqli --with-mysql --enable-pdo --with-pdo-mysql

Any more actions I can take to provide you with more information on this?

And what do you mean with 'official' in:

Please try _official_ snapshots.

I mean grab the binaries, not the sources and try them please.

Try changing the identity of the application pool from NETWORK SERVEICE to IWAM_[SERVERNAME]. From the IIS console, right-click on the AppPool --> Properties --> Identity tab.

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

Applies to all W2K3 versions after SP1 with DEP.
My Installation is W2K3-R2 64bit -- 

The problem described is in the order in which the extensions are loading from the ini file. IIS fails to register the out of order dll. When a dependency is run agains the unregistered dll, windows DEP sees it as a threat and shuts down the worker process. Pretty sweet actually.

The immediate solution is to comment out all of the extensions in your ini file and then one at a time, (very important), uncomment them and do a full reboot. DEP needs to be restarted clean so an IIS restart is not enough.

When the offending extension causes the fault, cut and paste it one level above the last uncommented extension. You're probably going to do this several times before you get it right but eventually you will hit the sweet spot. The key is not to load extension you don't need.  

If this were any other vendors product I would find something better but the fact is that the product is so good that its worth the extra work to get it up and running.

Note: You might be able to, (in fact you can), get away with just turning off DEP to get rid of the surface level problem but that would not solve the real problem.

Deeper investigation of the problem indicates that the reason you are now getting this is because of .NET 2.0. In verison 1.0 and 1.1 it did not throw this exception because it was set to ignore it. If you don't have any security issues, you could probably just ignore them and be O.K. That would not be my choice.

The solution is to recompile the DLL's (all of them) with Visual Studio 8. This will then correctly place them within the scope of the IIS authorized extension list. 

Workaround, back level your server to .NET 1.0 and do not apply any of the security patches. Once done, test and then start applying the security patches. Test each one don't just download them all install them.  

In a previous post my suggestion of proper ordering does work but it is exremely tedious and not something you want to endure everytime you add or remove functionality.

These are related issues that seem to be describing the same problem:
Bug #33373 IIS worker Process continually restarts
Bug #37575 Faulting application w3wp.exe
Bug #35263 Crash during IIS Restart

Adding the w3wp.exe process to the DEP exception list will also mask the problem.

Windows 2003 Server, IIS6, .NET 1.1 & .NET 2.0, php5.2-win32-200607120630 from the snapshots. (Fully Microsoft patched Windows 2003 server machine).

Even with all PHP dynamic extensions turned off, crash occurs during IISreset or w3svc service restart.

Event as it appears in event log:

Event Type:	Error
Event Source:	Application Error
Event Category:	(100)
Event ID:	1000
Date:		07/12/2006
Time:		06:26:45
User:		N/A
Computer:	COMPUTER-NAME
Description:
Faulting application w3wp.exe, version 6.0.3790.1830, faulting module unknown, version 0.0.0.0, fault address 0x01bba980.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 41 70 70 6c 69 63 61 74   Applicat
0008: 69 6f 6e 20 46 61 69 6c   ion Fail
0010: 75 72 65 20 20 77 33 77   ure  w3w
0018: 70 2e 65 78 65 20 36 2e   p.exe 6.
0020: 30 2e 33 37 39 30 2e 31   0.3790.1
0028: 38 33 30 20 69 6e 20 75   830 in u
0030: 6e 6b 6e 6f 77 6e 20 30   nknown 0
0038: 2e 30 2e 30 2e 30 20 61   .0.0.0 a
0040: 74 20 6f 66 66 73 65 74   t offset
0048: 20 30 31 62 62 61 39 38    01bba98
0050: 30                        0       



Visual Studio 2005 Debugger gives this for the stack trace:
*1      01bba980()
 2      msvcrt.dll!__endthread() 
 3      kernel32.dll!_BaseThreadStart@8()

WinDBG gives this:
<Unloaded_php5ts.dll>+0x26a980
msvcrt!endthread+0xab
kernel32!GetModuleFileNameA+0xeb

the Debug Diagnostic Tool gives this
Function     Arg 1     Arg 2     Arg 3   Source 
<Unloaded_php5ts.dll>+26a980     01782ee8     00000000     00000000    
msvcrt!endthread+ab     02108c80     00000000     00000000    
kernel32!GetModuleFileNameA+eb     77bcb35a     02108c80     00000000

I've noticed this error, too, but only after a PHP page has been loaded.

Same basic setup as most, Server 2003, IIS 6, PHP 5.1.4,  painstakingly followed the setup instructions.

Now a webpage that loads only HTML does not give this error.  When I load a page that calls PHP, it throws this error about 5 to 10 minutes after the first page is loaded.

I have this problem too, but it has nothing to do with PHP as I'm running ASP.NET.

My environment is:
MS Windows 2003 Server + SP2
IIS 6.0.3790.3959
.NET 2.0.50727

I get both:

Faulting application w3wp.exe, version 6.0.3790.1830, faulting module
unknown, version 0.0.0.0, fault address 0x01bba980.

and

Data Execution Prevention ? Microsoft Windows
To help protect your computer, Windows has closed this program. 
Name: IIS Worker Process
Publisher: program publisher

There have been a few bugs reported for this issue over a few years, and the most current and active one seems to be Bug #38111. I suggest everyone head over there and votes for it.

It is also open and awaiting a backtrace.  The problem appears that the crash is not directly the result of PHP code being executed, but rather the result of IIS cleaning up worker proccesses with PHP ISAPI running in them and DEP preventing some code execution at that time.  This makes generating a backtrace difficult, and thus the bug has been around for a number of years.

To help people with this issue, a number of workarounds have been discovered over the years:
- Add w3wp.exe to DEP exclusion list 
- Turn off process recycling in IIS
- Use FastCGI rather than ISAPI

Hi:
I'm having the same issue working with IIS7 Farm (Windows2008), the metabase content is in a SQL Cluster(Windows2008+Sql2008), when I perform a Failover the IIS needs to run an IISReset because they can not access the sites, I found a php5ts.dll crash. DefaultAppPool has Heap Corruption which adds to the problems. This is in the event logs from the system:
Need DebugDiag to monitor for 0xC0000374 during a failover
I need help because the issue in not solve.

Let make the suggestions more clear. Please use FastCGI with IIS. It is available for IIS5/6/7, x86 and x64, for xp, 2003, vista, 2008 and win7.

> Won't fix.