I don't run php with ea on IIS 6 so I can really help much.

Some ideas:
- Look at the logs to get the ip of the spammers and use IPSec on the W2K3 server to block that ip or range of ips.
- Use the ea intruction to filter the content that gets cached to see if you can determine if it is a particular set of php instructions that cause problems. For example cache only file with .php5 create a few file that have the .php5 extension and see when the problem happens if all php file don't work or just the cached .php5 ... You can also use that intruction to avoid caching certain files that might cause problems.

- You should probably do some hardcore debugging see exactly what is happening. Is the problem because the old "PHP/EA context" hangs around will the IIS thread are allocated new space ? Is the recycling of the IIS threads exactly designed to "free" IIS from problem DLL and it can't make a difference between a still good "PHP/EA context" versus a locked up "PHP/EA context".
So is it by design ?

So you probably have to get deeper into understanding the reycling process to see if you can find a solution.

Good luck,
C