Do you think this problem has appeared suddenly because my session (cookie based) reach the maximum size possible for sessions ?

I thought about that if it can be useful.

Just to confirm: is this PHP 5.3 and is it the Wincache 1.1 (not the latest dev drop)? 

The reason I ask is because in the latest drop for PHP 5.2 I have noticed the same problem, while on PHP 5.3 it worked. On PHP 5.2 the session fails to initialize because the name of the temporary session file created by wincache is corrupted. I thought that was specific to PHP 5.2 and VC6 build but if you see the same on PHP 5.3 then it looks like a bug somewhere in WinCache.

Here is the the call stack I see on PHP 5.2 that causes this failure (notice the name of shared filemap):

[9804] WINCACHE: start zvcache_create
[9804] WINCACHE: end zvcache_create
[9804] WINCACHE: start zvcache_initialize
[9804] WINCACHE: start filemap_create
[9804] WINCACHE: end filemap_create
[9804] WINCACHE: start filemap_initialize
[9804] WINCACHE: Creating a shared filemap with name |o[[_32751331_51971796
[9804] WINCACHE: start create_file_mapping
[9804] WINCACHE: failure 209 in create_file_mapping
[9804] WINCACHE: end create_file_mapping
[9804] WINCACHE: failure 209 in filemap_initialize
[9804] WINCACHE: end filemap_initialize
[9804] WINCACHE: failure 209 in zvcache_initialize
[9804] WINCACHE: start filemap_terminate
[9804] WINCACHE: end filemap_terminate
[9804] WINCACHE: start filemap_destroy
[9804] WINCACHE: end filemap_destroy
[9804] WINCACHE: end zvcache_initialize
[9804] WINCACHE: failure 209 in ps_open_func
[9804] WINCACHE: start zvcache_terminate
[9804] WINCACHE: end zvcache_terminate
[9804] WINCACHE: start zvcache_destroy
[9804] WINCACHE: end zvcache_destroy
[9804] WINCACHE: end ps_open_func

In a successful case this should look as below (notice the name of the shared filemap):
[2820] WINCACHE: start ps_open_func
[2820] WINCACHE: start zvcache_create
[2820] WINCACHE: end zvcache_create
[2820] WINCACHE: start zvcache_initialize
[2820] WINCACHE: start filemap_create
[2820] WINCACHE: end filemap_create
[2820] WINCACHE: start filemap_initialize
[2820] WINCACHE: Creating a shared filemap with name WINCACHE_FILEMAP_SESSZVALS_1_93823
[2820] WINCACHE: start create_file_mapping
[2820] WINCACHE: end create_file_mapping
[2820] WINCACHE: Mapping file map at any random address
[2820] WINCACHE: end filemap_initialize
[2820] WINCACHE: start filemap_getsize
[2820] WINCACHE: end filemap_getsize
[2820] WINCACHE: start alloc_create
[2820] WINCACHE: end alloc_create
[2820] WINCACHE: start alloc_initialize
[2820] WINCACHE: start lock_create
[2820] WINCACHE: end lock_create
[2820] WINCACHE: start lock_initialize
[2820] WINCACHE: end lock_initialize
[2820] WINCACHE: start lock_getnewname
[2820] WINCACHE: end lock_getnewname
[2820] WINCACHE: end alloc_initialize
[2820] WINCACHE: start alloc_get_cacheheader

Same problem on 3 different servers. No idea why it happens some times and not others. Cleared session directory, tried permissions everything.

First Server:
Windows Server 2003 Standard Edition Service Pack 2 i586 (32bit)
MSVC9 x86 NTS
IIS 6.0 FastCGI 1.1
PHP 5.3.3

Second & Third Servers:
Windows Server 2008 Standard Edition Service Pack 2 i586 (64bit)
MSVC9 x86 NTS
IIS 7.0 FastCGI 1.1
PHP 5.3.3

I've tried various configurations, positioning the extension to load at the start/end... Nothing seems to help with this. For some reason, wincache thinks that the save path is unavailable whatever it may be.

Help with this is desperately needed!

Great thinking! That really bareks the mold!

Hello,

Microsoft team, do you have any news about this ticket I opened 2 years ago ?

I have since upgraded my webserver to IIS 8.0 but I observe yet randomly this bug with wincache sessions. Sometimes writing wincache session data fails (Unknown: Failed to write session data (wincache)) without any change to the code or configuration.

Thanks.

Hi,

we are getting the same problem (fastCGI-Error) in conjunction of a Win2003SP2 and IIS6 with PHP 5.3.24.

fcgiext.dll
7.5.7693.0 (fbl_srv_iis_dev(ksingla).090415-1635)

I vote this as urgent!

Hey guys,

I have the same problem. I am using Wincache 1.3.5 with PHP 5.5 under IIS 7.5 win7.

After certain time the hosted application cannot start a session:
session_start(): Cannot find save handler 'wincache'

I have often found some "out of mem errors" besides those session problems. Maybe they are related to each other.

Cheers

Confirmed with Julien that this issue no longer repros on 1.3.6.0.

It's still doing it randomly. Happened on Saturday, so I upgraded to php 5.6, and it happened again last night.

This is on a Windows2012 server

[08-Oct-2014 22:17:17 America/Phoenix] PHP Warning:  Unknown: Failed to write session data (wincache). Please verify that the current setting of session.save_path is correct (C:\Windows\temp) in Unknown on line 0


Windows error log:
Faulting application name: php-cgi.exe, version: 5.6.0.0, time stamp: 0x53fe294e
Faulting module name: php_wincache.dll, version: 1.3.6.1, time stamp: 0x53a45e09
Exception code: 0xc0000005
Fault offset: 0x0000ae64
Faulting process id: 0x37c4
Faulting application start time: 0x01cfe38101d746a6
Faulting application path: C:\Program Files (x86)\PHP\v5.6\php-cgi.exe
Faulting module path: C:\Program Files (x86)\PHP\v5.6\ext\php_wincache.dll
Report Id: 44f69346-4f74-11e4-80c7-0cc47a049217
Faulting package full name: 
Faulting package-relative application ID:

Fault offset 0xae64 in that version of php_wincache.dll is in the fcnotify_check function.  The AV occurs because a non-null notify record was found, but the record pointer must be in invalid memory (deref'ing through a bad pointer).

If you can get a crash dump of the repro, please send me mail offline and I can investigate.

Are you using multiple versions of PHP (and WinCache) on a single server?  If so, there may be an easy config adjustment to ensure this doesn't happen.

Thx!
    --E.

I will enable crash dumps on the server.

Yes, I have multiple versions of PHP and wincache installed, all but one of the sites the sites are using PHP5.6, and the PHP5.3 site does not use wincache. 

What would be the config adjustment workaround?

I have configured one site (the critical one) to use a different session save path after this crash.

Thanks!

Hello,

Actually, I use an IIS 8.0 server (Windows Server 2012) with PHP 5.5.17 + WinCache 1.3.6.1 for session/user/file cache + Zend OPcache for opcode cache

As I said to Eric, I do not observe more the session loss bug. I do not have seen the "Failed to write session data error" in the php logs since July 2013.

For me the problem is solved.

I have actually rare errors in the Events Viewer but I think it is an other problem:

Nom de l’application défaillante php-cgi.exe, version : 5.5.16.0, horodatage : 0x53f66389
Nom du module défaillant : php_opcache.dll, version : 5.5.16.0, horodatage : 0x53f66550
Code d’exception : 0xc0000005
Décalage d’erreur : 0x0000235b
ID du processus défaillant : 0xc04

I am going to try Wincache 1.3.6.3...

Bye

Sorry for the delay!

There is a problem when using multiple PHP/WinCache versions within a single IIS Application Pool.

WinCache's default settings do not support that usage, and it will cause massive problems. You'll wind up putting opcode arrays from different PHP versions in a single shared WinCache opcode cache, which will most likely AV (or at the very least, do very bad things).

While it is totally supported to have multiple sites within a single app pool, and it's also supported to have different handler mappings per site, Wincache has an architectural problem supporting multiple PHP versions in a single app pool.  Namely, Wincache calculates the name of the cross-process shared memory based off the app pool name.

Let me give an example:

Assume you have two sites (site1 and site2) sharing the same AppPool (appPool1).  Assume site1 mapped *.php to PHP5.3, and site2 mapped *.php to PHP5.4.

Let's say you had a single copy of a script file in c:\phpscrips\foo.php, and that script were used by both site1 and site2.
If site1 is the first to compile and cached the script, it would be placed in the Wincache shared memory chunk for appPool1 compiled for PHP5.3.  When site2 loads the file, it would find it in the appPool1 shared memory chunk, and think that it was a PHP5.4 opcode array, and would crash when trying to execute the PHP5.3 opcode array.

I would strongly recommend separating the different PHP versions into different app pools.

There is a workaround for this issue:  The wincache.namesalt configuration setting (http://php.net/manual/en/wincache.configuration.php#ini.wincache.namesalt).

If you set the wincache.namesalt to a different value in each of the system-wide php.ini for each version, you can separate the caches.

e.g.:
<in the PHP 5.5.15 php.ini file> 
[WinCache]
wincache.ocenabled = On
wincache.fcachesize = 85
wincache.internedsize = 32
wincache.maxfilesize = 2048
wincache.ocachesize = 255
wincache.filecount = 16384
wincache.namesalt = 5_5_15

<in the PHP 5.4.28 php.ini file>
wincache.ocenabled = On
wincache.fcachesize = 85
wincache.internedsize = 32
wincache.maxfilesize = 2048
wincache.ocachesize = 255
wincache.filecount = 16384
wincache.namesalt = 5_4_28

I believe this scenario (multiple versions of PHP/WinCache in a single AppPool) is why the wincache.namesalt setting was created.

    --E.

Hello,

Bad news!

After one year and a half without the session error problem, I have yet this issue from 2 days. I noted only this morning that my website authentication system was dead (based on sessions).

Once I disabled session.save_handler = wincache (by setting the value files), then reenable it, the PHP sessions run fine anew.

Here's what I see in the php log (about 50 times this line on 11/11 and 11/12):

[11-Nov-2014 21:40:27 Europe/Paris] PHP Warning:  Unknown: Failed to write session data (wincache). Please verify that the current setting of session.save_path is correct (D:\Temp\php\session\) in Unknown on line 0

My server config is:

* IIS 8.0 (Windows Server 2012)
* PHP 5.6.1 NTS VC11 x86 (it is the only PHP version I use on the server)
* WinCache 1.3.6.3 for user, files and sessions cache (I have enabled wincache.srwlocks = 0 one month ago with no apparent problems)
* OPcache extension for opcode cache

Any idea How to solve this bug definitely ? Thanks.