Iis HTTP错误500.19-内部服务器错误无法读取配置文件

Iis HTTP错误500.19-内部服务器错误无法读取配置文件,iis,asp.net-web-api,Iis,Asp.net Web Api,我一直在互联网上搜索这个错误,但无论我如何尝试解决这个问题,实际上都没有任何效果。我从fiddler复制了一个url并将其放入浏览器后得到的详细信息如下 模块iiswebcore 通知开始请求 处理程序尚未确定 错误代码0x80070003 配置错误无法读取配置文件 配置文件\?\C:\inetpub\wwwroot\myservices\web.Config 事实上,在过去,当我使用VisualStudio在IIS中为它创建虚拟目录时,这个名为“myservices”的服务工作正常。但后来,我

我一直在互联网上搜索这个错误,但无论我如何尝试解决这个问题,实际上都没有任何效果。我从fiddler复制了一个url并将其放入浏览器后得到的详细信息如下

模块iiswebcore

通知开始请求

处理程序尚未确定

错误代码0x80070003

配置错误无法读取配置文件

配置文件\?\C:\inetpub\wwwroot\myservices\web.Config

事实上,在过去,当我使用VisualStudio在IIS中为它创建虚拟目录时,这个名为“myservices”的服务工作正常。但后来,我尝试在IIS中对该服务进行web部署,并将其从默认网站树中删除(“myservices”,这是我通过在VS2013中创建虚拟目录创建的)。我观察到的是,在我web部署“myservices”后,它的工作方式与以前的工作方式不同(我通过VS2013在IIS中为“myservices”创建了一个虚拟目录,但已将其删除,以查看web部署版本的工作方式是否相同)。因此,当我通过Fiddler(针对web部署的服务)分析HTTP错误500.19的原因时,它说(配置错误无法读取配置文件和 配置文件\?\C:\inetpub\wwwroot\myservices\web.Config),但当我实际尝试查看文件夹C:\inetpub\wwwroot时,我始终找不到myservices文件夹本身(在其中谈论web.Config文件)。然后,我在C:\intepub\wwwroot目录中手动创建了一个名为“myservices”的文件夹,并将我的web.config文件放在那里,以查看web部署的服务是否仍能工作,但它不能工作。然后,我删除了这个名为“myservices”的文件夹以及其中的web.config文件,并从默认网站树中删除了web部署服务

现在,在所有这些混乱之后,即使我去visual studio尝试为我的服务“myservices”创建一个虚拟目录(我可以在IIS中的默认网站树中看到它),但它会抛出与此服务的Web部署版本相同的错误,即http 500.19。换句话说,无论我尝试了什么,它都会把我的服务搞砸,即使它不是以前没有的web部署版本。我诚恳地请求所有在场的人,请用他们的任何经验来指导/建议我,看看我在这场尝试和错误的努力中出了什么问题


谢谢

这可能不太可能,但有时web.config文件会损坏(我们的代码存储库偶尔会这样做),您无法用肉眼看到它。取一个简单的web.config文件,您知道该文件没有损坏,然后从那里开始重建该文件(如果该文件有效)。我们还使用了一个十六进制编辑器(比如XVI32),在这里我们可以看到损坏,但是从新文件重建要容易得多


如果您的问题不是web.config,而是虚拟文件夹,请执行相同的方法。从工作开始,然后从那里开始。可能是web部署工具导致了损坏

当一切都不起作用时,我所做的就是卸载IIS,重新启动我的计算机,然后重新安装HTTP 500.19。我的IIS似乎已损坏。

非常感谢您的回答,但我真的无法理解,请您详细说明两件事。第一个是重建文件(您的意思是将未损坏的web配置文件复制到项目中的web配置文件中)。其次,您说过,如果问题不是配置文件,而是虚拟文件夹,那么请使用相同的方法,您指的是什么方法?当我们第一次遇到损坏问题时,我们将从一个新的web.config文件开始(例如,在VS中创建一个新的项目,并使用创建的项目)。如果该错误消失,则表明问题出在配置文件损坏上。因此,您可以在配置文件中手动输入所需的新部件。如果可行,请执行web部署。如果在部署的站点上出现错误,请尝试手动执行部署,而不是使用web部署。可能是web部署中的打包损坏了文件。如果这些都不起作用,则问题不是web配置损坏。由于您还对虚拟目录进行了大量修改,因此您应该从头开始创建一个新网站。在进行任何配置更改之前,复制文件并进行测试。这将允许您隔离第一次打破它的时间/方式。幸运的是,你甚至不会遇到同样的问题,它会再次起作用。基本上可以归结为这一点——通常,从头开始重建某些东西,然后尝试确定错误的来源要容易得多。