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.

btw, I think it probably relates to YAML, could you try with out it? (like use a pure php implementation of Yaml instead ext)

I've removed YAML from my php.ini and replaced the necessary functions with the Symfony/YAML parser. It is definitely more stable, but still crashes in 10% of the cases at the exact same location.

Except Wincache, this PHP 7.0.2 installation is vanilla.

Also I can only manage to make it crash if I reload a certain page that does array-value manipulations like this:

// Assign specific display parameters to each price
foreach ($prices as &$prc)
{
	$price = $prc[$_SESSION['GEO']['CURRENCY']];
	$price = $price < 79? ceil($price) : floor($price);

	$prc['PRICE'] = number_format($price, 0, $prdDisp['DECIMAL'], $prdDisp['THOU']);

	// Christmas pricing active?
	if ($this->config['B_CHRISTMAS_PRICES'])
	{
		$prc['OLD_PRICE'] = $prc['PRICE'];

		$price = $prc[$_SESSION['GEO']['CURRENCY'] . '_SPEC'];
		$price = $price < 79? ceil($price) : floor($price);

		$prc['PRICE'] = number_format($price, 0, $prdDisp['DECIMAL'], $prdDisp['THOU']);
	}
}

// Assign various properties to products
foreach ($products as &$prd)
{
	// Slug
	$prd['SLUG'] = trim(preg_replace('/[^a-z0-9-]+/', '-', strtolower($prd['DISPLAY_NAME'])), "-");

	// Price
	$price = $prices[$prd['PRICE_CATEGORY']];
	if ($price['PRICE'] != '0')
	{
		$prd['PRICE'] = $price['PRICE'];
		if ($price['OLD_PRICE'])
		{
			$prd['OLD_PRICE'] = $price['OLD_PRICE'];
		}
		$prd['CURRENCY'] = $prdDisp['SYMBOL'];
	}

	// Age
	$prd['NEW'] = (time() - strtotime($prd['RELEASEDATE'])) < (90 * 24 * 60 * 60);
}

As you can see, I add new array-elements in the foreach loop and I work on references instead of the values.

If I comment this code out, then (even with the yaml.dll) the website get's a LOT more stable.

@michael thanks for the follow up. Were it possible you to extract a small reproduce case? A backtrace or a core dump could be very helpful, too. Please exclude any non core extensions while doing that.

Thanks.

I wish I could send you a short script that causes it, but it seems everything "simple" just works.

This website uses AltoRouter, Twig and some custom functions (mainly Twig extensions) to render our website.

How do I create the core-dump or a complete backtrace? Keep in mind, I can't run this in the command-line.

My offer that somebody trustworthy does a remote-desktop session and works on my computer directly still stands.

On creating core dumps, an info is here https://bugs.php.net/bugs-generating-backtrace-win32.php or here https://msdn.microsoft.com/en-us/library/windows/desktop/bb787181%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396 .

