php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #78125 Persistent php-cgi.exe access fault
Submitted: 2019-06-07 19:45 UTC Modified: 2019-06-27 16:52 UTC
From: aschmidt at anamera dot net Assigned: cmb (profile)
Status: Closed Package: opcache
PHP Version: 7.3.7RC3 OS: Win x64
Private report: No CVE-ID: None
 [2019-06-07 19:45 UTC] aschmidt at anamera dot net
Description:
------------
After upgrading from 7.2.18 to 7.2.19:
"php-cgi.exe - Application Error : The instruction at 0xa522405a referenced memory at 0xffffffff. The memory could not be read." in event log.

This can be circumvented by:

a) Disabling OPcache for 7.2.19
b) Reverting 7.2.18 (with OPcache running)

Version=1
EventType=APPCRASH
EventTime=132044083798735470
ReportType=2
Consent=1
UploadTime=132044083800926965
ReportIdentifier=43296537-8958-11e9-8115-000c29fea50b
IntegratorReportIdentifier=43296536-8958-11e9-8115-000c29fea50b
NsAppName=php-cgi.exe
Response.BucketId=71ba2ba01cc178505d2a5f4840151c51
Response.BucketTable=4
Response.LegacyBucketId=2101596940039167057
Response.type=4
Sig[0].Name=Application Name
Sig[0].Value=php-cgi.exe
Sig[1].Name=Application Version
Sig[1].Value=7.2.19.0
Sig[2].Name=Application Timestamp
Sig[2].Value=5cee90f4
Sig[3].Name=Fault Module Name
Sig[3].Value=php7.dll
Sig[4].Name=Fault Module Version
Sig[4].Value=7.2.19.0
Sig[5].Name=Fault Module Timestamp
Sig[5].Value=5cee9854
Sig[6].Name=Exception Code
Sig[6].Value=c0000005
Sig[7].Name=Exception Offset
Sig[7].Value=000000000004405a
DynamicSig[1].Name=OS Version
DynamicSig[1].Value=6.3.9600.2.0.0.400.8
DynamicSig[2].Name=Locale ID
DynamicSig[2].Value=1033
DynamicSig[22].Name=Additional Information 1
DynamicSig[22].Value=9d04
DynamicSig[23].Name=Additional Information 2
DynamicSig[23].Value=9d04afd8fe818683e8ff19df16b47b8a
DynamicSig[24].Name=Additional Information 3
DynamicSig[24].Value=300e
DynamicSig[25].Name=Additional Information 4
DynamicSig[25].Value=300ed11c1f854278d1457f50e24df3a6
UI[2]=C:\Program Files\PHP\v7.2\php-cgi.exe
LoadedModule[0]=C:\Program Files\PHP\v7.2\php-cgi.exe
LoadedModule[1]=C:\Windows\SYSTEM32\ntdll.dll
LoadedModule[2]=C:\Windows\system32\KERNEL32.DLL
LoadedModule[3]=C:\Windows\system32\KERNELBASE.dll
LoadedModule[4]=C:\Program Files\PHP\v7.2\php7.dll
LoadedModule[5]=C:\Windows\system32\WS2_32.dll
LoadedModule[6]=C:\Windows\system32\ADVAPI32.dll
LoadedModule[7]=C:\Windows\SYSTEM32\VCRUNTIME140.dll
LoadedModule[8]=C:\Windows\SYSTEM32\api-ms-win-crt-stdio-l1-1-0.dll
LoadedModule[9]=C:\Windows\SYSTEM32\api-ms-win-crt-environment-l1-1-0.dll
LoadedModule[10]=C:\Windows\SYSTEM32\api-ms-win-crt-heap-l1-1-0.dll
LoadedModule[11]=C:\Windows\SYSTEM32\api-ms-win-crt-string-l1-1-0.dll
LoadedModule[12]=C:\Windows\SYSTEM32\api-ms-win-crt-runtime-l1-1-0.dll
LoadedModule[13]=C:\Windows\SYSTEM32\api-ms-win-crt-convert-l1-1-0.dll
LoadedModule[14]=C:\Windows\SYSTEM32\api-ms-win-crt-filesystem-l1-1-0.dll
LoadedModule[15]=C:\Windows\SYSTEM32\api-ms-win-crt-math-l1-1-0.dll
LoadedModule[16]=C:\Windows\SYSTEM32\api-ms-win-crt-locale-l1-1-0.dll
LoadedModule[17]=C:\Windows\system32\ole32.dll
LoadedModule[18]=C:\Windows\SYSTEM32\DNSAPI.dll
LoadedModule[19]=C:\Windows\SYSTEM32\bcrypt.dll
LoadedModule[20]=C:\Windows\SYSTEM32\api-ms-win-crt-time-l1-1-0.dll
LoadedModule[21]=C:\Windows\SYSTEM32\api-ms-win-crt-utility-l1-1-0.dll
LoadedModule[22]=C:\Windows\system32\NSI.dll
LoadedModule[23]=C:\Windows\system32\RPCRT4.dll
LoadedModule[24]=C:\Windows\system32\msvcrt.dll
LoadedModule[25]=C:\Windows\SYSTEM32\sechost.dll
LoadedModule[26]=C:\Windows\SYSTEM32\combase.dll
LoadedModule[27]=C:\Windows\system32\GDI32.dll
LoadedModule[28]=C:\Windows\system32\USER32.dll
LoadedModule[29]=C:\Windows\system32\SspiCli.dll
LoadedModule[30]=C:\Windows\SYSTEM32\ucrtbase.DLL
LoadedModule[31]=C:\Windows\system32\bcryptprimitives.dll
LoadedModule[32]=C:\Program Files\PHP\v7.2\ext\php_opcache.dll
LoadedModule[33]=C:\Program Files\PHP\v7.2\ext\php_xdebug-2.7.2-7.2-vc15-nts-x86_64.dll
LoadedModule[34]=C:\Program Files\PHP\v7.2\ext\php_mysqli.dll
LoadedModule[35]=C:\Program Files\PHP\v7.2\ext\php_mbstring.dll
LoadedModule[36]=C:\Program Files\PHP\v7.2\ext\php_gd2.dll
LoadedModule[37]=C:\Program Files\PHP\v7.2\ext\php_gettext.dll
LoadedModule[38]=C:\Program Files\PHP\v7.2\ext\php_intl.dll
LoadedModule[39]=C:\Program Files\PHP\v7.2\icuuc63.dll
LoadedModule[40]=C:\Program Files\PHP\v7.2\icuin63.dll
LoadedModule[41]=C:\Program Files\PHP\v7.2\icuio63.dll
LoadedModule[42]=C:\Windows\SYSTEM32\MSVCP140.dll
LoadedModule[43]=C:\Program Files\PHP\v7.2\icudt63.dll
LoadedModule[44]=C:\Windows\SYSTEM32\api-ms-win-crt-multibyte-l1-1-0.dll
LoadedModule[45]=C:\Program Files\PHP\v7.2\ext\php_curl.dll
LoadedModule[46]=C:\Program Files\PHP\v7.2\libcrypto-1_1-x64.dll
LoadedModule[47]=C:\Program Files\PHP\v7.2\libssl-1_1-x64.dll
LoadedModule[48]=C:\Windows\system32\WLDAP32.dll
LoadedModule[49]=C:\Windows\system32\Normaliz.dll
LoadedModule[50]=C:\Program Files\PHP\v7.2\libssh2.dll
LoadedModule[51]=C:\Program Files\PHP\v7.2\nghttp2.dll
LoadedModule[52]=C:\Windows\system32\CRYPT32.dll
LoadedModule[53]=C:\Windows\system32\MSASN1.dll
LoadedModule[54]=C:\Program Files\PHP\v7.2\ext\php_exif.dll
LoadedModule[55]=C:\Program Files\PHP\v7.2\ext\php_xmlrpc.dll
LoadedModule[56]=C:\Program Files\PHP\v7.2\ext\php_openssl.dll
LoadedModule[57]=C:\Program Files\PHP\v7.2\ext\php_soap.dll
LoadedModule[58]=C:\Program Files\PHP\v7.2\ext\php_pdo_mysql.dll
LoadedModule[59]=C:\Program Files\PHP\v7.2\ext\php_pdo_sqlite.dll
LoadedModule[60]=C:\Program Files\PHP\v7.2\ext\php_imap.dll
LoadedModule[61]=C:\Windows\SYSTEM32\WINMM.dll
LoadedModule[62]=C:\Windows\SYSTEM32\Secur32.dll
LoadedModule[63]=C:\Windows\SYSTEM32\api-ms-win-crt-conio-l1-1-0.dll
LoadedModule[64]=C:\Windows\SYSTEM32\WINMMBASE.dll
LoadedModule[65]=C:\Windows\SYSTEM32\cfgmgr32.dll
LoadedModule[66]=C:\Windows\SYSTEM32\DEVOBJ.dll
LoadedModule[67]=C:\Program Files\PHP\v7.2\ext\php_tidy.dll
LoadedModule[68]=C:\Program Files\PHP\v7.2\ext\php_xsl.dll
LoadedModule[69]=C:\Program Files\PHP\v7.2\ext\php_yaml.dll
LoadedModule[70]=C:\Program Files\PHP\v7.2\ext\php_fileinfo.dll
LoadedModule[71]=C:\Program Files\PHP\v7.2\ext\php_componere.dll
LoadedModule[72]=C:\Program Files\PHP\v7.2\ext\php_win32service.dll
LoadedModule[73]=C:\Program Files\PHP\v7.2\ext\php_wincache.dll
LoadedModule[74]=C:\Windows\system32\mswsock.dll
LoadedModule[75]=C:\Windows\System32\rasadhlp.dll
LoadedModule[76]=C:\Windows\SYSTEM32\IPHLPAPI.DLL
LoadedModule[77]=C:\Windows\SYSTEM32\WINNSI.DLL
LoadedModule[78]=C:\Windows\System32\fwpuclnt.dll
State[0].Key=Transport.DoneStage1
State[0].Value=1
FriendlyEventName=Stopped working
ConsentKey=APPCRASH
AppName=CGI // FastCGI
AppPath=C:\Program Files\PHP\v7.2\php-cgi.exe
NsPartner=windows
NsGroup=windows8
ApplicationIdentity=9C05B8417893E8F29D519DF0DFA49EA3



Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2019-06-08 07:32 UTC] krakjoe@php.net
-Status: Open +Status: Feedback
 [2019-06-08 07:32 UTC] krakjoe@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.


 [2019-06-09 12:38 UTC] aschmidt at anamera dot net
