When a Remote Desktop server hangs like this, there are a few key system services you can target. However, because the underlying issue is tied to the Hyper-V integration components and the network stack, a standard remote connection through services.msc from your desktop might timeout if the VM is completely isolated from the network.

If you can still establish a connection via services.msc (by pointing it to the remote machine's name/IP) or if you use Hyper-V's PowerShell Direct (which bypasses the network entirely and talks to the VM via the hypervisor bus), these are the services to target to try and unblock RDP without a hard reset.

1. Remote Desktop Services (TermService)

This is the core engine handling RDP sessions. When an RDP server bugs out due to packet queue issues, the listener thread often freezes.

• What to do: Try to Restart it.


• The Catch: If it's completely deadlocked, services.msc might get stuck on "Waiting for service to respond." If that happens, you have to kill its process wrapper (svchost.exe) via command line.

2. Hyper-V PowerShell Direct (The Ultimate Bypass)

If services.msc won't connect because the VM has no IP address, you can use PowerShell Direct. This lets you run commands inside the guest OS directly from the physical Hyper-V host (REP1), completely bypassing the network card, vSwitch, and firewalls.

Run this on your Hyper-V Host to forcefully bounce the RDP services inside the VM:

Invoke-Command -VMName "Gemini-G2-Rep" -ScriptBlock { 
    # Forcefully stop the RDP service and its graphics redirection 
    Stop-Service -Name "TermService" -Force 
     
    # Restart the remote desktop configuration service 
    Start-Service -Name "SessionEnv" 
    Start-Service -Name "TermService" 
}

3. The Network Location Awareness (NLA) Service

Because your error is explicitly tied to the network adapter dropping its IP context (Vport QueuePairs mismatch), the Network Location Awareness (NlaSvc) service inside the VM often thinks it has transitioned to an unidentified network or lost its gateway. This causes Windows Firewall to abruptly block incoming RDP traffic.

Restarting NLA forces the guest OS to re-evaluate its IP status and flush its routing tables.

Inside the VM (via PowerShell Direct or a local console), run:

Invoke-Command -VMName "Gemini-G2-Rep" -ScriptBlock { 
    Restart-Service -Name "NlaSvc" -Force 
}

Summary of Services to Target

If you are looking at services.msc or a script, target these four in this exact order:

What if it says "Control Transmit Status Pending"?

If you try to restart them and the status changes to "Stopping" and sits there indefinitely, it confirms the OS kernel is locked up waiting on the Hyper-V network driver. At that stage, services cannot self-terminate, and you will need to fall back on dropping the worker process (vmwp.exe) from the host as outlined previously.

This confirms the deadlock. When TermService gets stuck in a "Stopping" state, it means the Remote Desktop service is trying to tear down its active user sessions, but the underlying network threads are completely blocked by the Hyper-V virtual switch queue failure.

Because it is stuck in kernel-space waiting on a network interrupt that will never come, services.msc cannot force it closed. You have to kill its hosting process (svchost.exe) from the inside, or pull the plug from the host.

Here are your options to break the deadlock right now, ordered from least disruptive to a hard reboot.

Option 1: Force-Kill the TermService Process inside the VM (Via Host)

You can use PowerShell Direct from the physical Hyper-V host (REP1) to forcibly terminate the exact svchost.exe instance that is holding TermService hostage. This avoids restarting the whole VM.

Run this on the Hyper-V Host:

Invoke-Command -VMName "Gemini-G2-Rep" -ScriptBlock { 
    # Find the Process ID (PID) hosting TermService 
    $RdpPID = (Get-CimInstance -ClassName Win32_Service -Filter "Name='TermService'").ProcessId 
     
    # Forcefully terminate that process ID 
    Stop-Process -Id $RdpPID -Force 
}

Once this runs, the service will crash out of the "Stopping" loop. You can then immediately run Start-Service -Name "TermService" within the same block to revive RDP.

Option 2: Force-Kill via Network Command Line

If you happen to have a working command line connection to the VM from your local desktop (even if services.msc is hanging), you can issue a remote taskkill targeting the service name:

taskkill /S Gemini-G2-Rep /F /FI "SERVICES eq TermService" 

Option 3: If the VM is Completely Non-Responsive

If Option 1 or 2 throws a timeout error, the guest OS kernel has completely panicked. Don't waste time waiting for it to time out; go straight to the Hyper-V host layer and drop the VM worker process to force a hard reset.

Run this on the Hyper-V Host:

$VMGuid = (Get-VM -Name "Gemini-G2-Rep").Id 
$VMProcess = Get-CimInstance -ClassName Win32_Process -Filter "Name='vmwp.exe'" | Where-Object {$_.CommandLine -match $VMGuid} 
Stop-Process -Id $VMProcess.ProcessId -Force 

Crucial Next Step Before Booting

Once you get it stopped or restarted, disable VMQ on this VM immediately so it doesn't instantly deadlock again on the next user connection:

Set-VMNetworkAdapter -VMName "Gemini-G2-Rep" -VmqWeight 0 

If you successfully restart or force-kill TermService, every single active and disconnected remote user session will be instantly dropped. Here is exactly how it impacts the users and their data depending on how the service comes back down:

1. The Direct Impact on Users

• Immediate Disconnection: The moment the process dies, the RDP protocol listener drops. Every user will see their RDP client freeze for a few seconds before throwing a "Your Remote Desktop Services session has ended" or "Lost connection" error.


• Session State (Graceful vs. Crash): * If the service manages to cycle gracefully (unlikely in your current frozen state), the user sessions are technically preserved in memory, and users can reconnect once it's up.


• If you have to force-kill the service (via taskkill or killing the PID), the entire svchost.exe instance hosting those sessions is destroyed. This is the equivalent of pulling the power cord on their virtual desktops.

2. What Happens to Their Unsaved Work?

Because the guest OS kernel itself hasn't rebooted, the application processes (like Excel, Outlook, or accounting software) running under the users' session IDs will generally remain running in the background memory for a short period, even if the main RDP container crashes.

• When they reconnect: Once TermService restarts cleanly, users logging back in should be re-attached to their existing session profiles, and their open applications and unsaved work should still be sitting right there.


• The Exception: If the server was so badly deadlocked that the user profile service (ProfSvc) or the graphics subsystem also crashed during the network queue failure, Windows might fail to re-associate them with their old sessions on reconnect, forcing it to generate fresh, blank sessions instead.

The Verdict: Do it anyway?

Given that your server is currently completely non-responsive, refusing to hand out IP addresses, and blocking all incoming connections anyway, your users are already effectively locked out and unable to work. Bouncing the service (or pulling the plug on the VM worker process if TermService stays stuck in "Stopping") is your only viable path to restoring service. The potential risk of a user losing an unsaved document is heavily outweighed by the fact that the server is currently a brick.

It is an incredibly valid-and deeply frustrating-question. You are looking at a core architecture that debuted in 1993 with Windows NT 3.1, and 33 years later, a service freeze can still bring a multi-gigabit enterprise hypervisor to its knees.

The paradox of why it hasn't gotten better actually comes down to a fundamental shift in how operating systems are designed, combined with the impossible math of modern hardware coordination.

1. The Death of the Clean Kill (Kernel vs. User Space)

In the days of NT 3.51 or NT 4.0, if a service hung, you could almost always kill it because services were relatively self-contained units.

Today, to wring maximum performance out of hardware, Microsoft has moved massive amounts of plumbing out of "User Space" (where apps live) and directly into "Kernel Space" (the untouchable foundation of the OS).

• The TermService Trap: The Remote Desktop service isn't just a basic text listener anymore; it is tightly coupled with the graphics driver, the user profile subsystem, encryption layers, and-crucially-the virtual network stack.


• The "Unkillable" State: When a service status says "Stopping" and hangs indefinitely, it means the user-space process has asked the kernel, "Please close my network threads." But if the Hyper-V virtual switch kernel driver is stuck waiting for a hardware response from a physical NIC queue that errored out, the kernel puts that thread into an uninterruptible sleep state. Windows refuses to kill it because doing so would corrupt the entire operating system's memory pool, resulting in an immediate Blue Screen of Death (BSOD). So, it sits there frozen to "protect" the host.

2. Over-Engineering for the 0.1% (The Feature Mismatch)

Thirty years ago, a network card sent a packet, the CPU processed it, and that was it. Today, Microsoft tries to make Windows Server accommodate massive data centers automatically without manual tuning.

Features like VMMQ (Virtual Machine Multi-Queue) and Dynamic Switch Utilization Plans were engineered for massive Azure environments running thousands of virtual machines across 100Gbps fabric.

• By default, the modern Hyper-V switch aggressively tries to optimize traffic by demanding 16 separate hardware queue pairs per virtual port from your physical NIC, shifting them dynamically from CPU core to CPU core as RDP user traffic bursts.


• The problem is that real-world hardware drivers (from Intel, Broadcom, HPE, etc.) often can't handle that dynamic reshuffling cleanly, or they cap out at 4 or 8 queues. When the hardware driver fails to respond to an internal Windows request (an OID request) in a timely fashion, the whole virtual switch stack drops its tools and locks up.

3. The Layering of "Technical Debt"

Instead of rewriting the core infrastructure from scratch, modern Windows Server is essentially an incredibly sophisticated skyscraper built on top of that original NT foundation.

When you run an RDP server on Hyper-V, you aren't just running a machine. You are running:

1. The physical hardware driver.


2. The Switch Embedded Teaming (SET) layer.


3. The Hyper-V Virtual Switch.


4. The Virtual Machine Worker Process (vmwp.exe).


5. The Guest OS Network Driver.


6. The Windows RPC/Firewall Subsystem.


7. The Remote Desktop Engine (TermService).

If a glitch occurs at Layer 1 (the physical NIC queue mismatch), the error ripples all the way up to Layer 7. Because every layer expects the one below it to work perfectly, a failure at the bottom causes a cascade of dependencies where TermService gets left holding the bag, unable to close down because its foundational plumbing has vanished underneath it.

The Silver Lining

The only reason we can bypass this today without walking over to the physical rack and pulling the power cord is Hyper-V PowerShell Direct. By creating an internal VMBus (a direct software pipeline through the motherboard's RAM that completely bypasses the network card), we can at least get a surgical scalpel into the VM to drop the process-something administrators 30 years ago could only dream of while staring at a completely frozen screen.

To put that into a human-readable perspective, 56,894,672 seconds is approximately 658 days-or just over 1 year and 9 months.

In the world of Linux or Unix enterprise mainframes, a uptime of nearly two years is often worn like a badge of honor. But for a Windows Server Hyper-V host, that is an incredibly long time to go without a reboot, and it is almost certainly contributing to the structural instability you are experiencing with your virtual switch and RDP deadlocks.

Here is why that number is a major red flag for this specific environment:

1. You Are Missing Vital Kernel Patches

Because Windows updates require a full system reboot to replace core operating system files, a host that has been up for 658 days hasn't had its underlying kernel, hypervisor stack, or virtual switch binaries updated since mid-2024.

Over the last nearly two years, Microsoft has released dozens of critical patches fixing memory leaks, race conditions, and handling flaws explicitly tied to Hyper-V Switch Embedded Teaming (SET) and physical network driver interactions. You are running on an old, unpatched version of the network gearbox.

2. Driver Memory Fragmentation & Paged Pool Leaks

Even if an OS is stable, third-party hardware drivers (like those handling your physical NICs, storage controllers, and motherboard chipsets) slowly leak microscopic amounts of system memory over time.

After 658 days of constantly allocating and tearing down virtual network ports (Vports) for your VMs, the host's system memory pool becomes heavily fragmented. The network driver eventually struggles to find contiguous blocks of memory to assign new hardware queue pairs, making it drastically more likely to drop interrupts and hang worker processes (vmwp.exe).

3. The "Unresolved State" Risk

The longer a Windows machine stays running, the more likely it is that an internal service or driver has encountered a non-fatal error and is running in a compromised, unstable state. The Vport QueuePairs warnings you hit earlier are a classic symptom of a host's networking stack that has slowly degraded to the point where it can no longer orchestrate complex hardware features cleanly.

What You Should Do Next

While fixing the VmqWeight and capping the QueuePairs via PowerShell will give you immediate relief to get those RDP servers stable today, the host itself is screaming for maintenance.

Once you have a weekend or a low-impact maintenance window:

1. Evacuate the VMs: Live Migrate or cleanly shut down all virtual machines on REP1.


2. Apply cumulative updates: Run Windows Update on the physical host to clear the massive backlog of kernel and hypervisor patches.


3. Firmware updates: Since you'll already be taking the host down, take 10 minutes to update the physical network card's driver and firmware (NVM) to the latest vendor releases.


4. Reboot the Host: Flush that 658-day-old memory space and let the server start fresh.

Bouncing the host will clear out the structural cobwebs that no amount of service restarting or command-line trickery can fix.

To permanently fix the Vport QueuePairs error mismatch and stop the Hyper-V Virtual Switch from over-allocating hardware resources, you need to run a command on the physical Hyper-V host machine (REP1).

This limits the default number of Multi-Queue pairs the virtual switch requests to a stable number that your physical network card can actually handle.

Step 1: Open PowerShell as Administrator on the Host

1. Log into your physical host server (REP1).


2. Right-click the Start button and select PowerShell (Admin) or Terminal (Admin).

Step 2: Find Your Virtual Switch Name

If you don't know the exact name of your virtual switch, run this quick query first:

Get-VMSwitch | Select-Object Name 

Step 3: Run the Fix Command

Run the following command, replacing "YOUR_SWITCH_NAME" with the actual name you found in Step 2 (keep the quotation marks):

Set-VMSwitch -Name "YOUR_SWITCH_NAME" -DefaultQueueVmmqQueuePairs 4 

Why 4?

Modern Windows Server environments default to requesting 16 queue pairs per virtual port. Capping this value to 4 keeps it well within the threshold of standard hardware drivers (especially within Switch Embedded Teaming layouts) without sacrificing throughput for your RDP servers.

Once you execute this, the virtual switch will stop trying to force an over-engineered utilization plan on your NIC driver, clearing the event log warnings and stopping the associated kernel deadlocks.

Disabling the team and stripping it down to a single, bare 10Gb network card is actually the best diagnostic move you could have made. Teaming layers (especially Windows SET teams) multiply the complexity of queue allocations, so dropping back to a single interface lets you isolate exactly what is happening.

Since you are running a single 10Gb interface, the command to apply the fix to your Virtual Switch remains exactly the same.

Run this on the Hyper-V Host PowerShell (Admin) to align the switch with the single card:

Set-VMSwitch -Name "YOUR_SWITCH_NAME" -DefaultQueueVmmqQueuePairs 4 

(Remember to replace "YOUR_SWITCH_NAME" with the name of your virtual switch).

Why this is still crucial on a single 10Gb card

Even without a team, a standard 10Gb NIC driver (like an Intel X710 or Broadcom NetXtreme) typically exposes a fixed maximum number of hardware queues to the OS.

If Hyper-V is still running its default configuration, it will look at that single 10Gb pipeline, get overly ambitious, and try to carve out 16 QueuePairs for your RDP virtual machine's port. The single card's driver will reject or choke on that massive, dynamic request under heavy load, causing the exact same virtual switch lockup you've been fighting.

The Winning Combo

Now that you are on a single card, combining the command above with the VMQ disable command you just ran on the VM (-VmqWeight 0) completely stabilizes the path:

1. -VmqWeight 0 tells the host: "Stop trying to allocate dedicated hardware queues directly to the RDP virtual machine."


2. -DefaultQueueVmmqQueuePairs 4 tells the Virtual Switch: "When you manage the default host traffic, keep your hands on the wheel and don't ask the 10Gb driver for more than 4 queues."

This strips away the over-engineered British Leyland design entirely, forcing the host to handle the 10Gb traffic using a stable, predictable queue layout that won't lock up your RDP sessions.