I would see RDP to your machine as not very rational, as you most likely miss all the tools needed to debug and develop the PHP core on Windows. So quite some time would be needed for setups, etc. Please lets see what we have in the dumps (be sure there's no sensitive information in there before posting).

Thanks.

I've created a full crash-dump. It's 187 MB. Even with simple ZIP compression I get it down to 18 MB. Or is a mini-crash dump enough?

How do you want me to submit that file?

I've used the DebugDiag Analysis tool to get the backtrace:

ntdll!NtWaitForMultipleObjects+14    
KERNELBASE!WaitForMultipleObjectsEx+ef    
KERNELBASE!WaitForMultipleObjects+e    
kernel32!WerpReportFaultInternal+4ab    
kernel32!WerpReportFault+52    
KERNELBASE!UnhandledExceptionFilter+277    
ntdll!RtlUserThreadStart$filt$0+3e    
ntdll!_C_specific_handler+96    
ntdll!RtlpExecuteHandlerForException+d    
ntdll!RtlDispatchException+3a9    
ntdll!KiUserExceptionDispatch+3a    
php7!zend_mm_gc+6e [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_alloc.c @ 1891]   c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_alloc.c @ 1891 
php7!zend_mm_alloc_huge+96 [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_alloc.c @ 1761 + 8]   c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_alloc.c @ 1761 + 8 
php7!_emalloc+32ffcd [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_alloc.c @ 2442 + 12]   c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_alloc.c @ 2442 + 12 
php7!ZEND_CONCAT_SPEC_TMPVAR_TMPVAR_HANDLER+355021 [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_vm_execute.h @ 44492]   c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_vm_execute.h @ 44492 
php7!execute_ex+62 [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_vm_execute.h @ 417 + 5]   c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_vm_execute.h @ 417 + 5 
php7!zend_call_function+355dcd [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_execute_api.c @ 861]   c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_execute_api.c @ 861 
php7!php_array_user_key_compare+cc [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\ext\standard\array.c @ 1122 + 26]   c:\php-sdk\php70dev\vc14\x64\php-7.0.2\ext\standard\array.c @ 1122 + 26 
php7!zend_sort+1d8 [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_sort.c @ 351 + f]   c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_sort.c @ 351 + f 
php7!zend_sort+282 [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_sort.c @ 371]   c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_sort.c @ 371 
php7!zend_hash_sort_ex+85 [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_hash.c @ 2256]   c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_hash.c @ 2256 
php7!php_usort+179 [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\ext\standard\array.c @ 1060 + 8]   c:\php-sdk\php70dev\vc14\x64\php-7.0.2\ext\standard\array.c @ 1060 + 8 
php7!ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER+35609e [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_vm_execute.h @ 723]   c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_vm_execute.h @ 723 
php7!execute_ex+62 [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_vm_execute.h @ 417 + 5]   c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_vm_execute.h @ 417 + 5 
php7!zend_execute+16c [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_vm_execute.h @ 459]   c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_vm_execute.h @ 459 
php7!zend_execute_scripts+119 [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend.c @ 1428]   c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend.c @ 1428 
php7!php_execute_script+463 [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\main\main.c @ 2471 + 1b]   c:\php-sdk\php70dev\vc14\x64\php-7.0.2\main\main.c @ 2471 + 1b 
php_cgi!main+117a [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\sapi\cgi\cgi_main.c @ 2492]   c:\php-sdk\php70dev\vc14\x64\php-7.0.2\sapi\cgi\cgi_main.c @ 2492 
php_cgi!__scrt_common_main_seh+124 [f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl @ 264 + 22]   f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl @ 264 + 22 
kernel32!BaseThreadInitThunk+22    
ntdll!RtlUserThreadStart+34

Thanks for the backtrace. The analyze shows, that it might be a GC bug while executing some userspace sort functions (like usort, uksort, etc.). Could you please check the places in your code?

Also, please try to rerun PHP with environment variable USE_ZEND_ALLOC=0 set to the PHP environment (fe can be added to the FCGI options in IIS).

Thanks.

I've added USE_ZEND_ALLOC=0 as the environment variables for the FCGI process in IIS and now it's much less table. It crashes 80% of the time.

Here is the new backtrace of that crash:

ntdll!NtWaitForMultipleObjects+14    
ntdll!RtlReportExceptionEx+480    
ntdll!RtlReportException+c3    
ntdll!RtlReportCriticalFailure$filt$0+33    
ntdll!_C_specific_handler+96    
ntdll!_GSHandlerCheck_SEH+76    
ntdll!RtlpExecuteHandlerForException+d    
ntdll!RtlDispatchException+3a9    
ntdll!RtlRaiseException+324    
ntdll!RtlReportCriticalFailure+8c    
ntdll!RtlpHeapHandleError+12    
ntdll!RtlpLogHeapFailure+96    
ntdll!RtlpReAllocateHeapInternal+8fda5    
ntdll!RtlReAllocateHeap+31    
AcLayers!NS_FaultTolerantHeap::APIHook_RtlReAllocateHeap+31f4    
ucrtbase!realloc+3d    
php7!_erealloc+347d58 [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_alloc.c @ 2468 + 8]
php7!ZEND_CONCAT_SPEC_TMPVAR_TMPVAR_HANDLER+97 [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_vm_execute.h @ 44487]
php7!execute_ex+62 [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_vm_execute.h @ 417 + 5]
php7!zend_call_function+355dcd [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_execute_api.c @ 861]
php7!php_array_user_key_compare+cc [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\ext\standard\array.c @ 1122 + 26]
php7!zend_sort+11e [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_sort.c @ 334 + d]
php7!zend_hash_sort_ex+85 [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_hash.c @ 2256]
php7!php_usort+179 [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\ext\standard\array.c @ 1060 + 8]
php7!ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER+35609e [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_vm_execute.h @ 723]
php7!execute_ex+62 [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_vm_execute.h @ 417 + 5]
php7!zend_execute+16c [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_vm_execute.h @ 459]
php7!zend_execute_scripts+119 [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend.c @ 1428]
php7!php_execute_script+463 [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\main\main.c @ 2471 + 1b]
php_cgi!main+117a [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\sapi\cgi\cgi_main.c @ 2492]
php_cgi!__scrt_common_main_seh+124 [f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl @ 264 + 22]
ntdll!RtlUserThreadStart+34

I will try to create a tiny script that creates a small array, modifies it via references in a foreach loop and then calls usort()/uksort() to provoke the crash.

Please don't close this.

Good news. Today a new version of Wincache was released (2.0.5) and after updating the crashes are gone!

So it seems that Wincache was corrupting memory!

Sorry for the wild goose chase.

Issue resolved.