This looks like server misconfig at first glance. In the BT there is nothing about PHP. Combined with 
the fact you find nothing in the error log, it might be not PHP.

How did you get that BT? Debug symbols should be used for PHP as well. And when IIS starts, you should 
attach the debugger to the clean PHP fcgi process, so then debugger takes over.

Some more points before i go try it
- does the same happen when you out a plain text file instead of mpeg, also using appropriate content-
type and --limit-rate?
- does it happen when you request static content using wget with --limit-rate?
- please post the request/response headers

Thanks.

hi, 
thank you for reply.

- does the same happen when you out a plain text file instead of mpeg, also using appropriate content-type and --limit-rate?
i changed content-type to text/plain and renamed movie.mpg to movie.txt. No behaviour change. If i abort download i will also get a 500.

- does it happen when you request static content using wget with --limit-rate?
no, if i just download a file for example http://127.0.0.1/movie.mpg all works fine. Also if i abort download.


Please use following configuration:

Description
------------
- Installed a blank Windows Server 2008 R2 SP1 Standard, added Role IIS & Feature CGI.
- Extracted 5.5.1 VC11 x86 Non Thread Safe to c:\Program Files (x86)\php
- Installed vcredist_x86.exe
- Configuration of IIS:
added Handler Mappings in IIS
Request path: *.php
Module: FastCgiModule
Executable: c:\Program Files (x86)\php\php-cgi.exe
Name: PHP via FastCgi

- Then added 2 files to C:\inetpub\wwwroot index.php & movie.mpg (6MB)
- add download.cmd to c:
- Installed wget.
- No modification of php.ini, no malware scanner, ...
- start c:\download.cmd


[download.cmd]
--------------
"C:\Program Files\GnuWin32\bin\wget.exe" --limit-rate=20000 http://127.0.0.1/index.php


[Console Output]
----------------

C:\>"C:\Program Files\GnuWin32\bin\wget.exe" --limit-rate=20000 http://127.0.0.1
/index.php
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = C:\Program Files\GnuWin32/etc/wgetrc
--2013-08-16 09:35:00--  http://127.0.0.1/index.php
Verbindungsaufbau zu 127.0.0.1:80... verbunden.
HTTP Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 6702080 (6,4M) [text/plain]
In »index.php.7« speichern.

62% [=======================>               ] 4.193.792   --.-K/s   in 5m 33s

2013-08-16 09:40:35 (12,3 KB/s) - Lesefehler bei Byte 4193792/6702080 (Connectio
n reset by peer). Erneuter Versuch.

--2013-08-16 09:40:36--  (Versuch: 2)  http://127.0.0.1/index.php
Verbindungsaufbau zu 127.0.0.1:80... verbunden.
HTTP Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 6702080 (6,4M) [text/plain]
In »index.php.7« speichern.

 1% [                                       ] 131.072     19,5K/s  eta 8m 59s



[index.php]
-----------
<?php
$track = "movie.txt";

if (file_exists($track)) {
    header("Content-Type: text/plain");
    header('Content-Length: ' . filesize($track));
    header('Content-Disposition: inline; filename="movie.txt"');
    header('X-Pad: avoid browser bug');
    header('Cache-Control: no-cache');
    readfile($track);
    exit;
} else {
    header($_SERVER['SERVER_PROTOCOL'].' 404 Not Found', true, 404);
    echo "no file";
}
?>


[movie.txt] 6MB (no change if its a real movie or not)
---------------
asdfghasdfghasdfgh...


[w3svc1.log]
------------
#Software: Microsoft Internet Information Services 7.5
#Version: 1.0
#Date: 2013-08-16 07:38:26
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status time-taken
2013-08-16 07:38:26 127.0.0.1 GET /index.php - 80 - 127.0.0.1 Wget/1.11.4 500 0 2147500037 205717
2013-08-16 07:41:04 127.0.0.1 GET /index.php - 80 - 127.0.0.1 Wget/1.11.4 500 0 64 28672

I've just tried this with a text file of 6M with no reproduce.

Please post the output of these commands

wget --server-response --limit-rate=40000 http://127.0.0.1/65453/index.php

You can also try curl. It's available for windows or with msysgit shell
curl -v --limit-rate 40000 -o /dev/null http://127.0.0.1/65453/index.php

Thanks

CLI server also shows 200. It'd make sense to ask on IIS forums as well, as 
nothing points to PHP yet.

Please try it with --limit-rate=20000:

"C:\Program Files\GnuWin32\bin\wget.exe" --limit-rate=20000 http://127.0.0.1
/index.php




[Console Output]
----------------

