Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

Firstly, please try to disable xdebug. And, which opcache build do you use? Does 
it crash when fastcgi doesn't run simultaneously on the same machine? Please look 
at the link above about howto produce a backtrace.

Thread 0 - System ID 3728
Entry point   php!mainCRTStartup 
Create time   7/15/2013 11:07:13 AM 
Time spent in user mode   0 Days 0:0:1.216 
Time spent in kernel mode   0 Days 0:0:0.249 






Full Call Stack



Function     Arg 1     Arg 2     Arg 3     Arg 4   Source 
ntdll!NtRaiseException+12     00abf4b4     00abf504     00000000     00000000    
ntdll!RtlReportException+20     00abf4b4     00abf504     00000000     00abf9e0    
ntdll!RtlpTerminateFailureFilter+14     c0000374     00abf3b4     776e73bc     00000000    
ntdll!RtlReportCriticalFailure+67     00000000     00abf9e0     7769cfc0     00abf3c8    
ntdll!_EH4_CallFilterFunc+12     00000000     00000000     00000000     00abf4b4    
ntdll!_except_handler4+8e     fffffffe     00abf9d0     00abf504     00abf488    
ntdll!ExecuteHandler2+26     00abf4b4     00abf9d0     00abf504     00abf488    
ntdll!ExecuteHandler+24     00abf4b4     00abf9d0     00abf504     00abf488    
ntdll!RtlDispatchException+127     00abf4b4     00abf504     00abf4b4     00abf504    
ntdll!KiUserExceptionDispatcher+f     00abf4b4     00abf504     00abf4b4     00abf504

Do I do that correctly?

Well, that's a backtrace. Unfortunately it contains nothing about PHP. If that's 
the BT you only get, that's most likely not opcache. 

And what about the other questions i've asked - xdebug disabled? Does 
it crash when fastcgi doesn't run simultaneously on the same machine? Please try 
just one cli process.

Yes, with XDebug disabled, it still crashes.

I'm using the php_opcache.dll that is bundled with 5.5 NTS from the windows binaries site.

Yes, it still crashes with FastCGI not running (IIS stopped.)

If I disable opcache (opcache.enable_cli=0), it does not crash, if I enable (opcache.enable_cli=1), it crashes. How could that not be opcache causing the problem? We've been using wincache for years on the command line and have had no issues. What are we supposed to do? Abandon the use of opcache?

Ah, me ... php!mainCRTStartup it is ... i'm grieved. Did you load the debug 
symbols? You might get a better backtrace. As this one is really unusable, that's 
why it has confused me at the start.

Ok, now I think I'm loading the symbols (thought I was before, but maybe not), but I still don't know for sure if I'm doing it right.

Though, this one is slightly different:

Thread 0 - System ID 740
Entry point   php!sapi_cli_single_write+88e6 
Create time   7/16/2013 11:39:19 AM 
Time spent in user mode   0 Days 0:0:0.15 
Time spent in kernel mode   0 Days 0:0:0.62 






Full Call Stack



Function     Arg 1     Arg 2     Arg 3     Arg 4   Source 
ntdll!NtRaiseException+12     00b5f354     00b5f3a4     00000000     00000000    
ntdll!RtlReportException+20     00b5f354     00b5f3a4     00000000     00b5f880    
ntdll!RtlpTerminateFailureFilter+14     c0000374     00b5f254     774073bc     00000000    
ntdll!RtlReportCriticalFailure+67     00000000     00b5f880     773bcfc0     00b5f268    
ntdll!_EH4_CallFilterFunc+12     00000000     00000000     00000000     00b5f354    
ntdll!_except_handler4+8e     fffffffe     00b5f870     00b5f3a4     00b5f328    
ntdll!ExecuteHandler2+26     00b5f354     00b5f870     00b5f3a4     00b5f328    
ntdll!ExecuteHandler+24     00b5f354     00b5f870     00b5f3a4     00b5f328    
ntdll!RtlDispatchException+127     00b5f354     00b5f3a4     00b5f354     00b5f3a4    
ntdll!KiUserExceptionDispatcher+f     00b5f354     00b5f3a4     00b5f354     00b5f3a4

Sadly the BT isn't usable. Normally it should start somewhere in kernel, go 
through main and include some php call stack, like in the first section on this 
page http://bugs.php.net/bugs-generating-backtrace-win32.php . You seem to export 
some partial BT.

Thanks.

I guessed as much. Am I doing something wrong?

Ok, this morning on my home machine I got some very strange behavior. First, when running PHP using CLI it was crashing as soon as the script launched(not at the end as before.) This occurred every single time. On a whim, I restarted IIS (mind you, even though IIS was running on this machine, that site had not been used in 2 days), and the crashing at the beginning stopped. Now, it does not crash at the end, however, it does take a LONG time to shutdown - meaning, the script is complete (the test script is simply sleep(3);) and yet, the script does not exit for about 15 seconds.

So, I tested it on my work machine - same behavior. Let me get one of my other developers to test.

My teammate can confirm, still crashes after iisreset. Mine is not crashing on either machine this morning, but takes way too long to exit.

Never mind the comments about not crashing. I guess the debugger I installed now runs all of the time? That is the slow exit, the debugger capturing the crash.

So, behavior is still the same. How do I get a better backtrace?

So, what can I do to help move this along? This makes 5.5 unusable for us.

Eric has created another bug for this same issue: https://bugs.php.net/bug.php?id=65338 (his more accurately describes the actual problem.)

see bug #65338

I can confirm that Eric's patch in https://bugs.php.net/bug.php?id=65338 works.