Troubleshooting Kernel Event ID 2 with MSFT_NetLbfoTeamNic on Windows Server

Table of Contents

This article addresses a specific issue encountered in Windows Server 2012 R2 environments utilizing the NIC Teaming feature. The problem manifests as kernel event ID 2 being logged when a third-party Windows Management Instrumentation (WMI) provider interacts with the MSFT_NetLbfoTeamNic class. This event, while potentially alarming, often indicates a harmless scenario that can be effectively managed. Understanding the underlying cause and available workarounds is crucial for administrators maintaining these systems. This guide provides a detailed explanation of the issue, its root cause, and practical steps to mitigate or suppress the error logging.

Symptoms¶

In Windows Server 2012 R2 environments where NIC Teaming is actively used, and a third-party WMI provider attempts to access the MSFT_NetLbfoTeamNic WMI class, a specific event may be recorded in the system’s event logs. This event is identified as Kernel event ID 2 and originates from the Kernel-EventTracing/Admin source. The event details typically include an error message indicating that a session has failed to start with error code 0xC0000022.

The precise event log entry will resemble the following format:

Source: Kernel-EventTracing/Admin
Event ID: 2
Session “” failed to start with the following error: 0xC0000022

It is important to note that while this article specifically focuses on event ID 2 related to NIC Teaming and the MSFT_NetLbfoTeamNic class, this event ID can also be triggered by other unrelated issues. Therefore, careful diagnosis is essential to confirm that the observed event aligns with the scenario described herein before applying the suggested workarounds. This particular issue is not attributed to any fault within the third-party WMI provider itself but rather stems from internal Windows Server configurations.

Cause¶

The occurrence of kernel event ID 2 in this context is not due to any malfunction or error within the third-party WMI provider. Instead, the underlying cause is related to file permission restrictions within the Windows operating system itself. Specifically, the Windows Server 2012 R2 MSFT_NetLbfoTeamNic WMI class relies on the iNetCfg interface for its operations. This iNetCfg interface is inherently linked to the NetCfgTrace kernel logging provider, which is a component automatically enabled by the Windows operating system to facilitate diagnostic tracing.

Whenever NetCfgTrace is active, it automatically attempts to save trace data to a designated file located at C:\Windows\inf\netcfgx.0.etl. WMI providers, including third-party providers interacting with MSFT_NetLbfoTeamNic, operate under the security context of the WMIPRVSE process. This process, in turn, executes under the NETWORK SERVICE account, a built-in Windows account with specific privileges.

The problem arises because, by default, the NETWORK SERVICE account lacks the necessary permissions to write trace data to the C:\Windows\inf\netcfgx.0.etl file. Consequently, when a WMI provider calls the MSFT_NetLbfoTeamNic class, and NetCfgTrace attempts to log trace information, the permission denial results in the logged kernel event ID 2. This behavior is considered a known issue and is under consideration for resolution in future versions of Windows Server. It is not indicative of a critical system failure but rather a permission conflict within the logging subsystem.

Workaround¶

If the kernel event ID 2 error, as described in the “Symptoms” section, is indeed occurring in your environment, it is generally considered harmless and can be safely ignored. The functionality of NIC Teaming and the third-party WMI provider is not directly impacted by this logging issue. However, if you prefer to suppress the error logging and prevent these events from appearing in your system logs, a workaround involving adjusting file permissions is available.

To implement this workaround, you will need to execute a series of commands from an administrative command prompt. Ensure you have elevated privileges (run as administrator) before proceeding. The commands will grant the NETWORK SERVICE account the necessary permissions to write to the C:\Windows\inf directory and the associated ETL trace files, thereby resolving the permission conflict and preventing the kernel event ID 2 from being logged in this specific scenario.

Open an administrative command prompt and execute the following commands sequentially:

