This project is read-only.

Windows Server 2012 IIS HTTP 500 Error

Topics: Installing Orchard
Apr 16, 2013 at 10:30 AM
I installed 1.6 version and in as a new Website in IIS (did that with source and build versions) on my Windows Server 2012 64 bit VM. I think that I have all the configuration OK, like: app pool Manage Pipeline Integrated and 32 bit apps enabled, pool identity has full permission on Web folder, binding defined in host file. When I try to start the site – access my site, I get HTTP 500 Internal Server Error.
Interestingly, in a source code deployment, when I use development server, I am able to access the site. If I switch that to IIS, I get HTTP 500.
Any suggestion what I have been doing wrong?
Apr 17, 2013 at 6:54 AM
"500" is not enough information: it just means "server error". Please look in app_data\logs and give us the stack trace you see there.
Apr 18, 2013 at 7:24 PM
When I try to access the site, it does create the error log file for the day but it is empty. I couldn't find anything useful in the Event Viewer either.
Apr 18, 2013 at 7:34 PM
Sounds really like the website is not in integrated mode, or that the web.config handlers have been altered.
Apr 18, 2013 at 7:41 PM
is the pool running on 4.0 ?
are other .net 4 applications run? other wise try install or re-register .net framework?
Apr 23, 2013 at 9:50 PM
Pool is OK. I still cannot make it work on Windows Server 2012. What I noticed, Windows Server 2012 has .NET 4.5 and cannot have .NET 4.0. I guess the deployment files are compiled with .NET 4.0.
I was able to make it work on Windows 8, with the same settings, which has .NET 4.0 and 4.5.
Apr 27, 2013 at 9:48 PM
I am experiencing absolutely the same situation. It is ok on Windows 8 but I can't get it work on Windows Server 2012.
May 1, 2013 at 3:56 PM
Make sure you have installed ASP.NET 4.5 option in your IIS Server Role.
May 1, 2013 at 6:42 PM
ASP.NET 4.5 is installed in IIS. It is really interesting that I don't get any logs there either.
May 1, 2013 at 6:47 PM
I will investigate but I can't right now. Can someone file a bug so we can track the progress ?
May 2, 2013 at 9:15 AM
I've got it work. The site started when I added "App server" role with next options: ".NET Framework 4.5" and "Web Server (IIS) support". But it still looks a little bit tricky. Could you, please, give a brief explanation of failure reasons? Thanks in advance.
Jun 10, 2014 at 11:07 AM
I'm having the same problems - nothing at all in the error log and plain error 500s with no crash dump on screen in Windows Server 2012 R2 / IIS 8.5 / .NET 4.5, standard install.

I'd really like to see the crash dump - does anyone know which bits of the web.config I'd need to take out to get to the yellow screen of death?
Jun 13, 2014 at 8:30 PM
Edited Jun 13, 2014 at 8:43 PM
As per another issue I found I could improve things by deploying a little differently, but I still have this problem precisely. Rackspace are looking at it too, but I don't really see how I'm getting a crash without a YSOD - this looks pretty basic. Someone else must have the same thing, no?

Symptoms are as reported elsewhere - serving local resources eg CSS or JS files gives just the error, as do extensionless URLs.
Jun 14, 2014 at 6:04 PM
I seem to recall having that issue - it ended up being something related to enabling http activation in roles and features. It was over a year ago though - might have been something else.
Jun 22, 2014 at 3:31 PM
Hmm. On my Rackspace Cloud system this continues to occur, but as far as I can tell only when people are actually editing things. To be precise, one person editing can cause the error, which naturally occurs during a postback, typically when changing (saving) some content.

There are two types of "plain" error 500 screens - one with a grey background, the standard IIS one I've seen elsewhere when error handling isn't well set up, and another "service unavailable" white background error 500 screen. I don't understand why that would be. There's never anything in the logs - it looks like it's crashing too badly for that, so it's impossible to debug from there.

If you "bounce" the server (restart the instance, but not the app pool), then the problem clears, until in a few saves time it will do the same thing again. It almost looks like..
(1) you post back, changing something
(2) perhaps IIS starts rebuilding something
(3) the response returns with an Error 500.

At this point pressing F5 etc won't work, you just get more error 500s. The only way out of it, as far as I can tell, is to bounce the instance at this point. When that completes, pressing F5 will return with whatever it should have sent you in the first place.

You can get it to a state where some pages will render, but others will return the error 500. This happened before I turned caching on, so I don't think it's connected to that.

Rackspace are poking at it, but I don't think they have anyone with this working, of if they have, they don't know them. Anyone here using Rackspace Cloud?
Jun 28, 2014 at 10:18 AM
A little more on this. If I look at an Orchard page in multiple different browsers, using the same IP address and on the same MAC address:
  1. Edit a page in Orchard from one browser. Save it, all good there.
  2. Check the page in other browsers, one works fine, the other gives the plain grey error 500.
The only way to clear the error 500 appears to be to restart the application on Rackspace Cloud. That doesn't recycle the app pool, but does fix the problem. It's equivalent to restarting the instance (but not IIS) on IIS manager locally.

Rackspace won't divulge their load balancing architecture, but I they have a cookie in there which is probably used for sticky load balancing at their end. So two of my browsers are hitting a Rackspace IIS instance which serves the updated page correctly. The third one is hitting a different instance, which will not serve the page under any circumstances. Well, it'll probably serve it once IIS restarts, not sure how they have that set.

As usual the logs are information free: zero length. To be clear, I can make the logs work by forcing an error, so I know the logging is good. I'm familiar with RFC 2616.

In my case here the page is being written back to my database, and any image changes are written back to the file system. Only the latter is likely affected by the load balancing, but both work consistently. It does not fail on save: it fails once that commit is complete. The error 500 sometimes hits the "saving" browser, sometimes one of the others. So this is happening once the write is committed to Rackspace's back end, and it apparently randomly hits the output IIS servers.

As there's no log and no YSOD, it's presumably happening in some low level part of the "pipeline" in IIS. I will ask Rackspace to turn on failed event tracing and get them to pull the logs, maybe there will be a clue there.