exception-handling - servidor - iis 500 internal server error there is a problem with the resource you are looking for and it

ASP.NET Web API: Error no descriptivo de servidor interno 500

Question

Como dice el título, tengo 500 Internal Server Error from GET request a una acción IQueryable. El cuerpo del error está vacío. Ese error ocurre después de que mi acción devuelva el resultado.

Uso ASP.NET Web API RC.

¿Cómo puedo obtener el rastro de pila de ese error?

Answer 1

Después de RC, este problema se corrigió y obtendrá los detalles del error además del 500 Internal Server Error. (Sin embargo, este problema se corrigió solo en escenarios de Web Host).

Puede hacer lo siguiente para obtener los detalles de la excepción real que podría estar ocurriendo durante el método WriteToStream de un formateador.

ObjectContent<IEnumerable<Product>> responseContent = new ObjectContent<IEnumerable<Product>>(db.Products.Include(p => p.ProductSubcategory).AsEnumerable(), new XmlMediaTypeFormatter()); // change the formatters accordingly

            MemoryStream ms = new MemoryStream();

            // This line would cause the formatter''s WriteToStream method to be invoked.
            // Any exceptions during WriteToStream would be thrown as part of this call
            responseContent.CopyToAsync(ms).Wait();

Answer 2

Este escenario fue causado por los siguientes motivos

1. El problema ocurrió debido a Web.config mal formado. (Múltiples secciones de configuración)

2. En lugar de crear la carpeta roslyn dentro de la carpeta bin , la tuve creada en la raíz. (Ubicación de implementación)

La mejor forma de diagnosticar esto fue colocar una página HTML simple en la ubicación de la aplicación e intentar explorarla. 500 La descripción del error se mostrará en esta página html.

Y también no te olvides de agregar

<customErrors mode="Off"></customErrors>

a Web.config

Answer 3

Esto puede estar relacionado con la referencia circular.

http://www.asp.net/web-api/overview/formats-and-model-binding/json-and-xml-serialization#handling_circular_object_references

Intente agregar el siguiente código al método Application_Start en el archivo Global.asax:

 var json = GlobalConfiguration.Configuration.Formatters.JsonFormatter;
 json.SerializerSettings.PreserveReferencesHandling = Newtonsoft.Json.PreserveReferencesHandling.All;

Answer 4

Fredrik Normén escribió una gran publicación de blog llamada ASP.NET Web API Exception Handling sobre ese tema. Su solución usa clases de excepción personalizadas y un atributo de filtro de excepción que se puede aplicar a todos los métodos de acción de ApiController .

Answer 5

Me encontré con este mismo problema. Encontré la respuesta de Kiran Challa útil para lograr que la excepción real fuera arrojada fuera de mi acción.

Para resolver mi problema, establecer la propiedad ProxyCreationEnabled de mi contexto en falso me dio un paso más.

En mi caso, mi próxima excepción se debió a una referencia circular en mis modelos. Después de limpiar eso, la respuesta del fantasma 500 desapareció. ¡Buena suerte si aún no has resuelto esto!

Answer 6

Puedes intentar agregar:

GlobalConfiguration.Configuration.IncludeErrorDetailPolicy = 
    IncludeErrorDetailPolicy.Always;

a su Application_Start() en Global.asax. Esta solución funciona para muchos de los errores comunes.

Sin embargo, si no está obteniendo información satisfactoria, debería considerar escribir un l Filtro de excepciones y registrarlo globalmente.

Este artículo debería ayudarte a comenzar. El núcleo de lo que necesita es escribir y registrar algo como:

public class NotImplExceptionFilter : ExceptionFilterAttribute {
  public override void OnException(HttpActionExecutedContext context) {
     if (context.Exception is NotImplementedException) {
       context.Response = new HttpResponseMessage(HttpStatusCode.NotImplemented);
    }
  }
}

Answer 7

Tuve el mismo problema, pero la fuente fue ligeramente diferente: establecí la política CORS incorrectamente y eso me da 500 Internal server error , pero como CORS no funcionaba, el encabezado Access-Control-Allow-Origin no se presentó en respuesta y el navegador no puede leer la respuesta real

Lo resolví con la opción ChromeDevTools Copy as cURL que me permite ver la respuesta y comprender el origen del error

Answer 8

Tuve el problema en RC cuando no especificaba los parámetros de consulta en el orden correcto. Por ejemplo, si especifica $skip=0 , obtendrá 500, pero si especifica $orderby=xxx&skip=0 no hay error.

Answer 9

Una debilidad de enrutamiento engañosamente simple causó este problema en mi caso: Hubo otro HttpPost con la misma firma (no nombre) en mi controlador Api. El enrutamiento predeterminado no resolvió las diferencias de nombre, y el ServiceError 500 fue la respuesta que dio antes de que se alcanzara cualquiera de las funciones Api. Solución: cambie el enrutamiento predeterminado o sus firmas y vuelva a intentarlo.

Aquí está mi RouteConfig.cs que funciona bastante bien para el uso estándar de WebApi2:

    public class RouteConfig
{
    public static void RegisterRoutes(RouteCollection routes)
    {
        routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

        // Default is required in any case.
        routes.MapRoute(
            name: "Default",
            url: "{controller}/{action}/{id}",
            defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional }
        );
    }
}

Answer 10

Usualmente uso Global.asax para detectar todos los errores. Aquí hay un fragmento de código que puede usar

public void Application_Error(object sender, EventArgs e)
{
  Exception exc = Server.GetLastError();
  MvcApplication mvcApplication = sender as MvcApplication;
  HttpRequest request = null;
  if (mvcApplication != null) request = mvcApplication.Request;
}