I have found out there is a worse problem. When calling the 
ISAPI DLL function HttpExtensionProc(Extension) to process the PHP session it leaks some memory. If you remove the call it does not leak any memory. I also made sure the WriteClientProc and such procedures in the Extension struct are empty so there could not be any leak from within the web server engine. I also tried to unload the ISAPI dll and this did not free the memory either. When run the 1000x HttpExtensionProc(Extension) to a very easy script like the following:
<?
  echo "Hello";
?>
It leaks about 500kB. I'm not a Linux guy but I suppose if there would be a leak on Linux everybody would already know so I think it might be the ISAPI module problem only. Hopefully.
Thanks Jakub

Some more info I have found.
The DllMain function from the ISAPI dll is incorrectly exported and has the name _DllMain@12 so it cannot be called by the web server. When you call the PROCESS_ATTACH and DETACH DllMain calls it raises and exception. THREAD_ATTACH and DETACH work fine but still the memory leak is there. Each call to the HttpExtensionProc leaks about 1kB of memory. Please try to have a look at it
J

I was wrong about the _DllMain@12 it is called by Windows automatically. However I have found for instance this.
If you load the ISAPI module and free it in a cycle again it does not free the memory.
for ($i=0;$i<1000;$i++)
{
  lh = loadlibrary("...isapi.dll");
  freelibrary(lh);
}
After 200 cycles the process consumes 50MB. I don't think that should happen. What is wrong?

You have some extensions loaded in php.ini, right?
Which ones are those? What if you don't load them?

That's what I thought of too so I removed all extensions and the results I posted are without any extensions.

I have been digging more into this issue and I have found this.

1. HttpExtensionProc like this does not leak at all.
DWORD WINAPI HttpExtensionProc(LPEXTENSION_CONTROL_BLOCK lpECB)
{ return 0; }

2. 1. HttpExtensionProc like this does leak.
DWORD WINAPI HttpExtensionProc(LPEXTENSION_CONTROL_BLOCK lpECB)
{
	TSRMLS_FETCH();
	ts_free_thread();
        return 0;
}
It is clear that the ts_free_thread does not free everything. I'm not a C/C++ guru please people help here. This issue has been here since 2 years ago and nobody fixed it yet. Let me know. 
Jakub

I think I tracked down the leak.
In this function:
TSRM_API void *ts_resource_ex(ts_rsrc_id id, THREAD_T *th_id)

There's at the end this:
	TSRM_SAFE_RETURN_RSRC(thread_resources->storage, id, thread_resources->count);

Now if I uncomment this. It does not leak the memory for the 2 calls from my last post. 

The call translates to 
return &thread_resources->storage;

Why should this leak? Please, C++ people help us here.

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

Some fixes have been committed recently which should fix this bug. Please try the snapshot out.

The recent changes have fixed a big chunk of the leaks, but there are still a couple of memory types that are not getting freed.  I'll have a couple of more patches to close out this bug soon.

No feedback was provided for this bug for over 2 weeks, 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".