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.

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

Can you please try the latest snapshot[1]?

[1] <https://windows.php.net/downloads/snaps/php-7.2/r28808ca/>

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.

PS: 
The phpinfo() error results in php-cgi ending with Windows error 
ERROR_INVALID_DATA (0x8007000D)

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).

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>

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?

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?

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.

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.

Please try with PHP 7.3.7RC3 (<https://windows.php.net/qa/#php-7.3>).

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.)

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

> 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. :)