-Status: Feedback +Status: Open
 [2019-06-09 12:38 UTC] aschmidt at anamera dot net
The problem occurs when a minimal "phpinfo();" script is executed in IIS.

However it APPEARS to only occur when both a CLI and a FastCGI application are running at the same time under 7.2.19 with OpCache enabled. I have a CLI application running as a Windows Service. After upgraded to 7.2.19 I first started IIS to get my site running again, but then the Windows Service would not start the CLI app. Baffled, I rebooted the server, which automatically starts the service. I confirmed that NOW the service WAS running. I then started IIS by hand - and whenever I run a basic phpinfo() THAT would now crash.

I then stopped the service and IIS, reverted to 7.2.18 (without rebooting) and was aber to start both without problems. With that knowledge, I downloaded 7.2.19 one more time (in case of any download errors), copied it over 7.2.18 again, started the service by hand, and reproduced the IIS error. Finally, I disabled OPcache in 7.2.19 and NOW IIS was successfully running FastCGI in parallel with the CLI Service.

Here the most relevant of my PHP.INI settings:

precision = 14
zlib.output_compression = Off
serialize_precision = -1
zend.enable_gc = On
report_memleaks = On
auto_globals_jit = On
enable_dl = Off
zend.assertions = -1
opcache.enable=1
opcache.enable_cli=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=3907

