none
Hyper-V Enhanced Sessions constantly crash on Win10 1709 (Fall Creators) RTM RRS feed

  • Question

  • I recently updated to Win10 1709 (Fall Creators) RTM, 10.0.16299.15, and now whenever I use Virtual Machine Connection (VMConnect.exe) and switch to Enhanced Session Mode, VMConnect crashes within about 30 seconds.  This happens with multiple guest VMs running Win10 1709 and Win10 1607.  Additional observations:
    - Using a basic session works fine, but this omits a lot of useful functionality.
    - This does not occur unless I'm actually logged into the guest VM.  If I leave the guest at the Windows logon screen even in Enhanced Session Mode, it works fine.
    - I unchecked all of the Integration Services options in the VM settings in the hopes of isolating the offending component, but this behavior persisted even with all of those options disabled.

    I even restored my system to an image captured immediately after updating to Win10 1709 in case the recently installed Win10 1709 update (KB4041994) was the culprit, but I still observed this behavior after restoring said image.
    • Edited by jphughan Sunday, October 15, 2017 6:37 AM
    Sunday, October 15, 2017 4:45 AM

Answers

  • For me, disabling printer redirection in RDP solved the crash problem. I can put up with that until a formal fix is released.
    • Marked as answer by jphughan Thursday, October 19, 2017 3:18 PM
    Thursday, October 19, 2017 1:42 PM

