---
title: Limitations for Windows integration
source: https://docs.newrelic.com/docs/kubernetes-pixie/kubernetes-integration/troubleshooting/troubleshooting-windows
---

This page provides information about limitations and troubleshooting for New Relic's Kubernetes integration when running on Windows-based nodes.

## Checking the Windows Version [#windows-version]

> #### ⚠️ IMPORTANT
>
> When using containers in Windows, the container host version and the container image version must be the same. Our Kubernetes integration can run on Windows versions LTSC 2019 and LTSC 2022.

To check your Windows version, open a Powershell or command prompt window, and run:

```shell
  systeminfo
```

Look for the lines beginning with `OS Name` and `OS Version`. These lines provide the OS information and build number. This check is only to confirm that your environment is compatible; you don't need to specify this version information during installation.

-   Windows Server LTSC 2019: Corresponds to build number `10.0.17763`.
-   Windows Server LTSC 2022: Corresponds to build number `10.0.20348`.

## Windows DaemonSets [#windows-daemonsets]

When Windows monitoring is enabled, a Kubernetes DaemonSet is created for each supported Windows version, but pods are created only for Windows node versions that exist in the cluster. This means you may see multiple Windows-specific `DaemonSets`, but not all of them will have a `"desired"` pod count.

For example, in a cluster with two Linux nodes, one Windows LTSC 2022 node, and no Windows LTSC 2019 nodes, the output would be similar to this:

```shell
kubectl -n newrelic get daemonsets
NAME                                                DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR                                                          AGE
<...snip...>
newrelic-bundle-nrk8s-kubelet                       2         2         2       2            2           kubernetes.io/os=linux                                                 24h
newrelic-bundle-nrk8s-kubelet-windows-ltsc2019      0         0         0       0            0           kubernetes.io/os=windows,node.kubernetes.io/windows-build=10.0.17763   24h
newrelic-bundle-nrk8s-kubelet-windows-ltsc2022      1         1         1       1            1           kubernetes.io/os=windows,node.kubernetes.io/windows-build=10.0.20348   24h
```

If you want, you can prevent the chart from creating unnecessary `DaemonSets` by including the `windowsOsList` key in your custom `values.yaml` file while installing via Helm Chart and specifying only the desired version:

```yaml
windowsOsList:
  - version: ltsc2022                      # Human-readable version identifier
    imageTagSuffix: ltsc2022               # Tag to be used for nodes running the windows version above
    buildNumber: 10.0.20348                # Build number for the nodes running the version above. Used as a selector.
```

## Limitations to the Kubernetes integration for Windows [#k8-windows-limitations]

The New Relic agent for Windows sends [Kubernetes data samples](https://docs.newrelic.com/docs/kubernetes-pixie/kubernetes-integration/understand-use-data/find-use-your-kubernetes-data/#event-types), such as `K8sNodeSample` and `K8sPodSample`. The limitations that apply depend on whether you are running in privileged (HostProcess) mode or unprivileged mode.

### Unprivileged mode limitations [#unprivileged-mode-limitations]

When running in unprivileged mode (`windows.privileged=false`), standard Windows container isolation prevents the agent from directly accessing host resources. The following samples are not generated:

-   `SystemSample`
-   `StorageSample`
-   `NetworkSample`
-   `ProcessSample`

Additionally, `hostNetwork: true` cannot be set in the pod spec for standard Windows containers. This is a Kubernetes limitation that doesn't apply when using HostProcess pods in privileged mode.

### Windows kubelet metric gaps [#kubelet-gaps]

The following [Kubernetes metrics](https://docs.newrelic.com/docs/kubernetes-pixie/kubernetes-integration/understand-use-data/find-use-your-kubernetes-data/#event-types) are unavailable on all Windows nodes regardless of mode, because the Windows kubelet either doesn't expose them or they're not applicable on Windows:

-   Node:
    -   `memoryMajorPageFaultsPerSecond`: Always returns `0`.
    -   `memoryPageFaults`: Always returns `0`.
    -   `memoryRssBytes`: Always returns `0`.
    -   `net.errorsPerSecond`: Not sent.
    -   `net.rxBytesPerSecond`: Not sent.
    -   `net.txBytesPerSecond`: Not sent.
    -   Not relevant for Windows:
        -   `fsInodes`: Not sent.
        -   `fsInodesFree`: Not sent.
        -   `fsInodesUsed`: Not sent.
        -   `runtimeInodes`: Not sent.
        -   `runtimeInodesFree`: Not sent.
        -   `runtimeInodesUsed`: Not sent.
-   Container:
    -   `containerID`: Not sent.
    -   `containerImageID`: Not sent.
    -   `memoryMappedFileBytes`: Not sent.
    -   `memoryUsedBytes`: Not sent. Use `memoryWorkingSetBytes` as an alternative.
    -   `memoryUtilization`: Not sent (relies on `memoryUsedBytes`). You can compute a similar metric using `memoryWorkingSetBytes`/`memoryLimitBytes`.
    -   `requestedMemoryUtilization`: Not sent (relies on `memoryUsedBytes`). You can compute a similar metric using `memoryWorkingSetBytes`/`memoryRequestedBytes`.
    -   Not relevant for Windows:
        -   `cpuCfs*`: All `cpuCfs*` values not sent.
-   Volume:
    -   `fsUsedBytes`: Always returns `0`.
    -   `fsUsedPercent`: Always returns `0` (relies on `fsUsedBytes`).