简短版本
请阅读最底部的问题的简短版本。
情况
在我上周提出的一个问题中，我努力寻找一个解决方案，使我们的 asp.net 错误可视化防水，因为在某些边缘情况下 asp.net 异常处理失败，因此无法创建适当的异常可视化：
如何正确设置 ASP.NET web.config 以在边缘情况下显示特定于应用程序、安全且用户友好的 asp.net 错误消息
所需的解决方案
作为我在那里描述的方式的替代方法，在我看来，使异常可视化可靠的最佳方法是使用-element httpErrorsinsystem.webServer作为故障保存，以便任何未被 asp.net 正确处理的错误，导致基于httpErrors-element 设置显示的通用错误页面。
要做到这一点，必须有两件事可能：
- 应用程序正确处理的错误页面必须通过 iis 而不被替换为通用错误消息
- 在 asp.net 中无法正确处理的错误必须通过 IIS 替换。
我的理解是，这种行为是由-elementexistingResponse="Auto"中的参数表示的。
ms 文档指出：httpErrors
仅当设置了 SetStatus 标志时才保持响应不变。
这正是必需的：应用程序中任何成功的错误页面创建（通过Application_Error或通过明确定义的错误处理页面）都可以设置
Response.TrySkipIisCustomErrors = true并且 IIS 会让错误页面通过。但是，asp.net 中的应用程序未成功处理的所有其他错误都不会设置标志，因此会得到httpErrors-element 中指定的错误页面。
问题
可悲的是，似乎在 MVC5 应用程序中（我不知道在其他环境中是否存在相同的行为），Response.TrySkipIisCustomErrors( fTrySkipCustomErrors) 似乎自动设置为 [ true]，即使它不是由应用程序设置的。
因此，我们在同一个地方，就像在我的另一篇文章中一样：如果应用程序的错误处理失败，则无法使用 显示应用程序特定的错误existingResponse="Auto"，因为无法重置fTrySkipCustomErrors标志。
作为替代方案，可以设置existingResponse="PassThrough". 这就是我们目前所做的，因为我们希望生成带有支持代码和其他有用信息的错误页面，以向用户显示错误，或者可以使用 existingResponse="Replace"，但这不是一个选项，因为它替换了任何错误页面，因此我们无法向用户显示任何特定于错误的信息，例如之前提到的支持代码。
简短
的问题 因此，问题是，如何确保 MVC5 (asp.net) 不会自动将fTrySkipCustomErrors标志设置为使参数没有实际意义。[true]Response.TrySkipIisCustomErrorsfTrySkipCustomErrorsexistingResponse="Auto"
要检查这种 asp.net MVC5 异常处理失败但fTrySkipCustomErrors标志设置为 true 的情况，请从您的 MVC5 应用程序请求以下页面：
http[s]://[yourWebsite]/com1
请注意：我对禁用上述错误不感兴趣。这是一个例子。我希望错误可视化可靠，并且不必规避可能破坏 asp.net 错误处理机制的每个错误。