One example of such a response is:
"Server Error in '/' Application."
You can configure your .NET webapp (BD-enabled or not) to possibly give a more useful error message by adding:
to the Web.config file of your .NET webapp, or to the Machine.config file.
BD (all configurations, not just .NET) never catches "Throwable"... even if your CFM pages contains a <cfcatch> whose
type = "any".
In that scenario, BD catches BD-defined Exceptions, and java.lang.RuntimeException.
That means that if the Exception or Error is some other one... such as a JVM-specific one (or a .NET framework-specific one), or one that's specific to certain operations such as an XML Parsing Exception, or perhaps one that's thrown by the "Container" such as the .NET Framework or Sun's JVM then cfcatch won't catch it.
The reason is because BD makes calls to the APIs provided by either .NET or the JVM, and those calls may throw errors/exceptions that don't relate to the CF world.
In that case, it's not caught by BD, it bubbles up to the "Container" inside which BD runs.
At that point it's out of BD's hands.
This is why you'd see a "generic" .NET error (or JVM error) in the first place... and also why you'd want to turn customErrors off in the .NET webapp... so that the .NET framework won't hide the true problem from you.