我正在使用基于 asp.net 构建的第三方应用程序。它在 Server 2003/IIS6 上运行。我更改了应用程序池的回收方式。发生这种情况后，第三方应用程序停止工作。具体来说，与第三方程序目录中的文件不对应的 URL 返回了 404 错误。
（我不太了解 asp.net 的工作原理。）我的意思是，如果我转到类似这样的 URL example.com/thirdparty/page.aspx，当第三方程序目录中有一个 page.aspx 文件时，该页面就可以正常工作。如果我转到example.com/thirdparty/stylesheet6.css，当程序目录中没有 stylesheet6.css 文件时，我会收到 404 错误。
在我对应用程序池进行此更改后，它停止工作，尽管我可能错误地更改了 IIS 配置的其他方面。我已将这些应用程序池设置恢复到我认为的原样，但这并没有解决问题。
该第三方软件公司建议卸载并重新安装并从备份中恢复（基本上他们不知道它为什么会损坏）但我想消除我造成的损害因为这可能更容易。
我可以对 IIS 配置做哪些更改以破坏这些类型的 URL？
答案1
如果您定期备份，您可以尝试恢复更改前的 IIS 元数据库文件副本。techNet 上有关于此内容的良好指南这里。您需要先从磁带恢复文件，然后将其放在可以访问的地方，以便将其恢复到 IIS。备份当前文件第一的
答案2
回收设置不应该导致这种情况 - 但它们可能已经激活了之前所做的配置更改。
听起来您缺少 ASP.Net 的通配符脚本映射，并且应该为通配符脚本映射切换“验证文件是否存在”设置。该应用程序可能在首次设置时附带了相关说明，但可以在应用程序级别和网站级别重新定义这些设置。
uSlackr 建议从旧备份恢复元数据库，这个建议很好（并且不要忘记配置历史记录），否则您可以将 metabase.xml 与旧版本进行比较，并特别关注您感兴趣的每个级别的脚本映射和相关设置。
答案3
（我正在回答我自己的问题，因为根据 uSlackr 和 TristanK 给出的答案，我能够发现配置设置的改变如何会造成如此大的破坏。）
uSlackr 指出的文章是关键。我没有意识到每次更改配置时都会自动备份。不幸的是，尽管我做了所有调整以尝试恢复，但一切正常时的自动备份已被覆盖。不过，我能够使用手动恢复的说明从备份中恢复（无需恢复大量不相关的文件）。
我确信我做错了，我更改了网站根目录下的设置，然后在系统询问是否应覆盖下面的所有内容时回答“是”。我以为它只会更改该设置（例如超时），但它实际上用空白覆盖了较低级别的脚本映射。这些脚本映射包括通配符处理程序，这就是这些 URL 损坏的原因。经验教训：在适当的级别进行更改，当配置更改导致问题时从备份中恢复。