none
Server 2016 VM Hangs shutting down/restarting when the Pagefile is on a different VHDX.

    Question

  • Howdy,

    We are working on creating some VMs running 2016 for testing.  Our normal setup for our 2012 R2 machines is a C drive (OS), D Drive (Data), and P Drive (Pagefile).  This has never caused us any issues.  When I set this same thing up on our Server 2016 VMs we run into problems where the VM wont' shut down or restart once we move the Pagefile to P.

    To do so I set C & D to No Pagefile and P to System Managed.  The first reboot usually works OK but after that when we try to restart or shutdown we just get to a plain blue background with the words "Shutting down" or "Restarting" and it never moved.  I tried restarting one last Thursday and was off Friday.  I checked it this morning and it still said Restarting...

    There is no crash or error or anything and I just have to power it off through the Hyper-V itself.  The VMs always boot back up OK and Event Viewer doesn't show anything except all the various things entered the Stopped State just before the hang.

    As soon as I put the Pagefile back on C all the problems fo away and I can shut down and restart all I want with no issues.

    Anyone run into this by change or have any ideas what the problem might be?

    Monday, November 21, 2016 6:12 PM

All replies

  • Are the C: and P: vhdx files on the same or different physical disks?

    With a properly sized VM, there should be no worry about trying to place the page file for improved performance.  The operating system still needs a page file to operate smoothly, but if you have memory sized correctly, you should be able to get by with a relatively small (4GB) page file for nearly any system.  And it will hardly add any IOPS to the environment.

    Page files are a bit of a hang over from the days of really expensive memory on small memory systems.  So people tended to make use of the page file to offset the cost of memory.  Today, memory is a very inexpensive way to increase the capacity/performance of many applications.  As a result, very rarely do I ever have a page file greater than 4GB, and even then, it is almost not used.


    . : | : . : | : . tim

    Monday, November 21, 2016 7:50 PM
  • We use a flash storage array so who knows where the actual file are but the C and P drives are in the same folder (CSV) separate from the D drive.  We use to have C, D< and P all in separated volumes but now we have C and P together which has worked fine with 2012 R2.  We generally set the P drive to be 20 gigs in size and just let Windows manage it itself.
    Monday, November 21, 2016 8:16 PM
  • I know it's not addressing your question about why you started having issues, but I would re-evaluate the reason for having a separate page file drive. My personal opinion is that it is completely unneeded in almost every case and just creates another thing to manage.

    I have never built a VM with a separate page file drive, so I'll have to build a clustered environment to try to test out what you are seeing.


    . : | : . : | : . tim

    Monday, November 21, 2016 8:53 PM
  • Morning all,

    I'm seeing this issue as well. Exactly the same but I use the D:\ as the page file to mirror how Azure does it so that when we want to move to/from and or have VMs created natively in Azure it makes understanding the drive letter locations and such a little easier.

    Also as for the main reason for having the page file on a separate VHDX (@Tim), personally I'm doing this for DR replication so I can exclude the pagefile disk from the replication model and save on replication traffic/bandwidth. I do exactly the same thing for the SQL database TempDB files.

    But yes - can we get a response from MS on this issue please? It is easily reproducible.

    Kind Regards

    Joe.

    Friday, December 02, 2016 8:08 AM
  • Seeing this exact same issue on my VMs with separate drives for the pagefile. To tim (and others with a similar mindset): Telling us to just switch it to C:\ is not an answer. There are very legitimate reasons for putting the pagefile off the system drive. Please don't assume out only reason is performance, In our case, it is to reduce unnecessary churn of data during Hyper-V replication. This has worked fine in other virtualized Windows operating systems. Only 2016 has this issue and Microsoft needs to fix it.

    Edit: FYI, this is not fixed as of the November update.

    • Edited by OTD Razor Tuesday, December 06, 2016 10:54 PM
    Tuesday, December 06, 2016 10:53 PM
  • "Telling us to just switch it to C:\ is not an answer"

    I did not tell anyone to 'just switch it to C:'.  I explicitly stated my response was not addressing the question, and then suggested re-evaluating the reason why it was split in the first place.  For many years I have seen two primary reasons for moving the pagefile off C:.  One was due to the small size of disks.  That reason has pretty much disappeared.  The second was for perceived performance reasons.  Again, that reason has pretty much disappeared as the usage of pagefiles has diminished significantly over the years.  However, even though the justification presented for moving the pagefile has diminished, I still see many people who have not re-evaluated their processes due to changes in technology.  Hence the suggestion to re-evaluate.

    You have re-evaluated and present a cogent reason with replication.


    . : | : . : | : . tim

    Wednesday, December 07, 2016 2:08 PM
  • I am unable to replicate what you guys are seeing. Server 2016 Guest OS with a separate VHDX for the page file.

    Same CSV, different CSV, dynamic VHDX, fixed VHDX, system managed PF, defined size PF; they all work fine and the VM shuts down/reboot just fine.

    I would suggest you open a support case with Microsoft.

    Wednesday, December 07, 2016 3:20 PM
  • We are experiencing the exact same issue.

    We disabled the page file on C and then create a system managed page file on D which is a separate virtual hard disk.  We are doing this to mimic the way Azure creates the D temp drive.  With this setup, if I wait at least 4 minutes of up time and then reboot, the VM hangs on restarting.

    I have installed the latest Dec Cumulative patch but this didn't fix the issue.  Something else interesting is that you must wait at least 4 minutes after the machine comes online before you attempt to reboot for the issue to appear.  If you reboot in less than 4 minutes the VM will reboot with no issues.  I also attempted to partition the primary VHDX so that D exists on the same drive but the issue was still there.

    Something else that I found out that if I don't disable the page file on C and leave both C and D to be System Managed, there is no issues with rebooting.

    Tuesday, January 03, 2017 6:03 PM
  • So I figured out that if I change the Write Debugging Information from Automatic memory dump to None, the reboot issues went away.  I am able to reboot with no issues having no pagefile on C and a System Managed Page File on D.  Seems like a bug to me.
    Tuesday, January 03, 2017 6:36 PM
  • Even though this seems like a bug, this following article clearly states that you must have a page file on the boot volume for automatic memory dump to work (this is on by default).

    So if you don't have a page file on your boot volume, turn this off.  This did fix my reboot issues:

    https://support.microsoft.com/en-us/kb/307973

    •To take advantage of the dump file feature, your paging file must be on the boot volume. If you have moved the paging file to another volume, you must move it back to the boot volume before you use this feature.

    • Proposed as answer by Paul Zirkzee Thursday, March 16, 2017 9:43 PM
    Tuesday, January 03, 2017 6:51 PM
  • Hi Robert,

    Thanks for sharing the information.

    We could wait for later official documents to see if there would be any related information.

    Best Regards,

    Leo


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

    Wednesday, January 04, 2017 1:13 AM
    Moderator
  • Discovered this bug today. In my deployments we always exclude the pagefile from DPM backups as described in the best practice of putting the pagefile onto another VHDX.

    Under Server 2012 R2 "Write Debugging Information" is set to Automatic so I can't see how this isn't a bug in 2016.

    Saturday, March 11, 2017 8:37 AM
  • I had exactly the same problem. Setting "System Failure -> Write debugging information" to "None" solved the problem.
    Thursday, March 16, 2017 9:45 PM
  • Even though this seems like a bug, this following article clearly states that you must have a page file on the boot volume for automatic memory dump to work (this is on by default).

    So if you don't have a page file on your boot volume, turn this off.  This did fix my reboot issues:

    https://support.microsoft.com/en-us/kb/307973

    •To take advantage of the dump file feature, your paging file must be on the boot volume. If you have moved the paging file to another volume, you must move it back to the boot volume before you use this feature.

    The article you linked seems outdated. Even though not for Windows Server 2016, the following article indicates that the page file does not need to be on the partition containing the installed OS. The partition containing the installed OS is often called the boot volume.

    https://support.microsoft.com/en-us/help/969028/how-to-generate-a-kernel-or-a-complete-memory-dump-file-in-windows-server-2008-and-windows-server-2008-r2

    In Windows 7 and Windows Server 2008 R2, to get a Memory Dump, the paging file does not have to be on the same partition as the partition on which the operating system is installed. To put a paging file on another partition, it is not mandatory to use DedicatedDumpFile registry entry.

    In my tests, I found that hangs on shutdown did not occur after changing "Write debugging information" to "Complete memory dump", "Kernel memory dump", "Small memory dump (256 KB)", and "(none)".

    In my tests, I found that changing "Write debugging information" from "Complete memory dump" to "Automatic memory dump" resulted in the first shutdown not hanging. However, the second shutdown did hang.

    In my tests, I found that changing "Write debugging information" from "Complete memory dump" to "Active memory dump" resulted in shutdown 1, 2, and 3 not hanging. After the 3rd shutdown, I forced the VM to demand more memory than was allowed by "Maximum RAM" then started shutdown 4. Shutdown 4 hanged.

    Therefore, my tests could be somewhat flawed because I usually did not do more than 1 shutdown after a change or force the VM to demand more memory than was allowed by "Maximum RAM".

    EDIT: After further testing, I found I could cause a hang on shutdown with every setting of "Write debugging information" except "(none)".

    • Edited by KSebion Thursday, May 11, 2017 7:34 PM New information
    Thursday, May 11, 2017 6:38 PM
  • After a long research (> 2h). There is no event, nowhere, and only affect windows server 2016, not 2008 R2, 2012, 2012 R2. The host is Windows server 2012 R2.

    Thanks to Robert Auten !!

    As other, we migrate SWAP to another drive for DPM. 

    After change to none, shutdown/restart works as usual.

    Tuesday, May 16, 2017 3:50 PM