Windows10下IIS中ASP.NET Core应用频繁崩溃排查求助

Let’s walk through actionable, practical steps to diagnose and fix this frequent crash issue, based on the details you’ve shared:

1. Capture Detailed Crash Dumps & Managed Exception Logs #

The exception code 0xe0434352 is a CLR-level unhandled exception—system event logs only give surface-level info. To get the actual stack trace that points to your code:

• Enable crash dumps for .NET Core by setting these environment variables for your app:

  COMPlus_DbgEnableMiniDump=1
  COMPlus_DbgMiniDumpPath=C:\CrashDumps
  

  Make sure the C:\CrashDumps folder exists and has write permissions for your app pool identity. When the app crashes, a .dmp file will be generated here.
• Use tools like dotnet-dump (CLI) or WinDbg to analyze the dump file—this will show you exactly which managed code threw the unhandled exception.
• Boost your app’s logging verbosity to Debug level for categories like Microsoft.AspNetCore, System, and your own application namespaces. Check the logs right before a crash for any warning/error patterns that lead up to the failure.

2. Investigate Periodic Tasks/Code Paths #

Since the crash happens every 2 minutes, it’s almost certainly tied to a recurring process:

• Check for scheduled tasks (e.g., IHostedService with timers, Hangfire jobs, Quartz.NET triggers) that run on a 2-minute interval.
• Look for cache expiration policies, background queue processing, or recurring external API calls that fire every 2 minutes.
• Review the code in these paths for unhandled exceptions—things like database connection failures, null references, or unhandled HTTP client errors that aren’t being caught and logged properly.

3. Dig Deeper into Windows Event Logs #

Beyond the faulting app entry you shared:

• Check the Application log for other errors/warnings from your app or the .NET Runtime that occur at the same timestamp as the crash.
• Look into Windows Error Reporting logs (under Applications and Services Logs > Microsoft > Windows > Windows Error Reporting) — these often include a more detailed exception stack trace for CLR crashes.
• Verify there are no system-level issues like low disk space, memory pressure (even if private bytes aren’t rising, check for virtual memory limits), or permission issues with the app’s file system/database access.

4. Check .NET Core Version Compatibility #

You’re running .NET Core 1.1.0, which is an older, out-of-support version with known bugs that could be causing this:

• Upgrade to the latest patch version of .NET Core 1.1 (e.g., 1.1.13) to see if the issue is resolved by a pre-existing bug fix.
• If possible, plan a migration to a supported .NET version (like .NET 6 or 7) — not only will this fix old bugs, but it’ll also give you better debugging tools and performance improvements.

5. Audit Dependencies & Native Modules #

The faulting module being KERNELBASE.dll can sometimes point to issues with native dependencies:

• Use dotnet list package to audit your NuGet packages. Look for outdated packages, especially those that include native components (e.g., database drivers, SDKs for third-party services).
• Ensure all native dependencies are compatible with your Windows Server version (your KERNELBASE.dll is from Windows Server 2016, build 14393).
• Check for conflicts between different versions of the same dependency (e.g., multiple versions of Newtonsoft.Json or a database driver).

6. Isolate & Test Scenarios #

Narrow down the root cause by disabling non-core functionality:

• Temporarily turn off scheduled tasks, third-party integrations, or background processing. If the app stops crashing, re-enable each component one by one to find the culprit.
• Reproduce the issue in a staging environment, then attach a debugger (like Visual Studio or Rider) to the dotnet.exe process. This will let you catch the exception in real-time and inspect variables/stack traces when the crash occurs.

内容的提问来源于stack exchange，提问作者Maciejek