Description:
------------
On a Windows Server 2003 machine running IIS6.0 + PHP 5.1.3-dev running
as isapi.

Everytime the application pool recycles or is shutting down, the
w3wp.exe process that is shutting down crashes.
The w3wp.exe process that is being started, will start without any
problems.

I attached Debug Diagnostic Tool (v1.0) from Microsoft to the faulting
application pool, which gives the following result:

w3wp__PID__3188__Date__03_24_2006__Time_10_48_32PM__421__Second_Chance_E
xception_C0000005.dmp
Type of Analysis Performed   Crash Analysis 
Machine Name   XXXXXXX 
Operating System   Windows Server 2003 Service Pack 1 
Number Of Processors   1 
Process ID   3188 
Process Image   c:\WINDOWS\system32\inetsrv\w3wp.exe 
System Up-Time   2 day(s) 00:21:07 
Process Up-Time   0 day(s) 00:00:40 

Thread 19 - System ID 2360
Entry point   msvcrt!_endthread+3b 
Create time   3/24/2006 10:48:32 PM 
Time spent in user mode   0 Days 0:0:0.0 
Time spent in kernel mode   0 Days 0:0:0.0 

Function     Arg 1     Arg 2     Arg 3   Source 
<Unloaded_php5ts.dll>+2bc3f0     015eda00     00000000     00000000    
msvcrt!_endthread+ab     02093838     00000000     00000000    
kernel32!BaseThreadStart+34     77bcb35a     02093838     00000000    

In
w3wp__PID__3188__Date__03_24_2006__Time_10_48_32PM__421__Second_Chance_E
xception_C0000005.dmp an access violation exception (0xC0000005) occured
on thread 19 when another module attempted to call the following
unloaded module: php5ts.dll.

Im using the latest source files at snaps.php.net, configure command:

cscript /nologo configure.js --enable-isapi

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.