Hi,

I'm trying to install wincache 1.3for php 5.6 on my server which has no direct internet connection available.

So i've downloaded the installer, extracted and transferred those files to the server.

When i'm trying to open the wincache56wpi.msi it keeps saying: PHPPATH prporty must be set to the directory where PHP resides.

Under system variables i've already set the PHPPATH variable to my php folder, but the msi doesn't recognise this.

Could you please help?

Has anyone seen this issue (maybe not exact but similar that may have some insight)?

Before I describe it, Starters: My environment is Server 2012 R2 IIS8 64 Bit, running php version 5.3.28 NTS  VC9 along with Railo 4.

I have a php script that reads in a 2meg file and loops thru it, reading in line by line.  On each line it calls a coldfusion file which in turn updates the db (the calls to CF is clocking in in the 2-5ms range.  During the loop process, it goes painfully slow where IIS thinks it is taking 1000ms (verified in the IIS logs under time taken).

I also have boncode logging enabled so I can see each time the cf page is hit.

If, while in the loop and it is going painfully slow, I go into fastgci in IIS, and change the Max. Instances from whatever number it is (lets say 1) and change it to an arbirtrary number (lets say 32), it immediately kicks in and goes very fast.   Almost like it unjars something.  

You can go from 32 to 0, 16 to 19, 0 to 1, does not matter; all that matters is that the number changes.

The issue is present with and without wincache enabled, and it is present across 5.2.x and 5.3.x versions of php.

I'm kind of at a loss of where to look at this point, so anything is on the table.

And yes, this script/functionality was working fine without issue under server 2003 for close to a decade; this was the last server in a very large migration, so please no jeers (-;

We are not yet ready to make the plunge to 5.5 or 5.6.

Other info
=======

- Site running the php script is in its own app pool
-  That app pool is configured to run 32 bit apps
- Can't run that app pool in classic mode because of railo.
- I tried putting the page on its own non-railo site, created a new classic mode app pool, and it was still slow.
- There are no php errors being logged
- In the fastcgi mappings, I increased the max requests to 10000 and matched it with the env var PHP_FCGI_MAX_REQUESTS

No matter what combination I try, the one constant is still the same; change the max instances on the fly (no recycling of the app pool) and it magically starts going fast.

Thoughts and thanks in advance

At random times during the day, my web site will freeze and php logs the following error:

[28-Apr-2015 15:49:30 America/New_York] PHP Fatal error: Failure in Wincache[6644] free_memory: Block 0x1e01b4c not in use
in E:\VectorsTestSite\vendor\laravel\framework\src\Illuminate\Filesystem\Filesystem.php on line 16

This error will occur as long as the wincache filecache is enabled.  I disabled the opcode cache, but the error still occurs.  I also placed the offending file triggering the error in the ignore list.

So open to ideas/suggestions, since when Wincache is running properly, the site is 20% faster and we need that extra speed.

The environment:

WinCache version 1.3.7.4
PHP version 5.6.8
Laravel 4.2.16
Server software Microsoft-IIS/8.5
Operating System Windows NT 6.2 (windows server 2012)
Processor information Intel64 Family 6 Model 62 Stepping 4, GenuineIntel
Number of processors 8

Wincache Settings:

wincache.chkinterval 60
wincache.fcachesize 50
wincache.fcenabled 1
wincache.fcndetect 1
wincache.filecount 4096
wincache.ignorelist factory.php|index.php|filesystem.php
wincache.internedsize 4
wincache.maxfilesize 256
wincache.ocachesize 200
wincache.ocenabled 1
wincache.reroute_enabled 1
wincache.scachesize 8
wincache.srwlocks 1
wincache.ttlmax 1200
wincache.ucachesize 8
wincache.ucenabled 1

So after my production site runs for a while and I look at the statistics with the wincache.php file, it will indicate the opcode and file cache are using 100% of the memory however no files in either cache.  As soon as I recycle the app pool, the statistics immediately return to normal.  I've currently set the application pool to automatically recycle every 60 minutes as a safety precaution.

My Wincache Settings

wincache.chkinterval 60
wincache.enablecli 0
wincache.fcachesize 50
wincache.fcenabled 1
wincache.fcndetect 1
wincache.filecount 4096
wincache.ignorelist factory.php|index.php|filesystem.php
wincache.internedsize 4
wincache.maxfilesize 256
wincache.ocachesize 200
wincache.ocenabled 1
wincache.reroute_enabled 0
wincache.scachesize 8
wincache.srwlocks 1
wincache.ttlmax 1200
wincache.ucachesize 8
wincache.ucenabled 1

My Server Environment

WinCache version 1.3.7.4
PHP version 5.6.8
PHPRC C:\Program Files (x86)\PHP\v5.6.8\
Server software Microsoft-IIS/8.5
Operating System Windows NT 6.2
Processor information Intel64 Family 6 Model 62 Stepping 4, GenuineIntel
Number of processors 8
PHP session handler wincache
Application Pool ID Vectors Live
Site ID 4
FastCGI impersonation enabled

I was about to pull my hair on this while porting the Drupal SQL Server driver to Drupal 8, but after investigation I can only conclude that the Wincache Opcode Cache is breaking Drupal 8 install process.

Why am I using still this Opcode cache instead of Zend's? Because Zend Opcache is broken on Windows, there's at least 10 bugs on the PHP issue queue  related to Zend Opcache randomly failing on windows.

Steps to reproduce:

1. Get the latest dev version of Drupal 8 with GIT:

git clone --branch 8.0.x http://git.drupal.org/project/drupal.git

2. Download clean PHP binaries from PHP (5.6.9 Non Thread Safe)

http://windows.php.net/download/

3. Add Wincache 1.3.7.4 to the extension DIR and enable the opcode cache and enable the MySQL pdo:

extension=php_wincache.dll
wincache.ocenabled=0
wincache.ocachesize = 100
extension=php_mysql.dll

4. Configure an IIS site with D8 and the PHP and navigate to the installation URL, introduce the MySQL database details and strat the installation process.

Then this errors shows up:

An AJAX HTTP error occurred.
HTTP Result Code: 200
Debugging information follows.
Path: /core/install.php?langcode=es&profile=standard&id=1&op=do_nojs&op=do
StatusText: OK
ResponseText: 
Fatal error:  Class name must be a valid object or a string in D:\DRUPAL OFICIAL\d8\core\lib\Drupal\Core\Entity\Annotation\EntityType.php on line 63

So I investigated and debugged the error with XDebug a few times to find out that this is probablysome sort of encoding issue.

The error originates because this line:

$class = $values['entity_type_class'];

is returning NULL ($class = null).

But.... the $values array DOES contain a KEY named 'entity_type_class'. The only possible explanation for this is that the key inside the array and the 'entity_type_class' literal have different encodings or are not binary equal.

But I tried all imaginable ways to determine if both strings (key and literal) had different encodings, and they look to be exactly the same, PHP's mb_detect_encoding reports they are both ASCII encoded, and using PHP's == and === operator on the literal and the key return TRUE.

I have tried to install wincache-1.1.0-5.2-nts-vc6-x86.exe on a Windows 2012 server with PHP 5.2.14 and the Zend Scripting Language Engine:
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies
    with Zend Extension Manager v1.2.0, Copyright (c) 2003-2007, by Zend Technologies
    with Zend Optimizer v3.3.3, Copyright (c) 1998-2007, by Zend Technologies

I keep getting errors similar to this:

Faulting application name: php-cgi.exe, version: 5.2.14.14, time stamp: 0x4c4731f0
Faulting module name: php-cgi.exe, version: 5.2.14.14, time stamp: 0x4c4731f0
Exception code: 0xc0000005
Fault offset: 0x0000191a
Faulting process id: 0x1428
Faulting application start time: 0x01d0997f68f7b4b8
Faulting application path: C:\Program Files (x86)\Parallels\Plesk\Additional\PleskPHP5\php-cgi.exe
Faulting module path: C:\Program Files (x86)\Parallels\Plesk\Additional\PleskPHP5\php-cgi.exe
Report Id: a6a44096-0572-11e5-940f-d4ae52ce89b9
Faulting package full name:
Faulting package-relative application ID:

Before I spend more time troubleshooting, is there a version of WinCache that is compatible with both Windows Server 2012 and PHP 5.2.14 ? If so, which one?

Can it be the Zend engine that is not compatible with WinCache?

Thank you!

Lena

Hi,

Are there any plans to support PHP 7 once it hit's beta? It supports native 64-bit out of the box and there are already Windows builds for the first alpha. It would be really nice to be able to switch to PHP 7 right away once the final version is released.

Cheers,
Mike

On latest Wincache 1.3.7.6, tested on PHP 5.5.26.

In php.ini use:

session.save_handler = wincache

Now set session storage path to unexistent location:

session.save_path = "D:\caca\"

Script 1

<?php

session_start();

print "<html><body>WORKS</body></html>";

PHP FATALS with the following message (expected):

Fatal error: session_start(): Failed to initialize storage module: wincache (path: D:\caca\)

Script 2

<?php

class WincacheSessionHandler extends SessionHandler {
  public function read($session_id) {$data = parent::read($session_id);
  }
}

// Initialize the storage
$handler = new WincacheSessionHandler();
session_set_save_handler($handler, true);

session_start();

print "<html><body>WORKS</body></html>";

You get a WSOD crash (not a PHP fatal):

Faulting application name: php-cgi.exe, version: 5.5.26.0, time stamp: 0x5578a6fc
Faulting module name: php_wincache.dll, version: 1.3.7.6, time stamp: 0x556cd721
Exception code: 0xc0000005
Fault offset: 0x000163bf
Faulting process id: 0x588
Faulting application start time: 0x01d0ad4649943c17
Faulting application path: C:\Program Files (x86)\PHP\php5.5\php-cgi.exe
Faulting module path: C:\Program Files (x86)\PHP\php5.5\ext\php_wincache.dll
Report Id: 88887401-1939-11e5-83b0-8019346bbdc6
Faulting package full name:
Faulting package-relative application ID:

Not a big deal, but makes a nightmare to troubleshoot a broken session storage path :(

We're getting crashes on production sites that we've been unable to figure out, but at this point I'm suspecting WinCache may be the culprit. We're running Windows Server 2008 R2, PHP 5.4, and WinCache 1.3.4. We have 6 servers configured pretty much the same and have had crashes on most of them. I setup DebugDiag and while I did get a few crash dumps initially, the crashes kepts on happening but I no longer get any crash dumps. In the ones I got, the one thing that stood out was the only dll I recognized was wincache. All of them have an entry like this:

Thread 1 - System ID 8256

This thread is not fully resolved and may or may not be a problem. Further analysis of these threads may be required.

I also noticed that php-cgi.exe and php.exe processes tend to accumulate in the task manager and sometimes when there are crashes, there are dozens of them sitting there using no CPU. I did crash dumps on some of those, and all of them usually have the same entry I copied above. I've tried upgrading to WinCache 1.3.7.4, but when I did that all of a sudden my php.exe processes consistently did not exit, so I had to revert to WinCache 1.3.4.

So my question for starters is this: is there a sure way to diagnose if a crash is definitely caused by WinCache? At this point, having looked into a number of things and seeing other people reporting crashes, I'm leaning in that direction, but I'd love to be able to have more certainty. Any help is appreciated.

Hi,

Every 1-2 weeks, one of my server's websites grinds to a halt.

Looking at windows application event log, I see multiple errors like the one listed below.

I am using Win2008 server with IIS 7.5 64bit, PHP WinCache 1.3.5, PHP 5.5.8.

When this happens, I can also see 10's of php-cgi.exe tasks running (a lot more than when the server is functioning properly).

I will try using WinCache 1.3.5.2 that I see was released as a dev version and see if this error still repeats.

Here's the event log xml data:

  <System>
  <Provider Name="Application Error" />
  <EventID Qualifiers="0">1000</EventID>
  <Level>2</Level>
  <Task>100</Task>
  <Keywords>0x80000000000000</Keywords>
  <TimeCreated SystemTime="2014-03-19T09:51:05.000000000Z" />
  <EventRecordID>63754</EventRecordID>
  <Channel>Application</Channel>
  <Computer>HIGHTOURS</Computer>
  <Security />
  </System>
- <EventData>
  <Data>php-cgi.exe</Data>
  <Data>5.5.8.0</Data>
  <Data>52cde23c</Data>
  <Data>php_wincache.dll</Data>
  <Data>1.3.5.0</Data>
  <Data>51f7ead2</Data>
  <Data>c0000005</Data>
  <Data>00007ff3</Data>
  <Data>c1c</Data>
  <Data>01cf4358bef65452</Data>
  <Data>C:\Program Files (x86)\PHP\v5.5\php-cgi.exe</Data>
  <Data>C:\Program Files (x86)\PHP\v5.5\ext\php_wincache.dll</Data>
  <Data>fca07dd2-af4b-11e3-af09-95187af0dd16</Data>
  </EventData>
  </Event>
 

FYI--

I need some help from PHP community members to start testing the next version of WinCache for PHP7.  For those brave and hearty souls who would like to see WinCache working on PHP 7, here is your opportunity to help!

I've dropped an EXPERIMENTAL version WinCache 2.0 for PHP7 up on SourceForge:

x86: http://sourceforge.net/projects/wincache/files/development/wincache-2.0.0.0-experimental-7.0-nts-vc14-x86.exe/download

x64: http://sourceforge.net/projects/wincache/files/development/wincache-2.0.0.0-experimental-7.0-nts-vc14-x64.exe/download

Notes:

• I have tested this with PHP 7.0.0beta3 (from http://windows.php.net/qa/).
• This is vc14 NTS ONLY.
• This includes the first x64 version of WinCache.
• I've tested with the PHP regression test suite, but have not tested with any major framework.  If anyone can test with WordPress, Drupal, etc., I'd really appreciate it!
• I've done some quick FastCGI testing with IIS, but no stress or long-haul testing.
• The opcode portion of WinCache has been removed.  You should use Zend Opcache.
• Because the opcode cache is gone, you'll have to use the new wincache.php that's included in the self-extracting archive.

Requests:

• If you run into a crash, please contact me (private message on the IIS.net forums), and send me the repro script.  If you don't have a repro, I can't investigate.
• If you are able to capture crash dumps of any failing cases, please contact me (private message on the IIS.net forums), and we can somehow arrange transfer of the dump file so I can investigate.

Warning:

These bits are EXPERIMENTAL.  That means they're not extensively tested, and may contain crashing bugs.  No one should put these bits anywhere near a production environment.  Caveat Emptor: You have been warned!

Thx!

    --E.

Hi,

could you please help us to find out, what the problem could be?

[02-Oct-2015 13:36:24 Europe/Berlin] PHP Fatal error:  Failure in Wincache[3956] free_memory: Combining with non-free block 0x2d92b04 - CORRUPTION IMMINENT
 in Unknown on line 0

Access Log:

2015-10-02 13:35:26.704 172.18.x.x GET /auth/saml/login.php manuallogin=1 - - 172.16.9.220 "Mozilla/5.0 (compatible; PRTG Network Monitor (www.paessler.com); Windows)" - 200 0 0 2468 "D:\Moodle\auth\saml\login.php" "MOODLSVR1" 36271 258 "clientIP"
2015-10-02 13:36:24.222 172.18.x.x GET /auth/saml/login.php manuallogin=1 - - 172.16.9.220 "Mozilla/5.0 (compatible; PRTG Network Monitor (www.paessler.com); Windows)" - 500 0 0 0 "D:\Moodle\auth\saml\login.php" "MOODLSVR1" 169 258 "clientIP"

All following answered by HTTP-Status: 500

Thank you + Best regards

Hello Eric,

Do you have any information about the release date of a WinCache 2.0 stable version for PHP 7.0.0 which is available as you know.

Thanks ;)

The IIS team has published the release version of  WinCache Extension 2.0.0.2 for PHP 7.0.  This is the latest stable and production ready version of the extension for PHP 7.0.

Support for installing via the Web Platform Installer will be added in the future.

If you install the extension manually, then follow the instructions at  Installing/Configuring WinCache for PHP.

Notes

• WinCache 2.0.0 now fully supports x64 builds of PHP 7.0.

• As previously documented, opcode caching has been REMOVED in WinCache 2.0.0 and later.  User should use the Zend Opcache extension which has been available in the core PHP product since PHP 5.5.  To load the Zend Opcache extension, ensure the following line is included in the php.ini file:

zend_extension=php_opcache.dll 
[opcache] 
opcache.enable=1

•The extension can only be used with non-thread-safe builds of PHP

•The extension can only be used when IIS is configured to run PHP via FastCGI

•The WinCache Extension 2.0.0.2 for PHP 7.0 can only be used with the VC14 build of PHP 7.0. This will require the VC14 redistributable runtime library.

The IIS team thanks all of you who have installed and tried early releases of the WinCache extension and provided us with feedback, bug reports and feature suggestions through the Windows Cache Extension for PHP Forum . Your involvement throughout the release process has been very valuable and truly helped make this a great release!

Thank you!

    --E.

I have an issue where our vulnerability scanner will scan our web server which is running Drupal 7. The issue is that the scanner crashes WinCache everytime it scans the website. Also in normal website operation we do see WinCache crash once a week randomly. Below are the errors from the PHP 5.3 logs. Any insight on this issue would be awesome!!!! Thanks!

Windows 2008 R2

IIS 7.5

WINCACHE - 1.3.6.3

[12-Dec-2015 22:29:38 UTC] PHP Fatal error: WINCACHE: lock_writelock: acquired abandoned mutex USERZVALS_SEGMENT_1_0_608445_X. Something bad happend in another process! in C:\inetpub\wwwroot\prod\sites\all\modules\wincachedrupal\drupal_win_cache.inc on line 332

[12-Dec-2015 22:30:11 UTC] PHP Fatal error: WINCACHE: lock_writelock: acquired abandoned mutex USERZVALS_SEGMENT_1_0_608445_X. Something bad happend in another process! in C:\inetpub\wwwroot\prod\sites\all\modules\wincachedrupal\drupal_win_cache.inc on line 332

[12-Dec-2015 22:30:45 UTC] PHP Fatal error: WINCACHE: lock_writelock: acquired abandoned mutex USERZVALS_SEGMENT_1_0_608445_X. Something bad happend in another process! in C:\inetpub\wwwroot\prod\sites\all\modules\wincachedrupal\drupal_win_cache.inc on line 332

[12-Dec-2015 22:36:02 UTC] PHP Fatal error: WINCACHE: lock_writelock: acquired abandoned mutex USERZVALS_SEGMENT_1_0_608445_X. Something bad happend in another process! in C:\inetpub\wwwroot\prod\sites\all\modules\wincachedrupal\drupal_win_cache.inc on line 332

Hi,

The components of the server : IIS 6.0 (with 2 webgarden used) + PHP 5.3.3 NTS x86 VC9 + FastCGI 1.5 + WinCache 1.1.

WinCache configuration :

wincache.ocachesize = 18
wincache.fcachesize = 6
wincache.ttlmax = 0
wincache.enablecli = 1
wincache.ucenabled = 0
wincache.ignorelist = "test.php"

I have a problem with the file change notification function when I update my PHP files with the FTP plugin of the Notepad++ software. When I upload a file to the server (to replace an existing file), the file is well updated in the Windows Explorer of the server but if I access it by HTTP, I obtain yet the old version of the file. In fact, the WinCache cache has not been refreshed despite the file change notification function is enabled (by default). I precise that this problem is totally random because sometimes after I do an upload the cache is well refreshed and sometimes not.

Apparently, I can't reproduce the problem with an other FTP client. With FileZilla client per exemple, after an upload, the WinCache cache seems to be always refreshed.

If I update my files directly through the Windows Explorer server (with notepad per exemple) the WinCache cache is well updated.

Do you think the FTP uploads/writes done by Notepad++ "are not seen" by the file cache change detection mechanism ?

Or could this problem can be due to the web garden of my application pool (I know that web garden are well supported since WinCache 1.1) ?

The difference of my PHP files is per exemple that in the original file, I have a query commented with //mysqli_query(blabla); and if I uncomment this request and upload the file, the query is not executed because the file cache has not been refreshed (but the on disk file yes). Don't know if this present an interest for debugging.

Bye.

This is PHP 5.6 x86

When using reroute_enabled=1, there seems to be an internal cache for functions such as file_exists() and others, but this cache - that I supposed was dependant on the same cache that is used for wincache.fcenabled=1 - seems to be completely unbound.

Take the following script:

$location = "d:\\dump.txt";

wincache_refresh_if_changed([$location]);
clearstatcache();
if (!file_exists($location)) {
  file_put_contents($location, "<?php " . PHP_EOL);
}

file_put_contents($location, "THIS IS A LINE" . PHP_EOL);

return;

What I expect is that if I run this script, then manually delete the d:\\dump.txt file and run it again the call to file_exists() will return FALSE.

If using wincache.fcenabled=1 and reroute_enabled=0 it works as expected. Indeed, you don't even need the call to wincache_refresh_if_changed() or to clearstatcache(), propably the file system is notifying the cache that the file was deleted.

Buf if I use reroute_enabled=1 the nightmare starts. Once the file has been created, file_exists() will always return TRUE even if you manually delete the file from the file system, meaning that the calls to wincache_refresh_if_changed() or clearstatcache() have no effect on whatever internal cache reroute_enabled is using.

I found that if I added unlink() at the end of the script to delete the file (instead of doing this manually) then the internal cache seems to become aware of the fact the the file is being deleted.

But this is confusing....

1. I expect that calling wincache_refresh_if_changed() will refresh whatever internal cache is being used. I would also expect this from clearstatcache() - even if they are different caches. Probably wincache should also  be hooking into clearstatcache().

2. The fact that the documentation states that reroute_enabled=1 routes some function calls through the file cache (the one that is enabled with fcenabled=1) leaves me wondering what does the file cache do when reroute_enabled=0...

3. Wincache is supposed to internally receive file system notifications, so I can't understand why it is not being notified that the file was deleted - or if it is being notified - why is it not clearing/updating the cache used by reroute_enabled.

To make this more confusing, the docs don't make it clear what each cache does, and how do they work together.

We are currently running WinCache 1.3.7.4 and are confused about what the actually supported current version is. MS support has suggested we upgraded to 1.3.7.6 to resolve a filecache issue. But when you go to the source forge page it is under development folder not the release folder. http://sourceforge.net/projects/wincache/files/development/

The release folder has no 1.3.7.6

http://sourceforge.net/projects/wincache/files/wincache-1.3.7/

I do see the release folder now has a 1.3.7.8

http://sourceforge.net/projects/wincache/files/wincache-1.3.7/

But neither the announcements for this forum no the the changelog page has info on it.

https://pecl.php.net/package-changelog.php?package=WINCACHE

The change log page lists 1.3.7.7 but like 1.3.7.6 this is only in the Dev folder. 

So how do we determine what is actually supported? Also, the announcements all state "The IIS team thanks all of you who have installed and tried early releases of the WinCache extension and provided us with feedback, bug reports and feature suggestions through the Windows Cache Extension for PHP Forum. Your involvement throughout the release process has been very valuable to us and really helped us make this a great release!"

but when you open a case with MS they say they don't support wincache. 

PHP 7.0.2

Wincache reports 2.0.0.2 (but from 2.0.0.3 installer, build time Dec 23 2015 14:53:30)

I'm using session_regenerate_id() to manage users logged in for longer than nominal expiry. I'm seeing 

[31-Jan-2016 16:45:51 Europe/London] PHP Catchable fatal error:  session_regenerate_id(): Failed to create(read) session ID: wincache (path: C:\Windows\Temp) in [file location]

A quick search suggested that the Session handler (Wincache) needs a bit more work for PHP7:
https://bugs.php.net/bug.php?id=71187

I'm desperatly trying to find a way to prevent my usercaches from being deleted upon App Pool recycling. 

I'm currently on a Windows 2008 Server with IIS as web server, and want to use win cache as a long term cache for specific MySQL-results. I have my own handlers to invalidate those caches, and pretty much just want to keep these until the app triggers the invalidation. 

On my development machine I'm running a LAMP-stack and with APC there's simply not that problem at all. Is there any way I can replicate this behavior with IIS? 

If I'm not completely mistaken there's a default recycling of idle pools which I can adjust, but there's still the matter of "global" recycling of pools every 24th hour or so.

Any suggestions?