C:\>"C:\Program Files\GnuWin32\bin\wget.exe" --limit-rate=20000 http://127.0.0.1
/index.php
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = C:\Program Files\GnuWin32/etc/wgetrc
--2013-08-16 09:35:00--  http://127.0.0.1/index.php
Verbindungsaufbau zu 127.0.0.1:80... verbunden.
HTTP Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 6702080 (6,4M) [text/plain]
In »index.php.7« speichern.

62% [=======================>               ] 4.193.792   --.-K/s   in 5m 33s

2013-08-16 09:40:35 (12,3 KB/s) - Lesefehler bei Byte 4193792/6702080 (Connectio
n reset by peer). Erneuter Versuch.

--2013-08-16 09:40:36--  (Versuch: 2)  http://127.0.0.1/index.php
Verbindungsaufbau zu 127.0.0.1:80... verbunden.
HTTP Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 6702080 (6,4M) [text/plain]
In »index.php.7« speichern.

 1% [                                       ] 131.072     19,5K/s  eta 8m 59s

hi,
my other testsystem is windows 2012 with php 5.5.2 (x86). here is log and console output from today.
same setup as above & same problem.

when you cancle download of file by wget, did you get 200 or 500?


C:\tmp>"C:\Program Files (x86)\GnuWin32\bin\wget.exe" --limit-rate=20000 http://
127.0.0.1/index.php
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = C:\Program Files (x86)\GnuWin32/etc/wgetrc
--2013-08-20 15:21:09--  http://127.0.0.1/index.php
Verbindungsaufbau zu 127.0.0.1:80... verbunden.
HTTP Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 5702400 (5,4M) [text/plain]
In »index.php.1« speichern.

52% [===================>                   ] 3.014.656   19,5K/s   in 2m 31s

2013-08-20 15:23:40 (19,5 KB/s) - Lesefehler bei Byte 3014656/5702400 (Connectio
n reset by peer). Erneuter Versuch.

--2013-08-20 15:23:41--  (Versuch: 2)  http://127.0.0.1/index.php
Verbindungsaufbau zu 127.0.0.1:80... verbunden.
HTTP Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 5702400 (5,4M) [text/plain]
In »index.php.1« speichern.

48% [=================>                     ] 4.193.792   --.-K/s   in 4m 14s

2013-08-20 15:27:56 (16,1 KB/s) - Lesefehler bei Byte 4193792/5702400 (Connectio
n reset by peer). Erneuter Versuch.

--2013-08-20 15:27:58--  (Versuch: 3)  http://127.0.0.1/index.php
Verbindungsaufbau zu 127.0.0.1:80... verbunden.
HTTP Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 5702400 (5,4M) [text/plain]
In »index.php.1« speichern.

42% [===============>                       ] 4.193.792   --.-K/s   in 4m 14s

2013-08-20 15:32:13 (16,1 KB/s) - Lesefehler bei Byte 4193792/5702400 (Connectio
n reset by peer). Erneuter Versuch.

--2013-08-20 15:32:16--  (Versuch: 4)  http://127.0.0.1/index.php
Verbindungsaufbau zu 127.0.0.1:80... verbunden.
HTTP Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 5702400 (5,4M) [text/plain]
In »index.php.1« speichern.

 1% [                                       ] 147.456     19,5K/s  eta 8m 9s

That's not exactly what i wanted to see because you haven't used the --server-response option with wget. But now I 
see what I've overseen, consider this line in your wget output:

HTTP Anforderung gesendet, warte auf Antwort... 200 OK

I suppose that was something like "HTTP/1.1 200 OK" in the headers. 

Also in your last post to see - that are not multiple downloads at the same, but restarts on connection reset. The 
status 500 in the logs indicates merely this, not the headers sent out. That's what i get with curl and bandwith of 
20K, were probably the same with wget and this bandwidth

