Eu problema semelhante há muito tempo, o sistema em questão usa páginas de erro estático por causa disso.
Você pode definir isso no defaultResponseMode para o arquivo que servirá de volta a uma única página estática.
Eu notei um comportamento estranho nas páginas de erro do IIS. Eu tenho essa configuração:
<httpErrors errorMode="Custom" existingResponse="Replace">
<remove statusCode="500" />
<error statusCode="500" responseMode="ExecuteURL" path="/error-page" />
</httpErrors>
Às vezes, quando ocorre um erro do ASP.NET devido à cadeia de consulta ser muito longa, o segundo erro ocorre imediatamente ao tentar executar a URL da página de erro. Eu acompanhei o problema para o fato de o IIS anexar o URL original à URL da página de erro, como:
Original: http://example.com/someurl?id=some_very_long_query_string_causing_security_exception
Error: /error-page?500;http://example.com/someurl?id=some_very_long_query_string_causing_security_exception
Este é um problema enorme. Se o URL original falhar por ter uma string de consulta muito longa, a página de erro com o material anexado também falhará, porque ela tem uma string de consulta que é ainda mais longa!
Eu acredito que este é o erro mais burro no IIS. Alguém sabe se havia algum patch de service pack para isso? Pior cenário, se nada for corrigido até agora, existe uma maneira de desativar esse comportamento ou qualquer truque para parar o IIS anexando coisas não solicitadas à página de erro? Porque ele quebra todo o mecanismo da página de erro personalizada.
Eu problema semelhante há muito tempo, o sistema em questão usa páginas de erro estático por causa disso.
Você pode definir isso no defaultResponseMode para o arquivo que servirá de volta a uma única página estática.