Windows platform notes

How the agent runs on Windows. For installation, see the Windows installation guide. For how each runtime is instrumented, see the Application APM language pages, starting with .NET.

A different mechanism, the same model

Windows has no LD_PRELOAD and no production eBPF, so the agent uses Windows-native mechanisms. It keeps the same discover, instrument, and report model as the other platforms. Instead of systemd config files, the agent uses the Windows registry, the Service Control Manager, and Internet Information Services (IIS) configuration.

Discovery

To build the Discovered Services list, the agent looks at:

• IIS sites and application pools, including each pool’s managed runtime version and state. These appear with a kind of iis.
• Windows services, through the Service Control Manager. These appear with a kind of windows_service.
• Listening ports, so it can map applications to ports.

See Discovery.

Which Windows services are listed

The agent lists a Windows service when it recognizes what the service runs. It identifies a service in two ways.

First it matches the executable name from the service’s binary path against the runtimes and databases it supports:

• Runtimes: java.exe, javaw.exe, node.exe, python.exe, pythonw.exe, and dotnet.exe.
• Databases: sqlservr.exe, postgres.exe, and mysqld.exe.

If the name says nothing, the agent reads the executable’s PE headers and checks for a CLR header. This is how it finds a self-contained .NET service, published as its own executable and named after the application, such as MyCompany.Worker.exe. Nothing in that name identifies it as .NET, but the file itself does. The agent reads the file and never runs it.

It also tells .NET Framework and .NET apart, by looking for a runtimeconfig.json file next to the executable. The two use different profilers, so the distinction decides how the service is instrumented.

A service that matches neither check is left out, which keeps the several hundred built-in Windows services off the list. The agent also skips executables in Windows-owned directories such as C:\Windows\System32, since none of them is an application workload.

IIS application pools are discovered separately, through applicationHost.config, and are not subject to any of this.

ETW monitoring

Because Windows has no eBPF, the agent gives you equivalent zero-code monitoring through a custom Event Tracing for Windows (ETW) receiver. The receiver taps the HTTP.sys provider to emit server spans (at the request-path level) and Rate, Errors, and Duration (RED) metrics for IIS traffic, with no injection. This covers workloads that cannot use the .NET profiler, including legacy .NET Framework 3.5 pools and non-.NET applications on IIS. The receiver reads events only and makes no changes to your applications. See .NET for how the CLR profiler and ETW monitoring work together.

ETW is opt-in, exactly like eBPF on Linux. The agent collects an application pool only after you turn tracing on for it, and it collects nothing at all while no pool is enabled. Turning a pool off stops both its spans and its RED metrics.

Injection mechanisms

• .NET is instrumented with the Common Language Runtime (CLR) profiler. The agent writes the profiler’s environment directly to the registry or to the IIS applicationHost.config. On IIS 10 and newer, it can do this per application pool.
• Java, Node.js, and Python are instrumented through the per-service registry environment.

See the Application APM language pages for the details.

Privileges

The agent runs as a Windows service under the Local System account, which gives it the access it needs to:

• Read IIS configuration, query the Service Control Manager, and read the system TCP table to map ports to processes.
• Write the registry and applicationHost.config entries for instrumentation, and recycle pools or restart services.
• Register as an ETW consumer, which requires elevation.

Automatic collection

The agent automatically collects Windows host metrics: CPU, memory, disk, and network usage.

That is all it collects on its own. Traces, including the ETW monitoring described above, need you to turn tracing on for a service first.

No logs are collected from the host automatically. The agent doesn’t read the Windows Event Log unless you ask it to: to send a channel such as System or Application, add an eventlog source in log monitoring. See Host metrics and logs.

Next steps

Install on Windows Installer download and setup.

.NET application APM Instrument .NET on IIS and Windows services.

Host metrics and logs Metrics and logs collected automatically on Windows.