Takeown /f c:\windows\inf
icacls c:\windows\inf /grant "NT AUTHORITY\NETWORK SERVICE":"(OI)(CI)(F)"
icacls c:\windows\inf\netcfgx.0.etl /grant "NT AUTHORITY\NETWORK SERVICE":F
icacls c:\windows\inf\netcfgx.1.etl /grant "NT AUTHORITY\NETWORK SERVICE":F

Let’s break down each command:

1. Takeown /f c:\windows\inf: This command takes ownership of the C:\windows\inf directory. By default, the owner might be TrustedInstaller. Taking ownership is necessary to modify permissions.
2. icacls c:\windows\inf /grant "NT AUTHORITY\NETWORK SERVICE":"(OI)(CI)(F)": This command uses the icacls utility to modify access control lists (ACLs). It grants the “NT AUTHORITY\NETWORK SERVICE” account full control (F) permissions to the C:\windows\inf directory. The (OI)(CI) flags specify that these permissions should be inherited by Object Inherit and Container Inherit, meaning new files and subdirectories created within C:\windows\inf will inherit these permissions.
3. icacls c:\windows\inf\netcfgx.0.etl /grant "NT AUTHORITY\NETWORK SERVICE":F: This command specifically grants full control (F) permissions to the NETWORK SERVICE account for the netcfgx.0.etl file.
4. icacls c:\windows\inf\netcfgx.1.etl /grant "NT AUTHORITY\NETWORK SERVICE":F: This command similarly grants full control (F) permissions to the NETWORK SERVICE account for the netcfgx.1.etl file. While the initial issue often relates to netcfgx.0.etl, granting permissions to netcfgx.1.etl as well ensures comprehensive coverage.

After executing these commands, the kernel event ID 2 related to MSFT_NetLbfoTeamNic should no longer be logged. The NETWORK SERVICE account now has the necessary permissions to write trace data to the designated ETL files.

Resetting Owner to TrustedInstaller (Optional)¶

While granting NETWORK SERVICE permissions resolves the error logging, you might want to revert the ownership of the C:\Windows\inf directory back to the default NT SERVICE\TrustedInstaller account. This is generally recommended for maintaining system security and default configurations. To reset the owner, follow these steps:

1. Open File Explorer: Navigate to C:\Windows using File Explorer.
2. Access Properties: Right-click on the INF directory and select Properties from the context menu.
3. Security Tab: In the Properties window, navigate to the Security tab.
4. Advanced Security Settings: Click the Advanced button located at the bottom of the Security tab.
5. Change Owner: In the Advanced Security Settings window, locate the Owner section at the top. Click the Change link next to the current owner.
6. Select Location: In the “Select User or Group” dialog, click the Location button. Choose the local computer name from the list. You might need to scroll up if your computer is joined to a domain.
7. Enter Object Name: In the “Enter the object name to select” field, type NT SERVICE\TrustedInstaller.
8. Check Names: Click the Check Names button. The name should resolve and appear underlined.
9. Confirm Selection: Click OK to close the “Select User or Group” dialog.
10. Apply Changes: Click OK in the Advanced Security Settings window and then OK in the INF Properties window to apply the changes.

After resetting the owner, it is prudent to verify that the NETWORK SERVICE account still retains the necessary permissions for the C:\Windows\inf directory. You can use the icacls command to check the permissions. Open an administrative command prompt and execute:

C:\>icacls c:\windows\inf

The output should include an entry similar to the following, confirming that the NETWORK SERVICE account has the inherited full control permissions:

C:\Windows\inf NT AUTHORITY\NETWORK SERVICE:(OI)(CI)(F)
[...]

This verification ensures that the workaround remains effective after resetting the directory owner. By implementing these steps, you can effectively manage the kernel event ID 2 logging issue related to MSFT_NetLbfoTeamNic in Windows Server 2012 R2 environments.

If you have any further questions or insights regarding this issue, feel free to leave a comment below. Your experiences and perspectives can be valuable to others encountering similar situations.