All replies

  • Hi,

    As Windows 10 version 1709 just released the preview version, and the offical formal version will released from Oct. 17. Please check if the issue persists after you installed the formal version.

    If the issue exists, try to check the related error in Event Viewer(Windows Logs\Applications, Setup, System) and feedback here.

    Best regards,


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, October 16, 2017 7:03 AM
    Moderator
  • I'm already running the "official formal" version downloaded directly from the Windows Update servers because Microsoft posted the ESD files there about 2 weeks ago.  I used that to build an ISO, which I then used to update from 1703 RTM to 1709 RTM.  I never ran any Insider builds.


    • Edited by jphughan Monday, October 16, 2017 2:01 PM
    Monday, October 16, 2017 1:56 PM
  • - Using a basic session works fine, but this omits a lot of useful functionality.

    I think a related scenario would be booting your VHD natively and then using Remote Desktop Connection to it.  FWIW I am using W10 CU (15063.674) as a host and have not had any problem with my VM (which is now running 17017.1000).  However, I definitely want to try to boot that VHD natively, since I anticipate being able to have a lot more "useful functionality" that way.   ; )

    C.f.
    https://answers.microsoft.com/en-us/insider/forum/insider_wintp-insider_install-insiderplat_pc/virtual-machine-win10-insider-preview-activation/c3d2dde3-8a7b-44cd-bd67-c6988e92a42c?page=2#LastReply



    Robert Aldwinckle
    ---

    Tuesday, October 17, 2017 12:50 AM
  • Hey Robert,

    I didn't have this problem either when my host was on Win10 1703 (15063), so this is definitely new for hosts running Win10 1709 (16299.15).  Thanks for the suggestion of going back to RDP, though.  I'm now amazed I hadn't thought of that myself, since you're quite right that it would deliver most or all of the functionality I require and lost as a result of updating -- assuming RDP isn't broken too, of course, which I haven't yet tested.  However, that won't be a viable workaround for everyone.  One of the advantages of VMConnect is that it doesn't require a network path to exist between the host and guest the way RDP does, so this workaround wouldn't be useful for people running VMs on Private networks rather than Internal or External networks, for example.  But I don't use those, so thanks once again for suggesting that!
    • Edited by jphughan Tuesday, October 17, 2017 1:20 AM
    Tuesday, October 17, 2017 1:18 AM
  • Hi,

    As Windows 10 version 1709 just released the preview version, and the offical formal version will released from Oct. 17. Please check if the issue persists after you installed the formal version.

    If the issue exists, try to check the related error in Event Viewer(Windows Logs\Applications, Setup, System) and feedback here.

    Best regards,


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Ok, well I checked today, and sure enough, 16299.15 is the "official formal" version.  I did download and install the Day 1 update to bring my system to 16299.19, but this issue persists even after a restart, as do the other issues I mentioned in this thread.
    Wednesday, October 18, 2017 4:19 AM
  • Hi

    I have exactly the same trouble after updating windows to version 1709 from 1703. I find if you turn  off enhanced mode then it all works well but cashes every 30 seconds with enhanced mode turned on.

    The following 2 errors appear in the event log

    Application: VmConnect.exe

    Framework Version: v4.0.30319

    Description: The process was terminated due to an unhandled exception.

    Exception Info: exception code c0000005, exception address 0000000000000000

     

    Faulting application name: VmConnect.exe, version: 10.0.16299.15, time stamp: 0xa18d7004

    Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000

    Exception code: 0xc0000005

    Fault offset: 0x0000000000000000

    Faulting process id: 0x11ec

    Faulting application start time: 0x01d347c75472d9f5

    Faulting application path: C:\WINDOWS\system32\VmConnect.exe

    Faulting module path: unknown

    Report Id: 54354a5a-b915-4fa8-b7ab-5f9bf1986dd8

    Faulting package full name:

    Wednesday, October 18, 2017 6:37 AM
  • I just updated to 1709 yesterday but don't have the enhanced mode
    crashing.
     
    So what's the common factor here, i.e., what AV and firewall software do
    you use, and try disabling them temporarily and see if it still crashes.
    Also what video adapter.  Mine's just intel...
     
     
    Wednesday, October 18, 2017 11:30 AM
  • UPDATE: Using RDP to access my VMs also produces the exact same crash behavior, which means I have no way to achieve Enhanced Session functionality with my VMs.  I'm running Win10 1607 and 1709 VMs, and both behave the same way.  For what it's worth, RDPing to an actual remote system running Windows Server 2016 (same code base as my Win10 1607 VM) does not produce this crash behavior, but obviously that doesn't help me access my VMs.

    I also disabled RemoteFX for all GPUs under Hyper-V Settings, but this did not change the behavior.

    This is completely unacceptable, Microsoft!!


    • Edited by jphughan Wednesday, October 18, 2017 3:23 PM
    Wednesday, October 18, 2017 3:21 PM
  • I just updated to 1709 yesterday but don't have the enhanced mode
    crashing.
     
    So what's the common factor here, i.e., what AV and firewall software do
    you use, and try disabling them temporarily and see if it still crashes.
    Also what video adapter.  Mine's just intel...
     
     

    I'm just using Windows Defender in its default configuration and Windows Firewall with minimal customizations (though this wouldn't affect VMConnect) -- no third-party security software.  I'm on a Dell XPS 15 9530 that's running an Intel HD Graphics 4600 adapter.  It also has a GeForce GPU as a render-only device, but that doesn't come into play in regular Windows and is listed as not supported for RemoteFX, so I doubt that's a factor.  The Intel graphics drivers are admittedly old because the current version available on Windows Update when used on a system that has this particular GPU and Hyper-V installed creates 4 "fake" displays in Display Settings and wreaks all kinds of other havoc.  There's a long-running thread about this issue on Intel Communities, and Intel says they have it fixed in an internal build, but they still haven't released it months later.  But if it were a host GPU issue I'd expect VMConnect and RDP to fail consistently, not just when connecting to VMs (in the latter case).  This feels like some sort of bug on the Hyper-V host side with integration services for guest VMs.

    But what OSes are your VMs running where Enhanced Session mode works?

    (UPDATE: I created a brand new VM from a "Win8.1 with Nov 2014 Update" ISO and it exhibits the exact same behavior.)
    • Edited by jphughan Wednesday, October 18, 2017 5:11 PM
    Wednesday, October 18, 2017 4:24 PM
  • I have Intel 520 in a lenovo thinkpad X1 Yoga.
     
    I'm using AVG for AV, so that's different too. I know Microsoft tests
    defender, but just for grins, can you try excluding the VM's files folders
    for defender?   Also are you using bitlocker?  I'm not.
     
    I've used just Windows 10 Ent so far.  Is there something you want me to
    test in particular?
     
    fwiw, enhanced sessions isn't exactly like RDP, I believe it uses the VMBUS
    rather than normal RDP TCP.
     
    Wednesday, October 18, 2017 5:19 PM
  • I'll test adding an exclusion for Windows Defender, although I'm not optimistic.  I am indeed using BitLocker on both my OS volume and the Data partition where my VMs reside, but I can't imagine why that would affect only Enhanced Session Mode and I'm not willing to turn that off for testing, since that wouldn't be an acceptable workaround for me anyway, even temporarily.

    For the guest OS version, I was just trying to see how many OSes were affected.  So far I've unsuccessfully tested Win8.1, Win10 1607, and Win10 1709, so I'm going to bet that Win8.0 and Win10 1507, 1511, and 1703 are also affected, along with the corresponding Server versions of each.

    You're certainly right that VMConnect uses VMBus, whereas RDP uses TCP and therefore requires a network path to exist between the host and guest (which isn't always the case, e.g. Private virtual networks), but I believe the additional functionality enabled by VMConnect's Enhanced Session mode uses the same DLLs, APIs, etc as RDP does, e.g. unified clipboard, local drive mapping, multi-display session, etc.

    I do admit the failure pattern is odd, though.  If it was just a bug on the host in some DLL common to VMConnect and RDP, I wouldn't have expected RDP to work when connecting to a remote Windows Server 2016 host I tried -- but it does.  On the other hand, if it's a bug in VMBus, connecting to my VMs via RDP should work -- but it doesn't.  And the VMs themselves aren't crashing at all, just the VMConnect/RDP session on the host.

    So this is a bug that affects both VMConnect (Enhanced Session only) and RDP sessions established from a Win10 1709 Hyper-V host to guest VMs on that box (multiple OSes) but does not affect RDP to remote systems.  Very strange....


    • Edited by jphughan Wednesday, October 18, 2017 5:43 PM
    Wednesday, October 18, 2017 5:37 PM
  • >So this is a bug that affects both VMConnect (Enhanced Session only) and RDP sessions established from a Win10 1709 Hyper-V host to guest VMs on that box (multiple OSes) but does not affect RDP to remote systems.  Very strange....
     
    Yep, strange! It's not a general problem since I don't see any crashing.
    It's got to be hardware or software dependent.
     
    Maybe try booting to VGA mode?
     
    Wednesday, October 18, 2017 5:54 PM
  • >So this is a bug that affects both VMConnect (Enhanced Session only) and RDP sessions established from a Win10 1709 Hyper-V host to guest VMs on that box (multiple OSes) but does not affect RDP to remote systems.  Very strange....
     
    Yep, strange! It's not a general problem since I don't see any crashing.
    It's got to be hardware or software dependent.
     
    Maybe try booting to VGA mode?
     
    Sort of like I said with BitLocker above, even if VGA mode works, I don't consider that an acceptable workaround even temporarily, so I'm not really willing to spend time pursuing workarounds that I wouldn't be able to put up with.  At this point if the "quality update" that will presumably be released this coming Tuesday (4th of the month) doesn't resolve this, I may just end up restoring to the image I captured immediately before updating to 1709.  I do like to stay ahead of the curve as someone who works in IT both professionally and for family and friends, but 1709 doesn't really have anything I need, so if it's going to take away things I actually DO need, maybe I'll just come back later after it's stabilized.  Sigh....
    Wednesday, October 18, 2017 8:54 PM
  • I don't really see why booting to VGA temporarily (one time!) to isolate
    your problem is so onerous, but whatever, a restore is your best bet.
     
    Wednesday, October 18, 2017 9:08 PM
  •   @Bob

        Did you see this post in the networking forum. Looks like there is a general problem with RDP in version 1709.

    https://social.technet.microsoft.com/Forums/windows/en-US/8b0debe5-ba1e-4e4e-a054-6e8dc0bc2aa3/remote-desktop-connection-fails-after-fall-creators-update-installed?forum=win10itpronetworking


    Bill

    Wednesday, October 18, 2017 10:05 PM
  • No, I didn't, but it doesn't surprise me all that much, there does seem
    to be some kind of problem. 
     
    It works fine here though, both RDP and enhanced session, no crashes at
    all and I use both daily.  There was an earlier build that I had problems
    with RDP, but it's been awhile, and that wasn't a release build.
     
     
    Thursday, October 19, 2017 1:05 AM
  • For me, disabling printer redirection in RDP solved the crash problem. I can put up with that until a formal fix is released.
    • Marked as answer by jphughan Thursday, October 19, 2017 3:18 PM
    Thursday, October 19, 2017 1:42 PM
  • Interesting, thanks for posting that!
     
    I don't use printer redirection, so that could be why I never saw the
    problem.
     
     
    Thursday, October 19, 2017 2:21 PM
  • For me, disabling printer redirection in RDP solved the crash problem. I can put up with that until a formal fix is released.

    Confirmed.  This will have to do for now.  Thanks again for posting here and in the other thread!
    Thursday, October 19, 2017 3:18 PM
  • Interesting, thanks for posting that!
     
    I don't use printer redirection, so that could be why I never saw the
    problem.
     
     

    And for the Server 2016 box I tested with, I was using a saved RDP profile that had printer redirection disabled, which is why that worked for me.  Sigh....
    Thursday, October 19, 2017 7:04 PM
  • Confirmed disabling printer redirection results in a stable session
    Friday, October 20, 2017 1:36 AM
  • I don't use printer redirection, so that could be why I never saw the problem.
    In my case, I once did but during an early preview I couldn't get an install done until I had removed all printing support, so now I don't have any possibility of seeing that problem.   ; )


    Robert Aldwinckle
    ---

    Friday, October 20, 2017 12:18 PM
  • Seems there's a bug in Hyper-V on 1709...found this thread after multiple crashes past couple weeks w/different guest OSes but after turning off enhanced session mode, all is working (w/o enhanced features of course).  Will have to leave it off until there's a fix...has anyone opened a bug report yet?
    Friday, November 3, 2017 9:08 PM
  • I also found that disabling printer redirection in RDP solved the crash problem.

    Interesting that the one other consistent problem I've had since the Fall Creators update is a crash of the Print driver host for applications after boot on the Hyper-V host:

    Faulting application name: splwow64.exe, version: 10.0.16299.15, time stamp: 0x7403b6eb
    Faulting module name: ntdll.dll, version: 10.0.16299.64, time stamp: 0x493793ea
    Exception code: 0xc0000409
    Fault offset: 0x0000000000090d5f
    Faulting process id: 0x29b8
    Faulting application start time: 0x01d35e25bbc66616
    Faulting application path: C:\WINDOWS\splwow64.exe
    Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
    Report Id: c92dd424-274e-48db-8942-db1974c7b22c
    Faulting package full name:
    Faulting package-relative application ID:

    Wednesday, November 15, 2017 5:33 PM
  • Hi all,

    I had a problem accessing a Synology NAS from a Win10 client with HyperV installed.

    There was no issue before 1709 but immediately on rebooting after the 1709 update the access to the NAS via explorer and als WEB interface (!!!) was broken. I could open some directories but after several seconds explorer froze and did not respond any more.

    Web Interface access did not work from any browser, it showed an empty window forever without any error message. I found a huge number of TCP out of order / retransmission / duplicates with wireshark.

    There where no errors in system log.

    After removing HyperV erverthing is working again, the fault is comming back when reinstalling HyperV

    Max

    Sunday, November 26, 2017 7:11 PM
  • That's very strange, it almost looks like a DNS problem and a TCP
    windowing problem.  fwiw, I run 1709 with Hyper-V and don't see the same
    problem.
     
    I bet it's your NIC driver that's having a problem with hyper-V.  Do you
    have more than 1 NIC?
     
     
     
    Sunday, November 26, 2017 8:46 PM
  • https://support.microsoft.com/en-us/help/4051963

    There is no indication that this has the fix for the rdp bug, but..... it was supposed to be in this release.  Please test and report back please?

    • Proposed as answer by Robearo Friday, December 1, 2017 5:33 AM
    Thursday, November 30, 2017 7:06 PM
  • Hi

    I downloaded and applied the file which brought my windows 10 to version 16288.98 abd it appears to have fixed my issue reported earlier in this article.

    Thank you for the advice

    Thursday, November 30, 2017 7:41 PM
  • It doesn't fix my vmconnect display problems, but that may be unique to my
    laptop.  (Lenovo X1 Yoga 1st gen.)
     
     
    Thursday, November 30, 2017 9:05 PM
  • Installed patch KB4051963 (OS Build 16299.98) noted above on Hyper-V server and appears to resolve the problem with unpatched Window 10 virtual machine. Will apply patch to VM and continue testing.

    Also booted without getting splwow64.exe crash as well.

    https://support.microsoft.com/en-us/help/4051963


    • Edited by Robearo Friday, December 1, 2017 6:12 AM
    Friday, December 1, 2017 5:36 AM
  • Thanks

    Sunday, December 3, 2017 1:15 PM