classic icon indicating copy to clipboard operation
classic copied to clipboard

500 errors not logging

Open drjaydenm opened this issue 8 years ago • 11 comments

I am using version 2.0.9 of this component to log an ASP.NET MVC 5 application. It is working correctly, however does not log any 500 Internal server errors. All exceptions for other HTTP error codes are caught (400, 404 etc). Is there anything that may stop the logging of these 500 errors? Does an unhandled exception handler need to be setup at all? The app is fairly standard configuration wise.

drjaydenm avatar Sep 15 '16 04:09 drjaydenm

Thanks for the report. I haven't encountered this, may need some investigation. Help welcome, if you're able to build from source and take a look.

Which Serilog version are you running, and to which sink(s)? Thanks!

nblumhardt avatar Sep 18 '16 23:09 nblumhardt

I am using the Seq sink. I was using outdated versions of these packages. I have now updated them and am using Serilog 2.2.1 and Serilog.Sinks.Seq 3.0.1. The 500 errors are now coming through on Seq but have no exception data and are only logging as Information level, which is not very helpful as it has no context of the error (stack trace/line numbers etc).

drjaydenm avatar Sep 23 '16 00:09 drjaydenm

Sounds like progress! Glad to hear you have some data captured now.

Can you please send an example of one of the events received at Seq? Particularly the message associated with the event - redacted if necessary of course. Any information about associated properties on the event would also help to debug this on this end. Thanks!

nblumhardt avatar Sep 23 '16 01:09 nblumhardt

Here's an example of a log message we are seeing in Seq

serilog500message

drjaydenm avatar Sep 23 '16 01:09 drjaydenm

Thanks for the info. I think what's probably happening here (at a guess) is that another handler/exception filter is handling the exception. Are there any other error-handling paths that might prevent the exception from bubbling up?

I've just merged #31 to switch the level to Error appropriately in this scenario, if you have a chance to grab the 2.0.10 build and check it out.

nblumhardt avatar Sep 23 '16 01:09 nblumhardt

Thanks for the speedy fix for that, seems to be logging with Error level now for 500 server errors, even with no exception data.

Regarding capturing exception data, I am using the <httpErrors> setup in web.config. I have worked out just now that exception info is captured for local requests but not remote ones. Any ideas what may be causing this? I though maybe there was a <customErrors> in the web.config, but it's not in there.

drjaydenm avatar Sep 23 '16 03:09 drjaydenm

I have found a solution. Adding customErrors Off like the below works. I have errors handled using IIS httpErrors still so it isn't showing the user any exception details. I tried setting customErrors to On and there is no exception info locally or remotely, DetailedLocal shows the original problem of exceptions locally and not remotely and Off shows exceptions for both.

I guess the solution is to make sure customErrors is set to Off!

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

drjaydenm avatar Sep 23 '16 05:09 drjaydenm

Thanks for the update. Looking into it further, it seems like generic error handling and customErrors are often at odds. I think we should keep this ticket open to collect more data, but I am glad to hear you found a resolution.

nblumhardt avatar Sep 29 '16 00:09 nblumhardt

Hi @drjaydenm I have same issue I had to turn off custom errors in web.config: <customErrors mode="Off"></customErrors>

But the IIS error pages are not working for me, could you plase share your web.config?

v1ct0rv avatar Oct 24 '16 13:10 v1ct0rv

I had to use httpErrors over custom errors for it to work correctly. The httpErrors work more at the IIS level than at the ASP level. You can read more about it here https://www.iis.net/configreference/system.webserver/httperrors

drjaydenm avatar Oct 24 '16 19:10 drjaydenm

I don't know if this will help, but in my case (MVC 5 app), the same app behvaes pretty differently depending on the settings .

  • On my local machine with those settings :
  <system.web>
    <compilation debug="true" targetFramework="4.6.1" />
    <customErrors mode="Off">
      <error statusCode="400" redirect="Error/Error400" />
      <error statusCode="401" redirect="Error/Error401" />
      <error statusCode="403" redirect="Error/Error403" />
      <error statusCode="404" redirect="Error/Error404" />
      <error statusCode="500" redirect="Error/Error500" />
    </customErrors>
  </system.web>

I do get the full exception details image

  • and on a more "prod-ish" environment with those settings (note the customErrors mode = "On") :
  <system.web>
    <compilation debug="false" targetFramework="4.6.1" />
    <customErrors mode="On">
      <error statusCode="400" redirect="Error/Error400" />
      <error statusCode="401" redirect="Error/Error401" />
      <error statusCode="403" redirect="Error/Error403" />
      <error statusCode="404" redirect="Error/Error404" />
      <error statusCode="500" redirect="Error/Error500" />
    </customErrors>

I don't have the exception details: image

In order to fix this, I had to remove the HandleErrorAttribute that was applied globally.

    public class FilterConfig
    {
        public static void RegisterGlobalFilters(GlobalFilterCollection filters)
        {
            //filters.Add(new HandleErrorAttribute{ View = "Error500", Order = 1 });
        }
    }

Without this handler, the app seems to behave the same way no matter the options.

tsimbalar avatar Sep 25 '17 11:09 tsimbalar