This is driving the whole team crazy. There must be some simple mis-configured part of IIS or our Web Server, but every time we try to run out ASP.NET Web Application on IIS
I had these exact symptoms and my issue was similar to Peter's. Was setting up an existing project on a new server. My project referenced the IIS7 URL Rewriting module, but that hadn't been installed yet on the new server. Installing it fixed my issue.
You can use the Microsoft Web Platform Installer to install it. Execute it, select Products, in the left menu select Server and find URL Rewrite in the list and install it.
Or you can download it here.
I had the same error. I had an IIS site with .net framework version 2.0, but my app needed 4.0. I changed the version and it worked.
Posting just as a reminder if someone might have the same issue.
Comment the following lines in the web.config file.
<modules>
<!--<add name="ScriptModule" preCondition="integratedMode" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>-->
</modules>
<handlers>
<remove name="WebServiceHandlerFactory-ISAPI-2.0"/>
<!--<add name="ScriptHandlerFactory" verb="*" path="*.asmx" preCondition="integratedMode" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
<add name="ScriptResource" verb="GET" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>-->
</handlers>
This will work.
The below config was the cause of my issue:
<rewrite>
<rules>
<clear />
<rule name="Redirect to HTTPS" stopProcessing="true">
<match url="(.*)" />
<conditions>
<add input="{HTTP_HOST}" pattern="^.*spvitals\.com$" />
<add input="{HTTPS}" pattern="off" ignoreCase="true" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" redirectType="Permanent" appendQueryString="false" />
</rule>
</rules>
</rewrite>
Note: I removed this section for local testing, as it works fine in Azure.
Another way of getting 500.19 errot for no apparent reason is - missing directories and/or broken permissions on them.
In case of this question, I believe the question asks about full IIS version. I assume this because of this line:
Config File \\?\E:\wwwroot\web.config
IIS installer usually creates the wwwroot
for you and that's the default root folder for all websites and mount point for virtual directories. It always exists, so no problem, you usually don't care much about that.
Since web.config files are hierarchical, you can put there a master web.config file and have some root settings there, and all sites will inherit it. IIS checks if that file exists and tries to load it.
However, first fun part:
This directory will exists if you have IIS properly installed. If it does not exist, you will get 500-class error. However, if you play with file/directory permissions, especially 'advanced' ones, you can actually accidentally deny IIS service account from scanning/reading the contents of this directory. If IIS is unable to check if that wwwroot\web.config exists, or if it exists and IIS is not able to open&read it - bam - 500-class error.
However, for full IIS it is very unlikely. Developers/Admins working with full IIS are usually reluctant regarding playing with wwwroot
so it usually stays properly configured.
Usually, IIS Express "just works". Often, developers using IIS Express often are not aware how much internally it resembles the real IIS.
You can easily stumble upon the fact that IIS Express has its own applicationHost.config file and VS creates and manages it for you (correctly, to some extent) and that sort of an eye-opener telling you that it's not that simple and point-and-click as it seems at first.
Aside from that config file, VisualStudio also creates an empty directory structure under your Documents
folder. If I remember correctly, IIS Express considers these folders to be the root directories of your website(s) upon which virtual directories with your code are mounted.
Later, just like IIS, when IIS Express starts up, it expects these folders to exist and checks for root web.config files there. The site web.config files. Almost always, these web.config files are missing - and that's OK because you don't want them - you have your **application web.config", they are placed with rest of the content in a virtual directories.
Now, the second fun part is: IIS Express expects that empty directories. They can be empty, but they need to exist. If they don't exist - you will get a 500-class error telling you that "web.config" file at that path cannot be accessed.
The first time I bumped into this problem was when I was clearing my hard drive. I found that 'documents\websites' folder, full of trash, I recognized several year-old projects I no longer work on, all empty, not a single file, so I deleted it all. A week later - bam - I cannot run/debug any of the sites I was working at the moment. Error was 500.19, cannot read config file.
So, if you use IIS Express and see 500-class error telling about reading configuration, carefully check the error message and read all paths mentioned. If you see anything like:
c:\users\user\documents\visual studio 2013\projects\WebProject1\WebProject1.web\web.config
c:\users\zeshan.munir\documents\visual studio 2015\projects\WebProject1\WebProject1.web\web.config
c:\users\zeshan.munir\documents\visual studio 2017\projects\WebProject1\WebProject1.web\web.config
etc..
Go there exactly where the error indicates, ensure that these folders exist, ensure that IIS worker account can traverse and read them, and if you notice that anything's wrong, maybe it will be that.
BTW. In VisualStudio, on ProjectProperties/Web there's a button "Create Virtual Directory". It essentially does this very thing, so you may try it first, but IIRC it can also somethimes clear/overwrite/swap configuration sections in applicationHost.config file, so be careful with that button if you have any custom setups there.
I just add an answear because I spent hours trying to solve the same symptoms (but different issue):
A possible cause is a x86 dll in a 64 bits app pool, the solution is to enable 32 bits apps in the application pool settings.