Dear team, We are using RFA.NET 7 libraries in our WCF service. The WCF service is built on .NET framework v4.0. We are experiencing the below mentioned error when we are trying to connect to Reuters from the WCF service Error: Application: DataService.Server.WCF.Service.exe Framework Version: v4.0.30319 Description: The process was terminated due to an internal error in the .NET Runtime at IP 000007FEF9131A48 (000007FEF9060000) with exit code 80131506 When we checked the problem on MSDN sites, we came to know that it is because of concurrent garbage collection and we have disabled it by setting <gcConcurrent enabled=false/> in the app.config file. Even then, we are facing this error. Upon investigation, came to know that the exception purely occurs when an unmanaged code is not properly disposing the objects via the GC Investigation point: the problem was a C++/CLI library in which there was a call to the NtQuerySystemInformation; for some kind of reason sometimes (and under mysterious circumstances), when it was called the CLR heap got corrupted and the application crashed. So, we assume that the RFA.NET 7 library is built on C++ and could you please investigate on the occurance of this error from your end Describe the bugGetting below error msgs from Eventlog. After 5 times repeated messages, the specific application pool completely shuts down (no restarting). Entry 1 (in event log)
Entry 2
Entry 3 - note: WER and TEMP folders does not contain the stated files:
Entry 4
Now after 4th entry log, I see the specific application pool is restarted. This entire process happens 3 times in total - in about 2-3 minutes time total. In this particular case, 8 hours pass and we see a similar process repeating again. To ReproduceSteps to reproduce the behavior: <configuration> <system.webServer> <handlers> <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" requireAccess="Script" /> </handlers> <aspNetCore processPath=".\myproject.exe" arguments="exec "C:\Web\myproject\myproject\bin\Release\netcoreapp2.2\myproject.dll"" stdoutLogEnabled="true" stdoutLogFile=".\logs\log" hostingModel="InProcess"> <handlerSettings> <handlerSetting name="debugLevel" value="file" /> <handlerSetting name="debugFile" value=".\logs\ancm.log" /> </handlerSettings> <environmentVariables> <environmentVariable name="ASPNETCORE_HTTPS_PORT" value="443" /> <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Production" /> </environmentVariables> </aspNetCore> We have a bunch of these errors in the stdout log - but they have been there in ASP.NET Core 2.1.x as well: warn: Microsoft.AspNetCore.Antiforgery.Internal.DefaultAntiforgery[8] The 'Cache-Control' and 'Pragma' headers have been overridden and set to 'no-cache, no-store' and 'no-cache' respectively to prevent caching of this response. Any response that uses antiforgery should not be cached. FROM ANCM log
Attached is WER file I managed to find. We are using the temp bug fix for getting CurrentDirectory (see #4206 (comment)) in Program.cs using Microsoft.AspNetCore; using Microsoft.AspNetCore.Hosting; using myproject.Helpers; namespace myproject { public static class Program { public static void Main(string[] args) { CurrentDirectoryHelpers.SetCurrentDirectory(); // asp.net core 2.2 hack. In 3.0 this will be fixed: https://github.com/aspnet/AspNetCore/issues/4206#issuecomment-445612167 CreateWebHostBuilder(args).Build().Run(); } public static IWebHostBuilder CreateWebHostBuilder(string[] args) => WebHost.CreateDefaultBuilder(args) .UseStartup<Startup>(); } } Additional contextdotnet --info
|