opcache.revalidate_freq=30	
;(per IIS .user.ini: opcache.revalidate_freq=0 )

opcache.enable_file_override=1
opcache.log_verbosity_level=2
opcache.file_cache=C:\Windows\Temp\PHP\OpCache
opcache.file_update_protection=10 
cgi.force_redirect=0
cgi.fix_pathinfo=1
fastcgi.impersonate=1
fastcgi.logging=1

[ExtensionList]
extension=php_mysqli.dll
extension=php_mbstring.dll
extension=php_gd2.dll
extension=php_gettext.dll
extension=php_intl.dll
extension=php_curl.dll
extension=php_exif.dll
extension=php_xmlrpc.dll
extension=php_openssl.dll
extension=php_soap.dll
extension=php_pdo_mysql.dll
extension=php_pdo_sqlite.dll
extension=php_imap.dll
extension=php_tidy.dll
extension=php_xsl.dll
extension=php_yaml.dll
extension=php_fileinfo.dll

extension=php_componere.dll
extension=php_win32service.dll
zend_extension=php_opcache.dll

[XDebug]
; Must be loaded after OpCache !
zend_extension = "C:\Program Files\PHP\v7.2\ext\php_xdebug-2.7.2-7.2-vc15-nts-x86_64.dll"
xdebug.coverage_enable=0

[PHP_WINCACHE]
extension=php_wincache.dll
wincache.reroute_enabled=1
wincache.fcachesize=32
wincache.maxfilesize=512
session.save_handler=wincache
 [2019-06-14 18:07 UTC] cmb@php.net
