Adding more info, we are also seeing these errors in the Windows Application log:

Source: Zend OPcache
Event ID: 487
Base address marks unusable memory region
Attempt to access invalid address.

Which seems to be the same issue or related to the one described here:
https://github.com/zendtech/ZendOptimizerPlus/issues/167
and in this php bug report:
https://bugs.php.net/bug.php?id=64926

Thanks for the report. Yes, it is the know issue that sometimes reattaching to SHM fails. 

In 7.0 the INI directive opcache.file_cache_fallback was added, to still make use of the file cache in this situation. In your configuration, opcache.file_cache= has no value, thus the fallback cannot work. Please set a valid path as a value and observe the happenings.

Thanks.

Thanks for responding.

I added these two directives:
opcache.file_cache_fallback=1
opcache.file_cache="path to a server writable directory"

Then recycled the app pool,
At first the page was not responding (blank) and the windows log generated an Event ID 487 for each request.

After doing another recycle php pages started responding again, but the ini settings are still not applied or changing.

I can verify that the app pool is recycled, as every time I do it the "Cache hits" counter resets itself to 0 an starts incrementing back up for each request to the phpinfo() page.


The new opcache.cache_file is still showing as undefined.
This is the output of phpinfo() after doing those changes:

Opcode Caching	Up and Running
Optimization	Enabled
SHM Cache	Enabled
File Cache	Disabled
Startup	OK
Shared memory model	win32
Cache hits	5
Cache misses	1
Used memory	9132712
Free memory	57976152
Wasted memory	0
Interned Strings Used memory	132024
Interned Strings Free memory	4062280
Cached scripts	1
Cached keys	2
Max keys	3907
OOM restarts	0
Hash keys restarts	0
Manual restarts	0
Directive	Local Value	Master Value
opcache.blacklist_filename	no value	no value
opcache.consistency_checks	0	0
opcache.dups_fix	Off	Off
opcache.enable	On	On
opcache.enable_cli	Off	Off
opcache.enable_file_override	Off	Off
opcache.error_log	no value	no value
opcache.fast_shutdown	0	0
opcache.file_cache	no value	no value
opcache.file_cache_consistency_checks	1	1
opcache.file_cache_fallback	1	1
opcache.file_cache_only	0	0
opcache.file_update_protection	2	2
opcache.force_restart_timeout	180	180
opcache.inherited_hack	On	On
opcache.interned_strings_buffer	4	4
opcache.log_verbosity_level	1	1
opcache.max_accelerated_files	2000	2000
opcache.max_file_size	0	0
opcache.max_wasted_percentage	5	5
opcache.memory_consumption	64	64
opcache.mmap_base	no value	no value
opcache.optimization_level	0xFFFFFFFF	0xFFFFFFFF
opcache.preferred_memory_model	no value	no value
opcache.protect_memory	0	0
opcache.restrict_api	no value	no value
opcache.revalidate_freq	2	2
opcache.revalidate_path	Off	Off
opcache.save_comments	1	1
opcache.use_cwd	On	On
opcache.validate_timestamps	On	On

Now, please be a bit more verbose. "SHM Cache	Enabled" means there was no fallback required, but the file_cache value is still empty in your latest posting. That means the file where you set the file cache directive was not read in, for some reasons.

What was in the event, same as before about the "invalid address"? If yes, that' s another sign the php.ini doesn't even got read in. Please check what is the path to your php.ini shown in the phpinfo page, and check that you properly set it for the PHP environment.

Maybe there a specific PHP code leading to this?

Anatol

Thank you!

I have solved the issue. Your recommended settings to add opcache.file_cache_fallback=1
opcache.file_cache=[dir] were correct.

They were not working because our ini file had a line break in the middle of a config statement breaking it, so only part of our php.ini settings were loading.

Great you consequently stayed on the investigation. Time to close the issue. File cache fallback is a new feature, so any feedback on it were much appreciated, especially bugs.

Thanks.