opcache crashes on high volume IIS servers (Windows)

Description

There is no way to reproduce the bug with code.
The sneakiest thing is that everything works as it should, but opcache fails when the server load increases beyond a certain threshold.
I assume, but of course I'm not sure, because of the shared memory. This assumption derives from the fact that when it happens all the PHP (cgi) instances close unexpectedly (opcache's shared memory should be the only thing connecting them). I also tried to change the opcache memory model, but nothing changes.
Furthermore, in 99% of the cases no error is visible on the Windows events, but obviously on the IIS user side it shows a 500 error.

The only way I've found to reproduce the bug is to overload a test server (with the same configuration as the production server), after some time (usually a few minutes), all PHP instances close and occasionally I see an error similar to this:

Faulting application name: php-cgi.exe, version: 8.0.28.0, time stamp: 0x63eb7b04
Faulting module name: php_opcache.dll, version: 8.0.28.0, time stamp: 0x63eb7e4f
Exception code: 0xc0000005
Fault offset: 0x0000000000168011
Faulting process id: 0x1f2c
Faulting application start time: 0x01d9d3b2249e086e
Faulting application path: /path/to/php-cgi.exe
Faulting module path: /path/to/php_opcache.dll
Report Id: de8f6365-8a29-4f20-b3cf-d2d160d39508
Faulting package full name: 
Faulting package-relative application ID: 

I got proof that the cause is linked to opcache overloading the same server after disabling opcache. The server becomes (obviously) very slow, but no PHP instances crash even after 1 hour.

PHP Version

Both TS and NTS, PHP 8.0.28 + PHP 8.0.29 + (PHP 8.0.?)

Operating System

Windows Server 2022 Datacenter

Commencez par reproduire le plantage sous charge soutenue sur IIS avec Windows Server 2022 et PHP 8.0.28 ou 8.0.29, en comparant les configurations TS et NTS. Vérifiez le rapport d’erreur Windows pour php-cgi.exe et php_opcache.dll, puis comparez le comportement avec OPcache désactivé. Le travail est considéré comme terminé lorsque la cause du problème est isolée et que la même charge de travail ne fait plus planter les instances de PHP.