$ curl -v --limit-rate 20k  -o /dev/null http://127.0.0.1/65453/index.php
* About to connect() to 127.0.0.1 port 80 (#0)
*   Trying 127.0.0.1...   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0connected
* Connected to 127.0.0.1 (127.0.0.1) port 80 (#0)
> GET /65453/index.php HTTP/1.1
> User-Agent: curl/7.21.1 (i686-pc-mingw32) libcurl/7.21.1 OpenSSL/0.9.8r zlib/1.2.3
> Host: 127.0.0.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Cache-Control: no-cache
< Content-Length: 6291456
< Content-Type: text/plain
< Server: Microsoft-IIS/8.0
< X-Powered-By: PHP/5.5.2-dev
< Content-Disposition: inline; filename="movie.txt"
< X-Pad: avoid browser bug
< Date: Tue, 20 Aug 2013 16:16:05 GMT
<
{ [data not shown]
 66 6144k   66 4095k    0     0  13525      0  0:07:45  0:05:10  0:02:35     0* Recv failure: Connection was reset
 66 6144k   66 4095k    0     0  13521      0  0:07:45  0:05:10  0:02:35     0* Closing connection #0

curl: (56) Recv failure: Connection was reset

Just where curl exits, wget retries the download until it's worked, so infinite tries by default. Testing with a 
static file works. Anyway no crash yet, but now it's to figure out why the connectio nreset happens. It could help 
if you could test the same with apache or cli, too.

test - please to not spam our bug system

hi,
sorry me too, overseen that you need --server-response option in wget.
good to see, that you can reproduce the behavior. :)
here is output of wget & description to reproduce the mutliple download crash:

---------- 8< --------------------------------------------------------------------------

C:\tmp>"C:\Program Files (x86)\GnuWin32\bin\wget.exe" --limit-rate=20000 --serve
r-response http://127.0.0.1/index.php
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = C:\Program Files (x86)\GnuWin32/etc/wgetrc
--2013-08-20 19:51:18--  http://127.0.0.1/index.php
Verbindungsaufbau zu 127.0.0.1:80... verbunden.
HTTP Anforderung gesendet, warte auf Antwort...
  HTTP/1.1 200 OK
  Cache-Control: no-cache
  Content-Length: 5702400
  Content-Type: text/plain
  Server: Microsoft-IIS/8.0
  X-Powered-By: PHP/5.5.2
  Content-Disposition: inline; filename="movie.txt"
  X-Pad: avoid browser bug
  Date: Tue, 20 Aug 2013 17:51:19 GMT
  Connection: keep-alive
Länge: 5702400 (5,4M) [text/plain]
In »index.php« speichern.

73% [===========================>           ] 4.193.792   --.-K/s   in 4m 14s

2013-08-20 19:55:34 (16,1 KB/s) - Lesefehler bei Byte 4193792/5702400 (Connectio
n reset by peer). Erneuter Versuch.

--2013-08-20 19:55:35--  (Versuch: 2)  http://127.0.0.1/index.php
Verbindungsaufbau zu 127.0.0.1:80... verbunden.
HTTP Anforderung gesendet, warte auf Antwort...
  HTTP/1.1 200 OK
  Cache-Control: no-cache
  Content-Length: 5702400
  Content-Type: text/plain
  Server: Microsoft-IIS/8.0
  X-Powered-By: PHP/5.5.2
  Content-Disposition: inline; filename="movie.txt"
  X-Pad: avoid browser bug
  Date: Tue, 20 Aug 2013 17:55:35 GMT
  Connection: keep-alive
Länge: 5702400 (5,4M) [text/plain]
In »index.php« speichern.

12% [====>                                  ] 1.277.952   19,5K/s  eta 7m 11s


---------- >8 --------------------------------------------------------------------------

you can reproduce webserver crash with multiple downloads by following steps:

create file with following content:
[c:\tmp\wget.cmd]
"C:\Program Files (x86)\GnuWin32\bin\wget.exe" --limit-rate=20000 --server-response http://127.0.0.1/index.php

open cmd and typ in 
cd c:\tmp
for /L %i in (0,1,10) do start wget.cmd %i

loop will start 10 cmd boxes and download the "movie.txt".
wait 10-20 seconds and interrupt download by closing all cmd windows (Close all windows)
wait 1-2 seconds and start again 10 multiple downloads 

open cmd typ in 
cd c:\tmp
for /L %i in (0,1,10) do start wget.cmd %i

now all request will be answered with Status 500

c:\tmp>"C:\Program Files (x86)\GnuWin32\bin\wget.exe" --limit-rate=20000 --serve
r-response http://127.0.0.1/index.php
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = C:\Program Files (x86)\GnuWin32/etc/wgetrc
--2013-08-20 20:12:16--  http://127.0.0.1/index.php
Verbindungsaufbau zu 127.0.0.1:80... verbunden.
HTTP Anforderung gesendet, warte auf Antwort...
  HTTP/1.1 500 Internal Server Error
  Cache-Control: private
  Content-Type: text/html; charset=utf-8
  Server: Microsoft-IIS/8.0
  Date: Tue, 20 Aug 2013 18:12:16 GMT
  Connection: keep-alive
  Content-Length: 5666
2013-08-20 20:12:16 FEHLER 500: Internal Server Error.



i will try it with apache & cli later because i'm not familiar with this "tools"

regards oli

I've just tried with apache and cli server and it's not reproduceable there even 
with a smaller bandwidth, so looks like it's stick to IIS. So no need you to do 
it. Still unclear if it's readfile() so going to test your way now.

hello,
on 2 of our servers we have same behavior.
we could not narrow down exactly, why script returns error 500 but we also have iis + php readfile () in use.
hope you can reproduce & fix the bug soon,... if its really a bug.

regarding webserver crash with multiple downloads we can contribute following:
we have found a setting in iis. in fast-cgi settings, you can limit the "Rapid Fails perMinute" by default it is 10.
if you increase it, there will be no error 500 anymore shown to the users.
but in log you still get errors.
it seems that iis kills all php-cgi.exe processes if there are too many fails (error 500) in a specific time (perMinute).

From what i could debug now, there is no crash in PHP itself. What happens is that PHP 
exits early but IIS continues to deliver data to client. What I can assume now is that 
PHP fills the IIS buffers and waits for taker, but IIS doesn't ask anymore because the 
client is downloading with the very low bandwidth and the IIS buffer emties too slowly. 
Therefore two possibilities should be checked with IIS

- increasing timeout between PHP and IIS
- increasing internal IIS buffers, so then PHP can fill it up before it's full

Maybe it had really sense to check with IIS specialists anyway. What i'm additionally 
going to do now is to check if the same happens on linux with say nginx+fastcgi, 
because if it does - that were sure PHP issue.

thx for reply to all. glad to hear i'm not alone (-:
tested different constellations in the last days.
but didnt find any working constellation.
tried to increase timeout settings in iis but no success.
maybe you figured out something new?

hi,
today i installed on a windows server 2008 r2
nginx-1.4.2
and
PHP/5.5.3

and did same test as oli did. Download will NOT be interrupted.
Seems problem only exists in bond with iis and php.
Access log also show only HTTP-Status 200.

C:\nginx>"C:\Program Files (x86)\GnuWin32\bin\wget.exe" --limit-rate=20k --no-ch
eck-certificate --server-response http://127.0.0.1/index.php
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = C:\Program Files (x86)\GnuWin32/etc/wgetrc
--2013-09-04 16:28:57--  http://127.0.0.1/index.php
Verbindungsaufbau zu 127.0.0.1:80... verbunden.
HTTP Anforderung gesendet, warte auf Antwort...
  HTTP/1.1 200 OK
  Server: nginx/1.4.2
  Date: Wed, 04 Sep 2013 14:28:57 GMT
  Content-Type: audio/mpeg
  Content-Length: 41598976
  Connection: keep-alive
  X-Powered-By: PHP/5.5.3
  Content-Disposition: inline; filename="movie.mpg"
  X-Pad: avoid browser bug
  Cache-Control: no-cache
Länge: 41598976 (40M) [audio/mpeg]
In »index.php« speichern.

11% [===>                                   ] 4.685.600   20,0K/s  eta 30m 2s


Also with PHP/5.5.2

C:\nginx>"C:\Program Files (x86)\GnuWin32\bin\wget.exe" --limit-rate=20k --no-ch
eck-certificate --server-response http://127.0.0.1/index.php
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = C:\Program Files (x86)\GnuWin32/etc/wgetrc
--2013-09-04 16:35:05--  http://127.0.0.1/index.php
Verbindungsaufbau zu 127.0.0.1:80... verbunden.
HTTP Anforderung gesendet, warte auf Antwort...
  HTTP/1.1 200 OK
  Server: nginx/1.4.2
  Date: Wed, 04 Sep 2013 14:35:05 GMT
  Content-Type: audio/mpeg
  Content-Length: 41598976
  Connection: keep-alive
  X-Powered-By: PHP/5.5.2
  Content-Disposition: inline; filename="movie.mpg"
  X-Pad: avoid browser bug
  Cache-Control: no-cache
Länge: 41598976 (40M) [audio/mpeg]
In »index.php« speichern.

11% [===>                                   ] 4.587.296   20,0K/s  eta 30m 7s


Any suggestion for next steps to restrict the problem?

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.

Problem still exists, no further Information was required from me.
if i missed something, please keep me up.

hi,
problem still exists unter windows server 2012 + iis + php 5.5.6

confirm with windows server 2012 + iis + php 5.5.7

confirm with windows server 2012 + iis + php 5.5.8

As I had issues with IIS and PHP with requests that took a long time, my problem was that IIS had a default timeout set too short for my application. Solution for me was found here: http://stackoverflow.com/questions/17824462/internal-server-error-500-after-90-seconds-of-php-script-running

Is that still an issue with any of the actively supported PHP
versions[1]?

[1] <https://www.php.net/supported-versions.php>

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.