Exception in DeveloperProblemDetails.GetErrors() while executing the problem details middleware
See original GitHub issueI sometimes get the following exception in my server log:
An exception was thrown attempting to execute the problem details middleware.
System.BadImageFormatException: Invalid directory size.
bei System.Reflection.PortableExecutable.PEReader.ReadDebugDirectory()
bei Microsoft.Extensions.StackTrace.Sources.PortablePdbReader.GetPdbPath(String assemblyPath)
bei Microsoft.Extensions.StackTrace.Sources.PortablePdbReader.GetMetadataReader(String assemblyPath)
bei Microsoft.Extensions.StackTrace.Sources.PortablePdbReader.PopulateStackFrame(StackFrameInfo frameInfo, MethodBase method, Int32 IlOffset)
bei Microsoft.Extensions.StackTrace.Sources.StackTraceHelper.GetFrames(Exception exception)
bei Microsoft.Extensions.StackTrace.Sources.ExceptionDetailsProvider.<GetDetails>d__3.MoveNext()
bei Hellang.Middleware.ProblemDetails.DeveloperProblemDetails.<GetErrors>d__4.MoveNext()
bei System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
bei System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
bei Hellang.Middleware.ProblemDetails.DeveloperProblemDetails..ctor(ExceptionProblemDetails problem, IEnumerable`1 details)
bei Hellang.Middleware.ProblemDetails.ProblemDetailsMiddleware.GetDetails(HttpContext context, Exception error)
I’m not sure how to reproduce it, but from reading the stack trace I have an idea what might happen:
The top methods of the exception call stack indicate that it crashes while reading a PDB file. The problem I see here is that that class name indicates that it tries to read a portable PDB. But my application is running ASP.NET Core 2.2 on the full .NET Framework 4.7.1 since some used libraries are not available as .NET Core or .NET Standard builds. Those libraries also use non-portable PDB files. So I assume the crash happens because it tries to read a non-portable PDB file assuming it is a portable one.
I’m using ProblemDetails package version 3.1.0.
Issue Analytics
- State:
- Created 4 years ago
- Comments:16 (8 by maintainers)
Top Results From Across the Web
Handling Web API Exceptions with ProblemDetails ...
In this short post I describe a handy error-handling middleware, created by Kristian Hellang, that is used to return ProblemDetails results ...
Read more >Exception handling using Hellang middleware in .Net Core ...
I've added the following code in the ConfigureServices method in Startup.cs: services.AddProblemDetails(opts => { // Control when an exception ...
Read more >Handle errors in ASP.NET Core web APIs
In Program.cs , call UseExceptionHandler to add the Exception Handling Middleware: C# Copy. var app = builder.Build(); app.UseHttpsRedirection ...
Read more >How to use the ProblemDetails middleware in ASP.NET Core
NET Core middleware from Kristian Hellang that can be used to generate detailed results for the exceptions that occur in your application.
Read more >Problem Details responses everywhere with ASP.NET ...
It was possible to return the Problem Details response manually, or the framework could generate it automatically in several specific cases.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Nice! That’s a really well written issue! ✨
It really depends on how fast it’s fixed upstream. Since it’s just a source package, I can easily pull the latest from MyGet and ship a new version without making source changes to the middleware itself. I’ll see if maybe I can fix it myself and send a PR upstream.
Doesn’t look like it’s gotten to reading pdb yet, but throws while reading the dll to get the debug directory info.
I looked quickly at the code wondering if there was something letting go of the PE memory, but it looks ok.
The next thing I’d want to try would be to inspect the dll to see if it is in fact corrupted. Are you able to debug and determine what
assemblyPath
parameter is here?Cc @tmat