Home HOW-TO How to troubleshoot Event ID 15 from Source Hyper-V-VmSwitch. Failed to restore configuration for port XXX on switch XXX. Object Name not found

How to troubleshoot Event ID 15 from Source Hyper-V-VmSwitch. Failed to restore configuration for port XXX on switch XXX. Object Name not found

by Cengiz Kuskaya

Problem Description

After restarting a Hyper-V Server, Hyper-V Failover Cluster or Windows 10 with Hyper-V installed, Event ID 15 from Source Hyper-V-VmSwitch with the Error Message “Failed to restore configuration for port XXX on switch XXX. Object Name not found” can be logged.

We have made a detailed Root Cause Analysis. Our findings and solution are as follows.

Event Log

Log Name:      System
Source:        Microsoft-Windows-Hyper-V-VmSwitch
Date:          4/17/2020 1:33:19 AM
Event ID:      15
Task Category: (1010)
Level:         Error
Keywords:      (128)
User:          SYSTEM
Computer:      ServerName
Description:
Failed to restore configuration for port F913CE96-201D-4BF1-B5C1-E14FC49AAA1F (Friendly Name: ) on switch B7D41CA8-25B7-4DE6-8C70-809FD8E74B8E (Friendly Name: ), status = Object Name not found..

Root Cause Analysis

Once the problematic Hyper-V Server has been restarted following Event Logs from Source Hyper-V-VmSwitch gets logged. The following sequence of Information Event applies to an Hyper-V Server where the VM’s were shutdown and the Hyper-V Virtual Switch was connected to a Private Network.

1. Event ID 233 ..Create..
2. Event ID 232 ..Connected..
3. Event ID 9   ..Initialized..

Note !
If the port connection fails on the Hyper-V Virtual Switch (Private Network), Event ID 15 gets logged after Event ID 9. If you start the VM, additional Information Events are logged.

4. Event ID 232 ..Connected to Port..
5. Event ID 102 ..Networking Driver loaded..

1. “Hyper-V Virtual Switches” which are connected to a “Private Network”
Hyper-V Virtual Switches” which are connected to a “Private Network” have Dynamic Ports. This means, if you start a VM, the Port gets created in the Registry under the “Switch ID” and once you shutdown the VM, the Port ID’s gets deleted automatically. This applies to “Private Networksonly. In the screenshot mentioned below you can see a “Hyper-V Virtual Switch” which is connected to a “Private Network” and has created a successful port. Once you click on the “Switch ID” you will see, if the Switch is connected to a “Private” or “External” Network.

Example :
Switch ID : 834E5299-2791-460B-AD6D-D0AE27AF6236 (Static Entry)
Port ID : B8AE5677-47AC-4CD9-8339-2C358FA35EE7 (Dynamic Entry)

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vmsmp\parameters\SwitchList\834E5299-2791-460B-AD6D-D0AE27AF6236\B8AE5677-47AC-4CD9-8339-2C358FA35EE7

2. “Hyper-V Virtual Switches” which are connected to an “Internal or External Network”
Hyper-V Virtual Switches” which are connected to an”Internal or External Networks” have Static Ports. This means if you shutdown a VM the Port doesn’t get deleted. Furthermore, below two screenshots for an example of a corrupt and successful port.

Below a corrupt Port. It doesn’t have any kind of Information. Exactly these Port ID’s are causing Event ID 15.

This is a properly working Port. It should looks like this. It has the Hyper-V Virtual Switch name in it.

3. Why Hyper-V is logging Event ID 15 ?

This problem occurs if you import a VM on the Hyper-V Server. In our case the VM was exported from another Hyper-V Server. After the import operation VMMS.exe (Virtual Machine Management Service) created lots of orphaned port entries which caused later on Event ID 15 in System Event Log. We run Procmon from Sysinternals during the import operation and figured out that the Registry Keys are created by VMMS.exe. Basically this misbehaviour looks like a BUG.

Below the Registry Keys Before and After importing a VM on the target Hyper-V Server. VMMS.exe created lots of orphaned entries under the Hyper-V Virtual Switches, connected to a Private and External Network. You should check all of your Switches. Therefore I would recommend to take a Screenshot of the Registry before and after importing a VM so you can see which orphaned entries has been created.

“Before” importing the VM.

“After” importing the VM.

Solution

The solution is basically to delete the Port ID’s which are empty and which doesn’t have the Hyper-V Virtual Switch Name in it. Another approach would be to filter the System Event Logs based on Event ID 15, copy and search for these Port ID’s inside the Registry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vmsmp\parameters\SwitchList. Please kindly read the “Root Cause Analysis” part of the article before deleting the orphaned Port ID’s.

Basically right click on the orphaned “Port ID” and delete it. As a precaution you can backup the Registry \SwitchList (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vmsmp\parameters\SwitchList) as *.REG and *.HIV so you can import it back in any unexpected situation.

We have deleted the orphaned port entries on two Production Hyper-V Servers, restarted the Hyper-V Servers and checked also the VM’s to be sure that eveything is working fine. No problems. Event ID 15 doesn’t get logged anymore.

Keywords

Windows Server 2016, Windows Server 2019, Windows 10, Hyper-V, Failover Clustering, Hyper-V-VmSwitch, Event ID 15.

Good luck !