> As I undersstand some of the MSDN documentation, how ISAPI filters
> are executed has changed significantly along with the process model for
> IIS in v6. Where ISAPIs used to run in the parent process, now they're
> run in the worker threads.
No, we did not change it that significantly. The functionality of ISAPI
Filters interface has remained stable. What has changed is the underlying
process model and its implications on ISAPI Filters, and that is absolutely
expected. It is one reason we have an "IIS5 Compatibility Mode" -- to remove
the process model as a change and try to emulate IIS5 behavior wherever
possible.
> When you mix in worker thread recycling, is there any difference in how
> the cleanup/shutdown happens? I'm wondering if something different in
> the recycling process may be involved in the crash dumps we're seeing,
> as the number of dumps is related to how often tehy set it to recycle.
There's not much difference in how IIS6 presents the cleanup/shutdown to
ISAPI Filter for worker process recycling. IIS6 will make sure to unload the
ISAPI Filter DLL when it recycles, which eventually triggers your
PROCESS_DETACH entry point, etc. Not much problems with IIS6 here.
However, the mere fact that you are using IIS6 Application Pools means you
are introducing big differences to ISAPI Filters:
1. Multi-instance. It used to be that ISAPI Filter runs singleton instance
on the entire server. Now, it can run an instance inside different worker
processes. That global mutex is now more of a problem than a solution...
2. Recycling. It used to be that ISAPI Filter only starts up when the server
starts and cleans up when the server shuts down. This was a relatively rare
occurrence because you'd only do this once every several days/weeks.
Frequently, there are startup/shutdown bugs in ISAPI Filters that get
"covered up" because those events do not happen very often... but when you
recycle, they are now happening on the order of 24 times a day (instead of
once every several days), thus these filter startup/shutdown bugs are easily
exposed.
Recycling also introduces a possibility that two instances of same ISAPI
Filter DLL is in memory at the same time (via "overlapping recycle", where
the old w3wp.exe and filter DLL stays in memory until the new w3wp.exe and
filter DLL loads up). This is of course configurable, and the default is to
allow overlapping recycle.
3. Identity. It used to be that ISAPI Filter runs inside inetinfo.exe, which
runs as LocalSystem. By default in Worker Process Isolation Mode, it is
Network Service. Some filters depend on the identity to access various
resources, including Event Log and the file system.
A quick check would be to switch IIS6 into IIS5 Compatibility mode, which
would emulate IIS5 behavior by removing the multi-instance (filters all load
inside inetinfo.exe like before), there is no recycling, and the process
identity goes to LocalSystem.
If the filter runs fine in IIS5 Compatibility mode but fails in IIS6 Worker
Process Isolation mode, more than likely, there are some latent bugs in the
ISAPI Filter that are not uncovered until now, and you will have to
fix/address them in order to use IIS6 Application Pools.
--
//David
IIS
<a style='text-decoration: underline;' href="http://blogs.msdn.com/David.Wang" target="_blank">http://blogs.msdn.com/David.Wang</a>
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Mark" <mmodrall.DeleteThis@nospam.nospam> wrote in message
news:5D06B819-E32D-4AA9-B166-348C48869711@microsoft.com...
Hi...
Our ops guys want to upgrade all of our old W2K, IIS 5 servers to W2k3/IIS
6, and I'm wondering about the implications for a few old ISAPI filters
we've
got.
The first trial box they set up had 2 worker threads set to cycle every
hour. They found that IIS was generating rather prodigious .hdmp files
(still trying to find a reader for those), and they think it's got something
to do with our ISAPI filters.
As I undersstand some of the MSDN documentation, how ISAPI filters are
executed has changed significantly along with the process model for IIS in
v6. Where ISAPIs used to run in the parent process, now they're run in the
worker threads.
Obviously, that has implications for isapi memory structures, configuration
and such - you'll have as many copies of the memory structures for the isapi
as you do worker threads, so there are a lot of implications there.
How about cleanup/shutdown/recycling? How is that handled? In our old
ISAPI, cleanup was done on PROCESS_DETACH from the dll (which presumably the
IIS 5 parent process was doing). We never saw any dumps coming out of that.
When you mix in worker thread recycling, is there any difference in how the
cleanup/shutdown happens? I'm wondering if something different in the
recycling process may be involved in the crash dumps we're seeing, as the
number of dumps is related to how often tehy set it to recycle.
Thanks
_mark<!-- ~MESSAGE_AFTER~ -->
>> Stay informed about: IIS 6, old ISAPI filters 
FAQ
Profile
Private Messages
Log in