-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb
 [2019-06-14 18:07 UTC] cmb@php.net
Can you please try the latest snapshot[1]?

[1] <https://windows.php.net/downloads/snaps/php-7.2/r28808ca/>
 [2019-06-14 21:21 UTC] aschmidt at anamera dot net
-Status: Feedback +Status: Assigned -PHP Version: 7.2.19 +PHP Version: 7.2.21-dev
 [2019-06-14 21:21 UTC] aschmidt at anamera dot net
Problem 1 (persistent):

<?php phpinfo( $_GET[ 'i' ] ?? INFO_ALL ); ?>

Will work in IIS for all INFO_* values EXCEPT for INFO_MODULES.
phpinfo( 8 ) will fail in PHP.

However, opcache.php will work fine - and my own scripts seem to work.

Also, executing same phpinfo() in CLI runs without apparent problems.

Problem 2 (one-time):

Initially, after installing 7.2.21-dev, I had restarted the PHP-CLI background application is running first (as a Windows Service) and THEN IIS PHP. This result in FASTCGI crashing with these event log entries occur:

Zend OPcache, Event ID 2:
Unable to open base address file
The system cannot find the file specified.

Problem 3 (persistent):

If I REBOOT Windows Server, then IIS will start and run (with the exception of phpinfo() ), BUT, I am now unable to start the PHP-CLI service. 

If I STOP IIS, THEN I can start the PHP-CLI service.

This problem can be circumvented with 
opcache.enable_cli=0.


In summary:
There STILL appears to be a concurrency problem with OPcache FastCGI and CLI active at the same time.
And I there is a problem with OPcache and phpinfo(8) in IIS.
 [2019-06-14 21:41 UTC] aschmidt at anamera dot net
PS: 
The phpinfo() error results in php-cgi ending with Windows error 
ERROR_INVALID_DATA (0x8007000D)
 [2019-06-15 00:00 UTC] aschmidt at anamera dot net
I have spent more time narrowing down the problem with concurrent OPcache in php-cli vs. IIS FastCGI. Hopefully this will make sense to you.

First:
1. the original problem with the php-cgi.exe access fault does seem resolved.
2. the phpinfo() problem did NOT happen with 7.2.18.
3. but, the concurrency problem with php-cli vs. FastCGI ALSO happens with 7.2.18, so it is does NOT be have been caused by 7.2.19 (sorry...)

Here is what I found out regarding the OPcache running php-cli and FastCGI - and it seems to center around the ZendOPcache.MemoryBase@someuserid@somehash file.

a. OPcache IGNORES the PHP.ini "sys_temp_dir" value!
b. OPcache will rely on the TEMP or TMP environment variable - which CAN be user specific!
c. If IIS starts first, with the AppPool using set to identify "UserX", then IIS will create/update a file in C:\Windows\Temp\ZendOPcache.MemoryBase@UserX@somehash.
d. Any attempt to manually start a php-cli service also configured run der user "UserX" will not run.
e. If you now SHUT DOWN IIS, then you can start the service. OPcache will now use the User's environment to create C:\Users\UserX\AppData\Local\Temp\ZendOPcache.MemoryBase@UserX@somehash.
f. NOW you can restart IIS and both FastCGI and php-cli will run concurrently.

There are TWO ways to work around this issue:
1. either: opcache.enable_cli=0
2. or: Set the service to start automatically at boot (ONLY, if NOT set it to automatically start "delayed")

Im summary:
I suspect is an issue with how OPcache manages that MemoryBase file, or in which User vs. System Temp folder it creates that file, specially if multiple processes run under the same Windows UserID (but one running under IIS impersonation).
 [2019-06-15 08:12 UTC] cmb@php.net
Thanks for the further investigation!

> OPcache IGNORES the PHP.ini "sys_temp_dir" value!

Indeed.  On Windows it uses GetTempPath() instead.

On Windows, Opcache has a single Opcache instance (shared memory)
per User and PHP version.  To manage this instance, it uses the
MemoryBase file.  In the given case, starting FCGI for the first
time will create the Opcache instance, and the MemoryBase file
like you have described.  When the CLI service is started, the
Opcache instance is found, but attaching is not possible, because
the MemoryBase file is not found, so the process terminates.
Shutting down FCGI will cause the Opcache instance to be destroyed.
Afterwards the CLI service can be started, and it creates a new
Opcache instance and MemoryBase file.  If FCGI is started
afterwards, the Opcache instance is found, and the old MemoryBase
file as well, so attaching is successful if the contents of both
MemoryBase files are identical.

> There are TWO ways to work around this issue:

