Invoke-Command to HyperV VM automatically ends after 10 minutes

Question

Hello, about 2 weeks ago we started to see a weird behaviour when we used Invoke-Command to perform long-running actions in HyperV VMs. After 10minutes we get this error message:

OperationStopped: The background process reported an error with the following message: "The Hyper-V socket target process has ended.".

This can be reproduced with basic commands like this one (it also happens if ConfigurationName is set to "" to use the Windows PowerShell remotely):

$session = New-PSSession -VMId $vm.Id -Credential Developer -ConfigurationName "PowerShell.7"
Invoke-Command -Session $session -Command {
    while($true) {
        Get-Date
        Start-Sleep -Seconds 10
    }
}

However, if we run the command the following way, the issue does not appear, so it really is an issue if a single Invoke-Command takes longer than 10 minutes:

while($true) {
    Invoke-Command -Session $session -ScriptBlock {
        Get-Date
        Start-Sleep -Seconds 10
    }
}

About our setup:

• We use PowerShell 7.5.3 on both, the host and in the VM, and have PSRemoting enabled
• We tried it with a few different recent Windows 11 versions of the VM but always had the same result
• The issue appears if we setup the VMs via scripts and also if they are setup manually by just using a base image downloaded from https://my.visualstudio.com/
• A few PCs do not seem to have the issue yet, so we assume that a recent Windows update on our hosts introduced this behaviour

So far, we did not find any location where this is configured. Does anyone know if this intended or a bug or where we can configure this?

Answer 1

Dear Jonas,

From what you've described, it appears that long-running Invoke-Command sessions targeting Hyper-V VMs are being terminated after approximately 10 minutes, resulting in the error:

OperationStopped: The background process reported an error with the following message: "The Hyper-V socket target process has ended."

This behavior is reproducible with persistent script blocks but not with repeated short-lived invocations, which strongly suggests a timeout or session management change affecting continuous remote execution.

Given that:

You're using PowerShell 7.5.3 on both host and guest,

The issue occurs across multiple VM setups (scripted and manual),

Some hosts still behave normally,

…it’s likely that a recent Windows update introduced a change in how Hyper-V socket sessions are managed—possibly enforcing a timeout for idle or long-running connections.

Here are Suggested next steps

1. Check for timeout policies or session limits Review any recent Group Policy or local policy changes related to remote management or PowerShell session limits. Look into WSMan settings using:
   • Code

          Get-Item -Path WSMan:\localhost\Shell
     

     and verify values like IdleTimeout and MaxIdleTimeout.
2. Test with ConfigurationName set to "" You mentioned the issue persists even when using Windows PowerShell remotely. Still, testing with ConfigurationName = "" may help isolate whether the issue is tied to PowerShell 7 endpoints.
3. Compare with unaffected hosts If possible, compare the update history and remoting configurations of the hosts that do not exhibit the issue. This may help pinpoint the change.
4. Temporary workaround As you've discovered, breaking the loop into repeated short Invoke-Command calls avoids the timeout. While not ideal, this may serve as a temporary workaround until the root cause is identified.
5. Escalate through official support channels If the issue persists and no configuration explains the behavior, we recommend opening a support case with Microsoft to investigate whether this is a regression or an intentional change.
6. Test with ConfigurationName set to "" You mentioned the issue persists even when using Windows PowerShell remotely. Still, testing with ConfigurationName = "" may help isolate whether the issue is tied to PowerShell 7 endpoints. Compare with unaffected hosts If possible, compare the update history and remoting configurations of the hosts that do not exhibit the issue. This may help pinpoint the change. Temporary workaround

     As you've discovered, breaking the loop into repeated short `Invoke-Command` calls avoids the timeout. While not ideal, this may serve as a temporary workaround until the root cause is identified.
   
     **Escalate through official support channels**
   
        If the issue persists and no configuration explains the behavior, we recommend opening a support case with Microsoft to investigate whether this is a regression or an intentional change.
   

If this guidance proves helpful, feel free to click “Accept Answer” so we know we’re heading in the right direction 😊. And of course, I’m here if you need further clarification or support. T&B, Domic Vo