A developer-friendly guide to dotnet, apphost, hostfxr, hostpolicy, CoreCLR, and BenchmarkDotNet runner processes

Most .NET developers think their application starts when Main() runs.

It does not.

Before the first line of your C# code executes, a native hosting layer has already done a surprising amount of work. It has located the correct .NET runtime, read your runtime configuration, resolved shared frameworks, prepared dependency loading, initialized CoreCLR, and then handed control to your managed entry point.

That native bootstrapper is the reason you sometimes see .NET Host, dotnet.exe, or your application executable lingering in Task Manager after you thought everything had stopped.

I never saw the .NET host process before until I started running into major BenchmarkDotNet issues while working on the latest edition of my code performance book. Benchmark runs would appear to freeze. Restarting the benchmark tests often failed. Sometimes the only fix was to kill the host process from Task Manager. Other times, I had to reboot the machine before the next benchmark run would work correctly.

That experience led me down the rabbit hole of how .NET applications actually start, why host processes remain alive, and why BenchmarkDotNet can expose shutdown problems that normal application runs hide.

The modern .NET host was added with .NET Core, starting with .NET Core 1.0, released in June 2016.

This article explains the .NET host process and shows how to diagnose it when it gets in your way.

Why the .NET Host Exists

The .NET host exists because a modern .NET application is not just one executable.

A .NET application may depend on:

• A specific .NET runtime version.
• One or more shared frameworks.
• A .runtimeconfig.json file.
• A .deps.json dependency graph.
• NuGet package assemblies.
• Native dependencies.
• Runtime configuration switches.
• A generated app executable.
• The CoreCLR runtime itself.

Something must connect all those pieces before managed code can run.

That “something” is the .NET hosting layer.

The host solves three core problems.

1. Runtime Selection

Multiple .NET runtimes can be installed side by side on the same machine. Your app may target .NET 8, .NET 9, .NET 10, or another supported runtime.

The host reads the application’s runtime configuration and determines which installed runtime should be used. It also applies roll-forward rules when an exact runtime version is not available.

2. Dependency Resolution

The host uses the application’s dependency information to determine where assemblies and native libraries should be loaded from.

This is one of the reasons the .deps.json file matters. It describes the application’s dependency graph so the runtime can resolve assemblies consistently.

3. Runtime Initialization

After the runtime and dependencies are resolved, the host initializes CoreCLR.

CoreCLR is the actual managed runtime. It provides the JIT compiler, garbage collector, threading services, exception handling, assembly loading, and managed execution environment.

Only after this initialization succeeds does your Main() method run.

The Hosting Pipeline at a Glance

A simplified startup flow looks like this:

dotnet.exe or apphost

        ↓

hostfxr

        ↓

hostpolicy

        ↓

CoreCLR

        ↓

Your managed Main() method

That flow changes slightly depending on how the application is deployed, but the major responsibilities remain the same.

The Main Components of the .NET Hosting Layer

dotnet — The Muxer

The dotnet executable is often called the muxer, short for multiplexer.

It is the command-line entry point used for many .NET operations, including:

dotnet build
dotnet test
dotnet publish
dotnet MyApp.dll

When you run a framework-dependent application as a DLL, such as:

dotnet MyApp.dll

the dotnet muxer determines that you want to run an application. It then locates hostfxr and transfers control to the rest of the hosting pipeline.

apphost — The Application Executable

Many .NET applications also have a native executable generated for them.

For example, your build output may contain:

MyApp.exe
MyApp.dll
MyApp.deps.json
MyApp.runtimeconfig.json

That MyApp.exe file is not your managed application in the old .NET Framework sense. It is a native apphost executable whose job is to start your managed application.

The apphost gives your application a normal executable name, icon, process identity, and operating-system entry point. Internally, it still participates in the same hosting process.

This is why a process may appear as your application name, even though it is still functioning as a .NET host bootstrapper.

hostfxr — The Framework Resolver

hostfxr is the brains of the hosting layer.

Its responsibilities include:

• Reading .runtimeconfig.json.
• Determining which shared framework is required.
• Applying roll-forward rules.
• Finding an installed compatible runtime.
• Loading hostpolicy.
• Passing control to the next layer.

If the runtime cannot be found, this is the stage where you usually see errors such as a missing .NET runtime, incompatible framework, or failed runtime resolution.

hostpolicy — The Runtime Policy Layer

hostpolicy is responsible for preparing the actual runtime launch.

It handles:

• Dependency resolution.
• Runtime configuration.
• Assembly probing paths.
• Native dependency loading.
• CoreCLR startup.
• Locating the managed entry point.