If I'm not mistaken, there is at least a third work-around, namely
to copy FCGI's MemoryBase file to where the CLI process expects
it, before starting the CLI process.

It might be worthwhile to pursue fixing this (i.e. use the same
MemoryBase file), but perhaps a better alternative might be to
facilitate to actually have multiple Opcache instances per user
and PHP version when needed.  There is a draft[1], but it is not
yet sufficiently tested.

To avoid confusion: most of the explanations above refer to
Opcache on Windows only, and they are rather simplified.

[1] <https://github.com/cmb69/php-src/tree/opcache.cache_id>
 [2019-06-18 05:37 UTC] aschmidt at anamera dot net
-PHP Version: 7.2.21-dev +PHP Version: 7.3.8-dev
 [2019-06-18 05:37 UTC] aschmidt at anamera dot net
Just also tested 7.3.6 up to 7.3.8-dev. BOTH problems are open:

a) the php-cgi crashes whenever OPcache is enabled! 

b) phpinfo(8) crashes unconditionally, but phpinfo(55) will work.

So at this point, there appears that neither the current, nor any upcoming version supports OPcache under Windows - and I'm worried that phpinfo(8) is failing?
 [2019-06-18 08:14 UTC] cmb@php.net
-Status: Assigned +Status: Feedback
 [2019-06-18 08:14 UTC] cmb@php.net
Thanks for further checking!  I have some further questions which
may help to localize the problem:

* Did neither of the two issues occur with 7.3.5?

* Which exact revision of 7.3.8-dev did you test?  Was it
  r9f0515c?

* Can you reproduce the two issues without Xdebug and Wincache?

* What happens when you run FCGI and the CLI service under
  different user accounts?
 [2019-06-19 00:07 UTC] aschmidt at anamera dot net
-Status: Feedback +Status: Assigned
 [2019-06-19 00:07 UTC] aschmidt at anamera dot net
phpinfo( 8 ) FAILS with php-7.3-nts-windows-vc15-x64-r11b354d
- even without OPcache, Wincache
but WORKS fine with php 7.3.6

(So the same phpinfo(8) problem as with 7.2, fails after 7.2.19).


Concurrent php-cli and php-cgi with OPcache crashes:
php-7.3-nts-windows-vc15-x64-r11b354d
7.3.6, 7.3.5, 7.3.4
It does NOT matter if wincache extension is removed. 


However, concurrent php-cli and php-cgi WORKS with wincache in all those 7.3.x, as soon as OPcache is removed.

Sorry - testing with different permissions/users is not practical, because the php-cli service and the php-cgi web site rely on certain network shares that require certain privileges.
 [2019-06-19 00:19 UTC] aschmidt at anamera dot net
The most functional environment is:
7.3.6 or 7.2.19
WITH WinCache
WITH OpCache
BUT opcache.enable_cli=0   !!!

In THAT combination:
- php-cli will work (uncached), 
- php-cgi will work (cached), 
- phpinfo(8) will work.
 [2019-06-25 08:42 UTC] cmb@php.net
-Status: Assigned +Status: Feedback
 [2019-06-25 08:42 UTC] cmb@php.net
Please try with PHP 7.3.7RC3 (<https://windows.php.net/qa/#php-7.3>).
 [2019-06-25 16:35 UTC] aschmidt at anamera dot net
-Status: Feedback +Status: Assigned -PHP Version: 7.3.8-dev +PHP Version: 7.3.7RC3
 [2019-06-25 16:35 UTC] aschmidt at anamera dot net
The php-cgi.exe access fault no longer occurs, even if
opcache.enable_cli=1
opcache.enable=1
Thank you for that.

I took the time and disabling/enabling extension one at a time.
The module that causes the phpinfo(8) crash in your recent PHP 7.3.x and 7.2.x builds is the win32service 4.0 extension (the production release of 2019-02-20).
(It doesn't matter if WinCache, OPcache, or xdebug are active or removed at the same time.)
 [2019-06-27 16:21 UTC] aschmidt at anamera dot net
-Status: Assigned +Status: Closed
 [2019-06-27 16:21 UTC] aschmidt at anamera dot net
FYI - the phpinfo() problem with php-cgi was due to the Win32Service extension garbling the Content-Type header. 

How now been fixed with Win32Service 0.4.1
 [2019-06-27 16:52 UTC] cmb@php.net
> The php-cgi.exe access fault no longer occurs, […]

Great!  Thanks for checking.

> How now been fixed with Win32Service 0.4.1

Also good news. :)
 
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Sun Dec 08 18:01:24 2019 UTC