Home/ Questions/Q 7553411
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-30T11:02:47+00:00

Hi I am getting a fault in a php application leading sometimes to an

  • 0

Hi I am getting a fault in a php application leading sometimes to an error in the event log as such:

Faulting application name: php-cgi.exe, version: 5.3.6.0, time stamp: 0x4d81eb28
Faulting module name: php5.dll, version: 5.3.6.0, time stamp: 0x4d81ebdc
Exception code: 0xc0000005

And at other times a fast-cgi error with no event logged error (can browse on local server):

C:\Program Files (x86)\PHP\v5.3\php-cgi.exe – The FastCGI process exited unexpectedly

In this case although no error is logged to the event log the following 2 entries always follow directly after the fault:

Listener Adapter protocol ‘net.pipe’ successfully connected to Windows Process Activation Service.
Listener Adapter protocol ‘net.tcp’ successfully connected to Windows Process Activation Service.

There is seemingly no logic as to which way the application faults and how it is logged, but it will always be one or the other, and obviously they are related.

Our application is relatively complex, but the only difference between running fine or not running fine is a change to a dataset which may cause different numbers to be formatted in some routines.

If I attach XDebug (PHP Storm) and trace the execution, it completes without issue.
If I run without tracing through, one of the above fault scenarios becomes evident.

Can anyone explain this behaviour with the information I have given, especially why attaching the debugger and tracing through the application prevents the issue?

How would you debug this?

Thanks.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Our application generates a trace but due to the output buffer it was not displayed in the case of a fault.

    So ensuring that each line of the trace displays time and memory usuage we :

    1. output trace to a file, line by line.
    2. compare trace’s of various executions for patterns.

    In my case the only pattern was memory consumption. Successful runs used less then 60mb, faulting runs used higher than 60mb.

    The application pool was not in support 32 bit application mode, making the switch to 32bit mode halved the memory consumption, and everything now runs as before.

    Incidently php has no memory limit set in the php.ini, the same as the app pool so I would guess this was/is a pointer issue, but just happy to be moving forwards again.

    • 0