Once hostpolicy has done its work, CoreCLR can be initialized and your managed code can finally execute.

CoreCLR — The Managed Runtime

CoreCLR is the runtime that executes your .NET code.

It provides:

• JIT compilation.
• Garbage collection.
• Threading.
• Exception handling.
• Assembly loading.
• Type loading.
• Managed execution.

The host gets everything ready. CoreCLR runs the managed application.

Framework-Dependent vs. Self-Contained Applications

The hosting flow depends on how your app is deployed.

Framework-Dependent Applications

A framework-dependent app relies on a .NET runtime already installed on the machine.

It may be launched as:

dotnet MyApp.dll

or through a generated apphost executable:

MyApp.exe

In this model, the host resolves the correct installed runtime and shared framework before the app starts.

This deployment model keeps your app smaller, but the target machine must have a compatible runtime installed.

Self-Contained Applications

A self-contained app includes the runtime with the application.

Instead of relying on a system-installed .NET runtime, the published output includes the runtime files needed to run the app.

This makes deployment more predictable because the target machine does not need to have .NET installed separately. The tradeoff is that the published output is larger, and servicing the runtime usually means republishing the application.

A self-contained application still starts through a native executable, but the runtime components are app-local rather than resolved from the shared machine-wide runtime installation.

Single-File Applications

Single-file applications add another wrinkle.

They package application files into a single executable. Depending on the options used, some files may be bundled, extracted, loaded directly from the bundle, or kept alongside the executable.

This is convenient for deployment, but it can make troubleshooting more confusing because the visible executable does not always reflect everything being loaded internally.

Why You See “.NET Host” in Task Manager

On Windows, you may see a process listed as:

.NET Host

dotnet.exe

MyApp.exe

BenchmarkDotNet.Autogenerated.exe

The exact name depends on how the application was launched and how it was published.

Seeing .NET Host does not automatically mean something is wrong. It usually means a .NET application is still running through the native hosting layer.

The host itself is small. It is not doing your application’s work. It simply remains alive because the process is still alive.

If the process lingers, the real cause is usually one of these:

• A foreground thread is still running.
• A hosted service has not stopped.
• A benchmark left work behind.
• A child process is still alive.
• A profiler, diagnoser, or debugger is attached.
• Blocking I/O is preventing shutdown.
• A file handle is still open.
• A finalizer or cleanup path is stalled.
• Async code was started but never completed.
• A cancellation token was ignored.
• A deadlock occurred during shutdown.

In other words, the host is usually not the root problem.

It is the process shell still waiting for everything inside it to finish.

Why This Matters for BenchmarkDotNet

BenchmarkDotNet is intentionally more complicated than a normal console application run.

To produce reliable measurements, BenchmarkDotNet uses process-level isolation. It generates benchmark code, builds it, and runs benchmarks in separate processes. This helps isolate benchmark execution from the host application, but it also means every benchmark runner goes through the .NET hosting pipeline.

That means a BenchmarkDotNet run may involve:

• The original benchmark launcher process.
• Generated benchmark projects.
• Generated benchmark executables.
• Separate runner processes.
• Build artifacts.
• Diagnostic tools.
• Profilers or ETW/EventPipe sessions.
• Temporary files.
• Log files.
• Child processes.

When everything works, this isolation is one of BenchmarkDotNet’s strengths.

When something hangs, it can be frustrating because the process you need to kill may not be obvious.

A stuck benchmark runner may show up as .NET Host, dotnet.exe, or a generated BenchmarkDotNet executable. If that process does not exit cleanly, the next benchmark run can fail because files are locked, diagnosers are still attached, or the previous runner process is still alive.

How BenchmarkDotNet Host Processes Can Get Stuck

A BenchmarkDotNet runner process may linger for many reasons.

Common causes include:

• Fire-and-forget tasks started during a benchmark.
• Background work created in GlobalSetup.
• Services that do not honor cancellation.
• HttpClient, streams, timers, or subscriptions are not disposed.
• Blocking calls such as .Result, .Wait(), or Thread.Sleep() in the wrong place.
• Child processes launched by benchmark code.
• Profilers or diagnosers that do not detach cleanly.
• ETW/EventPipe sessions that remain active.
• Excessive output to redirected streams.
• Cleanup code that deadlocks.
• Finalizers waiting on locks or unmanaged resources.
• Native dependencies that do not unload cleanly.

The result can look like BenchmarkDotNet froze, when the actual issue is that the generated runner process never completed shutdown.

Symptoms of a Stuck Host Process

You may be dealing with a lingering host process if you see symptoms such as:

• BenchmarkDotNet appears frozen.
• A benchmark run never reaches the summary.
• A generated benchmark executable remains in Task Manager.
• A .NET Host process remains after stopping the run.
• Re-running the benchmark immediately fails.
• Build output folders cannot be cleaned.
• Files in BenchmarkDotNet.Artifacts are locked.
• Visual Studio cannot rebuild the benchmark project.
• The only way to continue is to kill the host process.
• In the worst case, rebooting clears the issue.

This is exactly the type of problem I started seeing while running large benchmark suites for my performance work.

At first, it looked random. Eventually, I realized the host process was not the real villain. It was the visible process left behind after something inside the benchmark runner failed to shut down correctly.

How to Diagnose a Lingering .NET Host Process

1. Inspect the Process Command Line

Start with Task Manager or Process Explorer.

In Task Manager:

1. Go to the Details tab.
2. Right-click the header row.
3. Choose Select columns.
4. Enable Command line.

The command line often reveals exactly what is being hosted.

You may see something like:

dotnet MyBenchmark.dll

or a generated BenchmarkDotNet executable with arguments such as:

–benchmarkId

–benchmarkName

That tells you whether the process belongs to your app, BenchmarkDotNet, Visual Studio, a test runner, or another tool.

2. Check the Parent Process

Process Explorer is useful because it shows parent-child relationships.

For BenchmarkDotNet, this can help you identify whether the lingering process was launched by:

• Visual Studio.
• Rider.
• dotnet test.
• Your benchmark console app.
• BenchmarkDotNet itself.
• A generated benchmark runner.

This is often faster than guessing based on process name alone.

3. Look for Locked Files and Handles

If the next run fails because files are locked, use Process Explorer to inspect handles.

Look for handles pointing to:

BenchmarkDotNet.Artifacts

bin

obj

*.dll

*.exe

*.pdb

*.json

*.log

A locked generated executable or assembly is a strong sign that a previous runner process is still alive.

4. Enable Host Tracing

Host tracing can show what the .NET hosting layer is doing during startup.

For .NET 10 and later, use:

$env:DOTNET_HOST_TRACE="1"
$env:DOTNET_HOST_TRACEFILE="host_trace.txt"
$env:DOTNET_HOST_TRACE_VERBOSITY="4"

Then run the app or benchmark again.

For older .NET versions, use the older variable names:

$env:COREHOST_TRACE="1"
$env:COREHOST_TRACEFILE="host_trace.txt"
$env:COREHOST_TRACE_VERBOSITY="4"

Host tracing is especially useful when you suspect:

• The wrong runtime is being selected.
• The wrong framework is being resolved.
• Roll-forward behavior is not what you expected.
• A runtime cannot be found.
• A generated BenchmarkDotNet runner is using a different runtime than expected.

5. Review BenchmarkDotNet Build Artifacts

BenchmarkDotNet writes generated files into its artifacts folder.

Check:

BenchmarkDotNet.Artifacts

Depending on the failure, you may find:

• Generated source files.
• Generated project files.
• Build scripts.
• Logs.
• Result files.
• Diagnoser output.

If the problem is build-related, run BenchmarkDotNet with:

–logBuildOutput

This gives you more detail about restore and build failures.

6. Debug the Benchmark Runner Process

If the benchmark builds but hangs during execution, debug the generated process.

One option is to temporarily use BenchmarkDotNet’s in-process debug configuration. Another option is to attach the debugger to the benchmark process itself.

The important part is this: attach to the process running the benchmark, not just the original launcher process.

BenchmarkDotNet runner processes usually include command-line arguments that identify the benchmark ID and benchmark name. Use those to find the correct process.

Practical Mitigations

These are the changes that usually make BenchmarkDotNet host-process problems less painful.

Keep Diagnosers Minimal

Only enable the diagnosers you need.

Start with the smallest possible configuration. Add MemoryDiagnoser, DisassemblyDiagnoser, EventPipeProfiler, or other diagnosers one at a time.

If the hang appears only when a specific diagnoser is enabled, you have narrowed the search dramatically.

Clean Up Everything You Start

Benchmark code should leave the process as clean as it found it.

That means:

• Dispose IDisposable and IAsyncDisposable instances.
• Stop timers.
• Cancel background operations.
• Complete channels.
• Close streams.
• Dispose subscriptions.
• Stop hosted services.
• Kill or wait for child processes.
• Release unmanaged resources.

Use GlobalCleanup for benchmark-level cleanup and make it boring, predictable, and defensive.

Avoid Fire-and-Forget Work

Fire-and-forget tasks are dangerous in benchmarks.

This is especially true for code like:

_ = Task.Run(SomeWorkAsync);

If the benchmark method returns before that work completes, BenchmarkDotNet may continue while the runner process still has active work in progress.

Benchmarks should measure completed work, not launched work.

Respect Cancellation Tokens

If your benchmark involves services, queues, hosted workers, channels, or async loops, make cancellation mandatory.

Shutdown paths should not rely on hope.

Avoid Blocking Async Code

Avoid mixing async and blocking calls such as:

.Result
.Wait()
.GetAwaiter().GetResult()

These can contribute to deadlocks or shutdown delays, especially in more complicated test or benchmark environments.

Keep Benchmark State Isolated

Each benchmark should own its setup and cleanup.

Avoid shared static state unless it is intentional and safe. Shared state can easily survive longer than expected and cause the next benchmark run to behave differently.

Upgrade BenchmarkDotNet and the .NET SDK

Some hang scenarios have been fixed over time in BenchmarkDotNet and the .NET runtime.

When diagnosing strange behavior, verify that you are not fighting an old tooling issue that has already been addressed.

Clean the Artifacts Folder

If a previous run failed badly, delete:

BenchmarkDotNet.Artifacts

bin

obj

Then rebuild and rerun the benchmark.

If files cannot be deleted, a process still has them open.

A BenchmarkDotNet Shutdown Checklist

When BenchmarkDotNet appears stuck, I now ask these questions:

• Is a generated benchmark runner still running?
• Is .NET Host still visible in Task Manager?
• Does the command line show a BenchmarkDotNet-generated executable?
• Are files locked in BenchmarkDotNet.Artifacts?
• Is a diagnoser or profiler enabled?
• Did the benchmark start background work?
• Did GlobalSetup create anything that GlobalCleanup failed to stop?
• Are there unmanaged resources or native dependencies involved?
• Are child processes still alive?
• Is async code being blocked?
• Are cancellation tokens ignored?
• Does host tracing show the expected runtime?
• Does BenchmarkDotNet build output reveal a generated project issue?

This checklist has saved me a lot of time.

What I Changed in My Benchmarking Work

After running into these issues repeatedly, I made changes in my dotNetTips.Spargine.Benchmarking assembly and NuGet package to reduce the likelihood of stuck benchmark runs. If you use the Benchmark class as your base class, these fixes have already been made.

The goal was not to “fix” the .NET host. The host was doing what it was supposed to do.

The goal was to make my benchmark code more disciplined about setup, cleanup, process behavior, and diagnostics.

So far, those changes have almost eliminated the stuck-host issues in my benchmark runs.

That was a hard-earned lesson: when the host appears stuck, the real problem is usually somewhere in the managed workload, benchmark setup, cleanup code, diagnoser pipeline, or child process behavior.

Figuring this out took me months!

Important: Do not apply BenchmarkDotNet’s [MemoryDiagnoser] attribute to a base class. I made that mistake in Spargine’s Benchmark base type, and it turned out to be the primary cause of the issue. Moving the attribute out of the base class made a dramatic difference. I still do not know exactly why this change had such a significant effect, but it was the critical fix.

Summary

The .NET host process is one of the most important pieces of .NET infrastructure that most developers rarely think about.

It runs before your managed code. It selects the runtime, resolves frameworks, loads hosting components, initializes CoreCLR, and finally launches your application.

Most of the time, it works so well that you never notice it.

But when something goes wrong—especially with BenchmarkDotNet, profilers, diagnosers, hosted services, background work, or locked files—the host process becomes visible. You may see .NET Host, dotnet.exe, your application executable, or a generated BenchmarkDotNet runner still alive in Task Manager.

When that happens, do not assume the host itself is broken.

Start by asking what the hosted process is still waiting on.

Check the command line. Check the parent process. Look for locked files. Review BenchmarkDotNet artifacts. Minimize diagnosers. Enable host tracing. Make sure every task, service, timer, stream, child process, and unmanaged resource is cleaned up correctly.

I learned this the hard way while working on my code performance book. Benchmark runs would hang, reruns would fail, and the only visible clue was a lingering .NET host process.

The good news is that once you understand what the host does, the problem becomes much easier to diagnose. The next time a .NET app, service, test run, or benchmark appears stuck, check Task Manager or Process Explorer. That quiet little host process may be the clue that points you to the real problem.

Pick up any books by David McCarter by going to Amazon.com: http://bit.ly/RockYourCodeBooks

If you liked this article, please buy David a cup of Coffee by going here: https://www.buymeacoffee.com/dotnetdave

© The information in this article is copywritten and cannot be reproduced in any way without express permission from David McCarter.