Take a look at IIS7's Failed Request Tracing feature:
Troubleshooting Failed Requests Using Tracing in IIS 7
Troubleshoot with Failed Request Tracing
The other thing I would do is tweak your <httpErrors> setting because IIS may be swallowing an error message from further up the pipeline:
The documentation states that add_header "Adds the specified field to a response header provided that the response code equals 200, 204, 206, 301, 302, 303, 304, or 307. A value can contain variables." So it doesn't work with a 502.
I forgot to add that you can use the third party headers more module to add headers to other codes. You'll probably have to ...
In IIS Manager, select your site, double-click the Error Pages icon and click on Edit Feature Settings in the pane on the right. Choose Detailed Errors. If that is not enough, click on the .NET Error Pages in the ASP.NET section, again Edit Feature Settings in the pane on the right, choose Off.
If this is a production machine, change these settings back ...
In my case:
The Event Log was empty.
web.config wasn't corrupt - verified by using same on local machine / using inetmgr
Checking IIS logs showed a request like this
...Chrome/57.0.2987.133+Safari/537.36 500 19 5 312
The key being:
sc-status sc-substatus sc-win32-status
500 19 5
which with some googling pointed me to the ...
It looks like the problem is with what IIS would call handler mappings.
You said Not (yet) using mod_mono
Without it you would not get the .NET framework, so how would Apache know how to handle asp files?
You need to determine the reason for the 500 error. It's usual to look in your logs for more detail and work out from there.
You should also take a look at the excellent answer to this Q&A which gives sound advice on diagnosing issues.
Open Server Manager
At Server Level (not default Web site)
Double click FastCGI Settings
open PHP.EXE listed there
Monitor changes to file php.ini
activity timeout default is 60s - change to 600s or whatever
We use a combination of log formats in nginx and lmon to catch things like this. An NGINX log format like:
$connection $remote_addr $host $remote_user [$time_local] "$request"
"$http_referer" "$http_user_agent" "$http_x_forwarded_for"
And it will load the rewrite module for you
the error you are seeing is not because you dont have permissions to use rewrite but because its not available as can be seen from the a2dismod list output you provided (its not appearing in the list)
Alas, there is a load balancer controlling the server, and the load balancer was set up to stop connections after 10 seconds of inactivity or so. The problem is solved now.
The reason the 500 did not show up in the apache's error.log is that it was the "outer" system (the load balancer) stopping the connection, not the server itself.
Thank you all ...
error_log $filename debug; will turn on debug level logging into the error log -- this will give you lots and lots of details of nginx's internal status at the time of the error, and if compiled with --with-debug (which several distros do by default) it'll give even more.
Be warned that the "debug" level really does generate lots of output, to the point ...
The most obvious issue is improper or zero NTFS rights on the web application folder. So make sure the account serving the site has the right permissions. Without proper NTFS rights to the web directory it doesn't matter what you put in the web.config as it will never be read.
A quick check can be to give everyone full rights - if the site starts working ...
I have spoken to a Dev on httpd mailing list and he confirmed that this feature has not been implemented in the current code base. I have also reviewed the code myself. The state machine inside mod_proxy_balancer cannot retry on HTTP error but can only do so in case of connection error. I tried to implement it myself but its too complicated and I can easily ...
By default, the Joomla log folder path is /logs. If you installed Joomla 3 to /home/username/public_html/joomla, then the log folder will be set to /home/username/public_html/joomla/logs.
To find where your Joomla logs are stored, you can try the following:
Log into your Joomla 3.0 admin control panel
In the left menu go to Global Configuration
Click the ...
It's something to do with session cookies and how the site handles them.
First pass, no session cookie at my end,
$ wget --load-cookies cookies --save-cookies cookies --keep-session-cookies -S http://motherscarehawaii.teamvision.biz/
--2011-07-21 21:37:05-- http://motherscarehawaii.teamvision.biz/
Resolving motherscarehawaii.teamvision.biz (...
7 is "time up" and 14 is "EOF", so the root cause of this is probably a read timeout during the upload.
The 70000 prefix means they are APR status codes.
They are logged poorly here because they the core of apache is expecting a different type of error code then what is returned -- these are APR or "filter" return codes but the core of httpd is expecting a ...
Restarting IIS because of a 500 response is about the same as cracking an egg with a hefty swing of a sledgehammer. You are not going to solve this problem with a restart, you are going to have to solve your problem by figuring out what is causing the 500 and correcting it. Automatically restarting the server on a 500 is not a resolution to the problem. ...
This error is generated because an absolute path is detected in web.config.
Absolute physical path (like C:\path\to\notfound.html) is not allowed in system.webServer/httpErrors section in web.config file.
Now you have 2 solutions :
1. Allow physical path in ApplicationHost.config file
By default this file is located in %SystemRoot%\system32\inetsrv\...
There's not much sense in using "~*" for /internalerror location, plain location would do.
You're getting 404 because /InternalError file is missing. Did you intend to serve such requests from uwsgi backend?
The location of the error log is in your config file, which is probably located at /etc/lighttpd/lighttpd.conf. Look for the server.errorlog line.
If it's still set to default, the log is probably at /var/log/lighttpd/error.log.