VM is unresponsive when applying Group Policy Local Users and Groups policy

This article provides steps to resolve issues where the load screen doesn't respond when an Azure virtual machine (VM) applies a policy during startup.

Symptoms

When you're using boot diagnostics to view a screenshot of the VM, the screen is stuck loading with the message: "Applying Group Policy Local Users and Groups policy" or "Please wait."

Screenshot of Applying Group Policy Local Users and Groups policy loading in Windows Server 2012 R2.

Screenshot of Applying Group Policy Local Users and Groups policy loading in Windows Server 2012.

Screenshot shows 'Please wait' is loading in Windows Server 2012.

Cause

There are conflicting locks when the policy attempts to clean up old user profiles.

Note

This applies only to Windows Server 2012 and Windows Server 2012 R2.

Here's the problematic policy:

Computer Configuration\Policies\Administrative Templates\System/User Profiles\Delete user profiles older than a specified number of days on system restart

Resolution

Process overview

Tip

If you have a recent backup of the VM, you may try restoring the VM from the backup to fix the boot problem.

  1. Create and access a repair VM
  2. Disable the policy
  3. Enable serial console and memory dump collection
  4. Rebuild the VM

Note

If you encounter this boot error, the guest OS isn't operational. You must troubleshoot in Offline mode.

Step 1: Create and access a repair VM

  1. Use steps 1-3 of the VM repair commands to prepare a repair VM.
  2. Use Remote Desktop Connection to connect to the repair VM.

Step 2: Disable the policy

  1. On the repair VM, open the Registry Editor.

  2. Locate the key HKEY_LOCAL_MACHINE and select File > Load Hive from the menu.

    Screenshot shows highlighted HKEY_LOCAL_MACHINE and the menu containing Load Hive.

    • You can use Load Hive to load registry keys from an offline system. In this case, the system is the broken disk attached to the repair VM.
    • System-wide settings are stored on HKEY_LOCAL_MACHINE and can be abbreviated as "HKLM."
  3. In the attached disk, go to the \windows\system32\config\SOFTWARE file and open it.

    1. When you're prompted for a name, enter BROKENSOFTWARE.
    2. To verify that BROKENSOFTWARE was loaded, expand HKEY_LOCAL_MACHINE and look for the added BROKENSOFTWARE key.
  4. Go to BROKENSOFTWARE and check if the CleanupProfile key exists in the loaded hive.

    1. If the key exists, the CleanupProfile policy is set. Its value represents the retention policy measured in days. Continue deleting the key.
    2. If the key doesn't exist, the CleanupProfile policy isn't set. Submit a support ticket, including the memory.dmp file located in the Windows directory of the attached OS disk.
  5. Delete the CleanupProfiles key by using this command:

    reg delete "HKLM\BROKENSOFTWARE\Policies\Microsoft\Windows\System" /v CleanupProfiles /f
    
  6. Unload the BROKENSOFTWARE hive by using this command:

    reg unload HKLM\BROKENSOFTWARE
    

Step 3: Enable serial console and memory dump collection

To enable memory dump collection and the serial console, run this script:

  1. Open an elevated command prompt session. (Run as administrator.)

  2. Run these commands to enable the serial console:

    bcdedit /store <VOLUME LETTER WHERE THE BCD FOLDER IS>:\boot\bcd /ems {<BOOT LOADER IDENTIFIER>} ON
    
    bcdedit /store <VOLUME LETTER WHERE THE BCD FOLDER IS>:\boot\bcd /emssettings EMSPORT:1 EMSBAUDRATE:115200
    
  3. Verify if the free space on the OS disk is at least equal to the VM's memory size (RAM).

    If there isn't enough space on the OS disk, change the memory dump location and refer it to an attached data disk with enough free space. To change the location, replace "%SystemRoot%" with the drive letter (for example, "F:") of the data disk in the following commands.

    Suggested configuration to enable OS dump

    Load broken OS disk:

    REG LOAD HKLM\BROKENSYSTEM <VOLUME LETTER OF BROKEN OS DISK>:\windows\system32\config\SYSTEM
    

    Enable on ControlSet001:

    REG ADD "HKLM\BROKENSYSTEM\ControlSet001\Control\CrashControl" /v CrashDumpEnabled /t REG_DWORD /d 1 /f
    REG ADD "HKLM\BROKENSYSTEM\ControlSet001\Control\CrashControl" /v DumpFile /t REG_EXPAND_SZ /d "%SystemRoot%\MEMORY.DMP" /f
    REG ADD "HKLM\BROKENSYSTEM\ControlSet001\Control\CrashControl" /v NMICrashDump /t REG_DWORD /d 1 /f
    

    Enable on ControlSet002:

    REG ADD "HKLM\BROKENSYSTEM\ControlSet002\Control\CrashControl" /v CrashDumpEnabled /t REG_DWORD /d 1 /f
    REG ADD "HKLM\BROKENSYSTEM\ControlSet002\Control\CrashControl" /v DumpFile /t REG_EXPAND_SZ /d "%SystemRoot%\MEMORY.DMP" /f
    REG ADD "HKLM\BROKENSYSTEM\ControlSet002\Control\CrashControl" /v NMICrashDump /t REG_DWORD /d 1 /f
    

    Unload broken OS disk:

    REG UNLOAD HKLM\BROKENSYSTEM
    

Step 4: Rebuild the VM

Use step 5 of the VM repair commands to reassemble the VM.

If the issue is fixed, the policy is now disabled locally. For a permanent solution, don't use the CleanupProfiles policy on VMs. Use a different method to perform profile cleanups.

Don't use this policy:

Machine\Admin Templates\System\User Profiles\Delete user profiles older than a specified number of days on system restart

Next steps

If you have issues when you apply Windows Update, see VM is unresponsive with "C01A001D" error when applying Windows Update.

Contact us for help

If you have questions or need help, create a support request, or ask Azure community support. You can also submit product feedback to Azure feedback community.