In combination with serilog some exception logging throws the following exception:
Assert Failure
Expression: [Recursive resource lookup bug]
Description: Infinite recursion during resource lookup within System.Private.CoreLib. This may be a bug in System.Priva
te.CoreLib, or potentially in certain extensibility points such as assembly resolve events or CultureInfo names. Resour
ce name: ArgumentNull_Generic
Stack Trace:
at System.SR.InternalGetResourceString(String key)
at System.SR.GetResourceString(String resourceKey, String defaultString)
at System.ArgumentNullException..ctor(String paramName)
at System.Runtime.Loader.AssemblyLoadContext.GetLoadContext(Assembly assembly)
at System.Reflection.Assembly.LoadFromResolveHandler(Object sender, ResolveEventArgs args)
at System.AppDomain.OnAssemblyResolveEvent(RuntimeAssembly assembly, String assemblyFullName)
at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, Runtim
eAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntro
spection, Boolean suppressSecurityChecks, IntPtr ptrLoadContextBinder)
at System.Reflection.RuntimeAssembly.InternalGetSatelliteAssembly(String name, CultureInfo culture, Version version,
Boolean throwOnFileNotFound, StackCrawlMark& stackMark)
at System.Resources.ManifestBasedResourceGroveler.GetSatelliteAssembly(CultureInfo lookForCulture, StackCrawlMark& st
ackMark)
at System.Resources.ManifestBasedResourceGroveler.GrovelForResourceSet(CultureInfo culture, Dictionary`2 localResourc
eSets, Boolean tryParents, Boolean createIfNotExists, StackCrawlMark& stackMark)
at System.Resources.ResourceManager.InternalGetResourceSet(CultureInfo requestedCulture, Boolean createIfNotExists, B
oolean tryParents, StackCrawlMark& stackMark)
at System.Resources.ResourceManager.InternalGetResourceSet(CultureInfo culture, Boolean createIfNotExists, Boolean tr
yParents)
at System.Resources.ResourceManager.GetString(String name, CultureInfo culture)
at System.SR.InternalGetResourceString(String key)
at System.SR.GetResourceString(String resourceKey, String defaultString)
at System.ArgumentNullException..ctor(String paramName)
at System.Runtime.Loader.AssemblyLoadContext.GetLoadContext(Assembly assembly)
at System.Reflection.Assembly.LoadFromResolveHandler(Object sender, ResolveEventArgs args)
at System.AppDomain.OnAssemblyResolveEvent(RuntimeAssembly assembly, String assemblyFullName)
at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, Runtim
eAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntro
spection, Boolean suppressSecurityChecks, IntPtr ptrLoadContextBinder)
at System.Reflection.RuntimeAssembly.InternalGetSatelliteAssembly(String name, CultureInfo culture, Version version,
Boolean throwOnFileNotFound, StackCrawlMark& stackMark)
at System.Resources.ManifestBasedResourceGroveler.GetSatelliteAssembly(CultureInfo lookForCulture, StackCrawlMark& st
ackMark)
at System.Resources.ManifestBasedResourceGroveler.GrovelForResourceSet(CultureInfo culture, Dictionary`2 localResourc
eSets, Boolean tryParents, Boolean createIfNotExists, StackCrawlMark& stackMark)
at System.Resources.ResourceManager.InternalGetResourceSet(CultureInfo requestedCulture, Boolean createIfNotExists, B
oolean tryParents, StackCrawlMark& stackMark)
at System.Resources.ResourceManager.InternalGetResourceSet(CultureInfo culture, Boolean createIfNotExists, Boolean tr
yParents)
at System.Resources.ResourceManager.GetString(String name, CultureInfo culture)
at System.SR.InternalGetResourceString(String key)
at System.SR.GetResourceString(String resourceKey, String defaultString)
at System.IO.FileNotFoundException.ToString()
at System.String.Concat(Object arg0, Object arg1)
at Serilog.Formatting.Display.MessageTemplateTextFormatter.Format(LogEvent logEvent, TextWriter output)
at Serilog.Sinks.RollingFileAlternate.Sinks.SizeRollingFileSink.SizeLimitedFileSink.Emit(LogEvent logEvent)
at Serilog.Sinks.RollingFileAlternate.Sinks.SizeRollingFileSink.AlternateRollingFileSink.Emit(LogEvent logEvent)
at Serilog.Core.Sinks.SafeAggregateSink.Emit(LogEvent logEvent)
at Serilog.Core.Logger.Write(LogEventLevel level, Exception exception, String messageTemplate, Object[] propertyValue
s)
at Serilog.Core.Logger.Error(Exception exception, String messageTemplate)
at CodeTest.Program.Main(String[] args) in C:\git\MFCLib\CodeTest\Program.cs:line 17
Steps to reproduce:
Project file:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp2.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Serilog" Version="2.5.0" />
<PackageReference Include="Serilog.Sinks.RollingFileAlternate" Version="2.0.9" />
</ItemGroup>
</Project>
Program.cs:
using System;
using System.Reflection;
using Serilog;
using Serilog.Sinks.RollingFileAlternate;
namespace CodeTest
{
class Program
{
static void Main(string[] args)
{
var logger = new LoggerConfiguration()
.WriteTo.RollingFileAlternate(".\\logs")
.CreateLogger();
try
{
var libAssembly = Assembly.LoadFrom("lib.dll");
}
catch (Exception e)
{
logger.Error(e, "catch test {message}");
}
}
}
}
One additional remark. When trying with other exceptions like division by zero the code works as expected.
Additional Info: My machine runs with German Locale
@ltd65 this was https://github.com/dotnet/coreclr/issues/12668 which was fixed with https://github.com/dotnet/coreclr/pull/13003/files but unfortunately this missed the cutoff for the 2.0 release. We will try to service for it.
Meantime can you try this workaround. Put new ArgumentException(); on the first line of Main. Assuming that code runs before the Assembly.LoadFrom and other lookups, this should cause the neutral resources to be cached, avoiding the failure.
This avoids the crash for me (using the code above and putting CultureInfo.CurrentUICulture = new CultureInfo("de-CH"); to simulate machine culture)
Thanks for the Workaround. Works for me. The "real exe" is anyhow only a temporary bootloader to Support switching an older full .net lib to netstandard2 and also core2 as new target.
@danmosemsft you might want to look at changing the milestone on https://github.com/dotnet/coreclr/issues/12668 to indicate something other than 2.0.0 since it appears that the problem should be fixed in that release.
@dbelcham I changed to 2.0.x to indicate servicing.
@danmosemsft should we close it as dupe or is there more to it?
Yes, I think this can be closed as dupe.
@danmosemsft Thank you for sharing the workaround can you please share sample code of it, i have been trying to resolve this issue but i am not able to.
@mlawand have you put new ArgumentException() at the start of your Main or equivalent in your web app?
@danmosemsft something like this.
`public static void Main(string[] args)
{
new ArgumentException();
BuildWebHost(args).Run();
}
public static IWebHost BuildWebHost(string[] args) =>
WebHost.CreateDefaultBuilder(args)
.UseStartup<Startup>()
.Build();
`
Yes, did it not work?
no it didn't
@danmosemsft i have 4 languages within my app, English, Arabic, Spanish and French. only English is working
I'm also seeing this issue in an Azure web app with the .NET Core 2.0.0 SDK, but ONLY if the Application Insights extension is installed. Languages are en-CA and fr-CA.
The workaround didn't work for me either.
The exact trigger for this bug is: there is a AssemblyResolve handler that has a bug: it either returns an assembly that does not match or it throws. It turns out that Assembly.LoadFrom always registers an AssemblyResolve handler with this bug. So another workaround is to remove such an AssemblyResolve handler, and avoid Assembly.LoadFrom. Of course, very often the app does not control whever code is doing this. Eg., it sounds like AppInsights may be doing this.
@kouvel @tarekgh did we conclude there was otheriwse no workaround except forcing en-US (as some people are doing) ?
Meanwhile, this is in the servicing branch and we are aiming to release it in November.
@kouvel @tarekgh did we conclude there was otheriwse no workaround except forcing en-US (as some people are doing) ?
I am not aware of any other workaround other than forcing en-US as current UI culture.
Is there a way they can opt-in using the new servicing bits of 2.0?
@tarekgh yes it should be possible to follow these instructions:
https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/dogfooding.md#advanced-scenario---using-a-nightly-build-of-microsoftnetcoreapp
and it would be good too, as it would confirm that the issue is fixed.
Do you have time to try this out and report back?
@chris-nissen did you find another workaround?
Sorry, no--my "solution" was just to remove the App Insights extension from my web app for the time being, until .NET Core 2.0.2 is available in Azure.
Fix released https://github.com/dotnet/corefx/releases/tag/v2.0.3
Most helpful comment
@ltd65 this was https://github.com/dotnet/coreclr/issues/12668 which was fixed with https://github.com/dotnet/coreclr/pull/13003/files but unfortunately this missed the cutoff for the 2.0 release. We will try to service for it.
Meantime can you try this workaround. Put
new ArgumentException();on the first line of Main. Assuming that code runs before the Assembly.LoadFrom and other lookups, this should cause the neutral resources to be cached, avoiding the failure.This avoids the crash for me (using the code above and putting
CultureInfo.CurrentUICulture = new CultureInfo("de-CH");to simulate machine culture)