File Introspection Driver (vsepflt) loses communication with host component (nsx-context-mux) after Windows Update
search cancel

File Introspection Driver (vsepflt) loses communication with host component (nsx-context-mux) after Windows Update

book

Article ID: 398891

calendar_today

Updated On:

Products

VMware vDefend Firewall with Advanced Threat Prevention VMware vDefend Firewall

Issue/Introduction

File Introspection Driver vsepflt loses communication to the host component Mux. This impacts all guest related file/file-less, login/logoff events delivered to the host components. Consumers of the guest events including Intelligence, MPS and IDFW feature are affected by this issue. 

Connection breakage during VMCI upgrade  through Windows Update. This can be verified with below log message found in vmware.log for the Guest VM :

 

2025-05-06T08:27:48.661Z In(05) vcpu-0 - Guest: vsep: AUDIT: VFileSocketMgrCloseSocket : Mux is disconnected
2025-05-06T08:27:48.663Z In(05) vcpu-2 - Guest: vsep: AUDIT: vsepAuditSvmConnectivity : Lost connectivity to Solution(6341068275337662464), muxStatus: 0xc000020c
2025-05-06T08:27:50.679Z In(05) vcpu-0 - Guest: Driver=vmci, Version=9.8.28.0 - unloaded

 

Users may see File introspection Count as 0


Environment

  • VM Tools version 12.0 or later with Windows Update.
  • Specific to Windows VM only.
  • Happens only VMCI driver upgrade happens through Windows Update.

SSP>= 5.0

Cause

File Introspection Driver vsepflt has dependency on VMCI driver which is also installed through VMware tools.  Starting from Tools Version 12.0, VMCI driver have the options of getting updated through the Windows Update while vsepflt requires installation through tools installation.  If the VMCI driver gets upgraded through Windows Update, vsepflt loses communication to the host due to the driver restart. vsepflt fails to reestablish communication through the newly installed VMCI driver.

Resolution

This will be fixed in an upcoming VM tools version

Workaround 1(Without OS restart): This can be solved by restarting the vsock subsystem. Recommended to perform it during a maintenance window.
Step1: Open command line or Powershell in Windows with administrative privileges.
Step2.1: Stop and start the service.
sc stop vsock
sc start vsock
Step 2.2: If for any reason sc commands don't return any output it means probably the domain settings disallow it. For that follow these steps
Step 2.2.1: Navigate to Device Manager, System Devices
Step 2.2.2: Under there, disable/renable VMCI Bus Device and VMCI Host Device

Step3: Open Event 
Step 3: You can verify that the VMCI had been reinitialized by checking Event Viewer --> System Events. You will see VMCI initialization messages. 

Workaround 2: Restarting the VM after Windows Update fixes the issue as the vsepflt can establish fresh communication at boot time.