Azure VM RDP Issues? DHCP Client Service May Be the Culprit

Updated: 25 Jun, 2025 • 0 • min read

Table of Contents

Applies to: ✅ Windows VMs

This article addresses a common problem encountered when trying to establish a Remote Desktop (RDP) connection to an Azure Windows Virtual Machine (VM): the connection fails because the DHCP Client service within the VM has been disabled or is not running correctly. In Azure’s networking model, the DHCP Client service plays a vital role in assigning necessary network configuration details, including the IP address, to the VM’s network interface. Without this service functioning, the VM may not acquire a valid IP address or initialize its network stack properly, thus preventing RDP connections.

Understanding the dependency of Azure VMs on DHCP is crucial. Unlike on-premises environments where static IPs or manually configured network settings might be common, Azure typically relies on dynamic IP assignment through DHCP for its virtual machines. Even if a VM has a static public IP assigned in the Azure portal, the internal IP address assigned to the network interface within the VM operating system is usually obtained via DHCP. If the DHCP Client service is stopped or misconfigured, the VM cannot get this internal IP, leading to network connectivity issues, including the inability to connect via RDP.

Symptoms¶

The primary symptom is the inability to connect to your Azure Windows VM using Remote Desktop Protocol (RDP). The connection attempt will typically time out or fail with a generic network error.

When troubleshooting from the Azure portal, if you check the Boot diagnostics screenshot for the affected VM, you will likely see the VM has successfully booted up and reached the login screen. This indicates the operating system is functional at a basic level, but the problem lies within the network configuration or services preventing remote access. The VM appears ready to accept credentials, but no remote connection can be established.

To confirm the issue is related to the DHCP Client service, you can remotely view the system event logs of the VM. This can often be done using tools like Event Viewer from another machine if network access is partially functional (though RDP itself is blocked), or more reliably via the Azure Serial Console. Looking through the System logs, you might find errors related to the DHCP Client service starting or failing to start.

A common event indicating this problem is Event ID 7022 from the Service Control Manager source. This event signifies that a service, in this case the DHCP Client service, started and then hung or failed.

Here is a sample log entry you might find:

Log Name: System
Source: Service Control Manager
Date: 12/16/2015 11:19:36 AM (Date and time will vary)
Event ID: 7022
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: myvm.cosotos.com (Computer name will vary)
Description: The DHCP Client service hung on starting.

For Azure Resource Manager VMs, you can utilize the Serial Access Console feature to query for specific event logs like 7022. Connect to the Serial Console and use the command prompt or PowerShell instance. The following command is useful for querying the System log for Event ID 7022 events within the last 24 hours (86400000 milliseconds):

wevtutil qe system /c:1 /f:text /q:"Event[System[Provider[@Name='Service Control Manager'] and EventID=7022 and TimeCreated[timediff(@SystemTime) <= 86400000]]]" | more

This command queries the ‘System’ event log, counts one event (/c:1 - although you might want to remove this to see all recent events), formats the output as text (/f:text), and filters (/q) for events from the ‘Service Control Manager’ provider with Event ID 7022 that occurred within the last 86400000 milliseconds (24 hours) of the current system time. Piping to more helps paginate the output if there are many events.

For Classic VMs, accessing event logs directly via Serial Console is not typically available in the same manner. You would usually need to work in an offline mode by attaching the OS disk to another VM or using Azure troubleshooting tools that analyze the disk content, and then manually collect and examine the logs. This offline approach involves mounting the OS disk’s file system and registry hive to inspect the event logs stored on the disk.

Azure VM Boot Diagnostics Screenshot
Screenshot from Azure Boot Diagnostics showing VM reached login screen.

Cause¶

The root cause of this RDP issue, as indicated by the symptoms, is straightforward: the DHCP Client service required for the VM to obtain its network configuration from Azure’s virtual network infrastructure is not running.

This can happen for several reasons:
* The service was manually stopped or disabled.
* A software installation or system configuration change inadvertently affected the service or its dependencies.
* Permissions on the service’s executable, configuration keys in the registry, or dependency files were altered, preventing it from starting.
* The service account used to run the DHCP Client service was changed or its credentials became invalid.
* The service is crashing or hanging due to internal errors or conflicts with other system components.

Note: This article specifically addresses issues with the DHCP Client service, which is responsible for receiving IP configuration. It does not apply to issues with the DHCP Server role, which is used to assign IP addresses to other devices on a network (a role typically not configured on standard Azure VMs obtaining their own IPs).

Solution¶

Before attempting any troubleshooting steps that involve modifying the VM’s configuration, it is highly recommended to take a snapshot of the OS disk of the affected VM. A snapshot serves as a point-in-time backup, allowing you to revert the disk to its previous state if any changes made during the troubleshooting process cause further issues. For detailed instructions on how to create a snapshot of a managed disk, refer to the Azure documentation on Snapshot a disk. This ensures you have a safety net before proceeding.

To resolve the problem, you primarily have two approaches:
1. Using the Azure Serial Console to attempt repair actions directly on the running VM.
2. Repairing the VM offline by attaching its OS disk to another functional VM.

Use Serial Console¶

The Azure Serial Console provides a text-based console access to your VM, even if the network stack is not fully functional. This is often the quickest method if the VM is booting but experiencing service issues.

Connect to Serial Console: Access the Serial Console for your VM in the Azure portal. Open a CMD or PowerShell instance within the Serial Console. You can typically switch between CMD and PowerShell sessions if needed. If the Serial Console is not enabled or not working for your VM, you may need to resort to the offline repair method or troubleshoot the Serial Console connectivity itself.
Check DHCP Service Status: Use the sc query command to check the current state of the DHCP Client service.
```
sc query DHCP
```
The output will show the service state (e.g., STOPPED, RUNNING, START_PENDING, STOP_PENDING). If the state is STOPPED, START_PENDING (stuck), or any state other than RUNNING, the service is not functioning correctly.
Attempt to Start the Service: If the service is stopped, try to start it using the sc start command.
```
sc start DHCP
```
This command attempts to initiate the DHCP Client service. Wait a few moments for the command to execute.
Verify Service Status: Query the service status again to confirm if it started successfully.
```
sc query DHCP
```
Look for the STATE field in the output. It should now show RUNNING. If the service shows RUNNING, attempt to connect to the VM via RDP. The problem may be resolved.
Troubleshooting Service Startup Errors: If the service fails to start or shows a state indicating an error (e.g., START_PENDING indefinitely, or an error message is displayed), the sc start command or the system event logs may provide an error code. Based on the error code received, consult the following table and follow the appropriate solution provided in the subsequent sections.

Error Code	Error Description	Suggested Solution
5	ACCESS DENIED	See DHCP Client service is stopped because of an Access Denied error.
1053	ERROR_SERVICE_REQUEST_TIMEOUT	See DHCP Client service crashes or hangs.
1058	ERROR_SERVICE_DISABLED	See DHCP Client service is disabled.
1059	ERROR_CIRCULAR_DEPENDENCY	This indicates a complex dependency issue. Contact Azure Support for assistance.
1067	ERROR_PROCESS_ABORTED	See DHCP Client service crashes or hangs.
1068	ERROR_SERVICE_DEPENDENCY_FAIL	This indicates a required service the DHCP Client depends on is not running or is failing. Contact Azure Support for assistance.
1069	ERROR_SERVICE_LOGON_FAILED	See DHCP Client service fails because of logon failure.
1070	ERROR_SERVICE_START_HANG	See DHCP Client service crashes or hangs.
1077	ERROR_SERVICE_NEVER_STARTED	See DHCP Client service is disabled.
1079	ERROR_DIFERENCE_SERVICE_ACCOUNT	This indicates the service is configured to run under an account different from the LocalSystem account used by other services in the same process. Contact Azure Support for assistance.
(Generic Timeout)	Often manifests as 1053	See DHCP Client service crashes or hangs or Contact Azure Support.

DHCP Client service is stopped because of an Access Denied error (Error 5)¶

An “Access Denied” error when starting a service often means the service’s process, or the account it is running under, does not have the necessary permissions to access critical system resources like files, folders, or registry keys. To diagnose this, you can use a tool like Process Monitor from Sysinternals (Microsoft).

Connect to Serial Console (PowerShell): Access the Serial Console and open a PowerShell instance. PowerShell is more convenient for downloading files directly from the web.

Download Process Monitor: Download the Process Monitor tool onto the VM. You can use PowerShell’s Net.WebClient object for this.

remove-module psreadline # Sometimes needed for older Serial Console hosts
$source = "https://download.sysinternals.com/files/ProcessMonitor.zip"
$destination = "c:\temp\ProcessMonitor.zip"
$wc = New-Object System.Net.WebClient
$wc.DownloadFile($source,$destination)
Expand-Archive -Path $destination -DestinationPath c:\temp -Force

This script downloads the Process Monitor zip file to c:\temp, then extracts it. Ensure the c:\temp directory exists (mkdir c:\temp if necessary).

Start Process Monitor Trace: Navigate to the directory where Process Monitor was extracted (e.g., cd c:\temp) and start a trace in quiet and minimized mode, saving the output to a backing file.
```
procmon /Quiet /Minimized /BackingFile c:\temp\ProcMonTrace.PML
```
Use cmd within the Serial Console for running procmon. This command starts monitoring system activity but runs in the background (/Quiet /Minimized) and logs events directly to the specified file (/BackingFile) to conserve memory.
Reproduce the Error: Immediately after starting the trace, attempt to start the DHCP service again using the sc start command to trigger the “Access Denied” error while Process Monitor is running.
```
sc start DHCP
```
Wait for the command to fail or hang. Once the error occurs or you’ve given it sufficient time to fail, terminate the Process Monitor trace.
```
procmon /Terminate
```
This command stops the monitoring and ensures the trace data is saved to the PML file.
Collect the Trace File: The c:\temp\ProcMonTrace.PML file contains the logged events. Since you cannot easily transfer large files out of the Serial Console, the most reliable method is to attach a data disk to the VM, copy the file to the data disk, detach the data disk, and then attach it to a working Windows VM where you can analyze the file.
- Attach a new or existing data disk to the affected VM via the Azure portal.
- Connect back to the Serial Console and open a CMD or PowerShell session.
- Identify the drive letter assigned to the newly attached data disk within the VM (use wmic logicaldisk get deviceid, volumename, size or Disk Management console via diskmgmt.msc if available). Let’s assume it’s F:.
- Copy the trace file to the data disk:
```
copy C:\temp\ProcMonTrace.PML F:\
```
  Replace F:\ with the actual drive letter of your attached disk.
- Detach the data disk from the affected VM using the Azure portal. Crucially, ensure the disk is offline or detached cleanly from the guest OS before detaching it in the portal to prevent data corruption.
- Attach the same data disk to a working Windows VM that has Process Monitor installed.
Analyze the Trace: On the working VM, open the ProcMonTrace.PML file using the Process Monitor application.
- Apply a filter to the trace to focus on “Access Denied” results. In Process Monitor, go to Filter -> Filter… or press Ctrl+L.
- Set up a filter rule: Result | is | ACCESS DENIED | Include. Click “Add” and then “OK”.
- Review the filtered events. Look for events near the time you attempted to start the DHCP service. Identify which specific file path, registry key path, or other resource the svchost.exe process (which usually hosts the DHCP service) was trying to access when the “Access Denied” result occurred.
Example of filtering Process Monitor results for “ACCESS DENIED”.
Fix Permissions: The analysis will pinpoint the resource(s) causing the error. The issue is typically that the account the DHCP service runs under (NT Authority\LocalService by default) lacks the necessary permissions (ACLs - Access Control Lists) on these resources.
- Connect back to the working VM where the affected OS disk is attached.
- Navigate to the identified file, folder, or registry key on the attached disk (e.g., F:\Windows\System32\dhcpcsvc.dll or a key under HKLM\BROKENSYSTEM\...).
- Compare the permissions on this resource with the permissions on the same resource on the working VM’s OS.
- Adjust the permissions on the affected resource on the attached disk to match those on the healthy system, ensuring the NT Authority\LocalService account has the appropriate Read, Read & Execute, or Full Control permissions as needed. You can use File Explorer’s Security tab or the Registry Editor’s Permissions option for this.
- After correcting permissions, detach the OS disk cleanly from the working VM and reattach it to the original VM.
- Attempt to start the VM and connect via RDP.

DHCP Client service is disabled (Error 1058, 1077)¶

If the sc query DHCP command indicates the service is in a STOPPED state and its start type is set to DISABLED, you need to change the startup type back to its default, which is Automatic. Error 1077 also suggests the service is marked such that it should never be started, often synonymous with being disabled.

Restore Startup Type: Use the sc config command in the Serial Console to set the DHCP service’s startup type to auto (Automatic).
```
sc config DHCP start= auto
```
Note the space between start= and auto.
Start the Service: Now that the service is enabled, attempt to start it.
```
sc start DHCP
```
Verify Service Status: Query the service status again to ensure it is running.
```
sc query DHCP
```
The state should now be RUNNING.
Attempt RDP Connection: Try connecting to the VM using Remote Desktop.

DHCP Client service fails because of logon failure (Error 1069)¶

This error indicates that the service is configured to run under a specific user account, and the logon attempt for that account failed. The DHCP Client service, by default, runs under the built-in NT Authority\LocalService account. If this account setting was modified, it can cause logon failures if the new account doesn’t exist, has an incorrect password, or lacks necessary privileges.

Revert Service Account: Use the sc config command to reset the service’s logon account to the default NT Authority\LocalService.
```
sc config DHCP obj= 'NT Authority\LocalService'
```
Note the space between obj= and 'NT Authority\LocalService'. The account name needs to be enclosed in single quotes.
Start the Service: Attempt to start the service now that the logon account is set to the default.
```
sc start DHCP
```
Attempt RDP Connection: Try connecting to the VM using Remote Desktop.

DHCP Client service crashes or hangs (Error 1053, 1067, 1070)¶

These errors suggest the service is failing to start or stop cleanly, or is getting stuck in a pending state. This can be due to internal service issues, conflicts, or problems with shared service processes. The DHCP Client service typically runs within a shared svchost.exe process. Isolating it into its own process can sometimes help diagnose or resolve conflicts.

Attempt to Stop the Service: If the service is stuck in a START_PENDING or STOP_PENDING state, try to explicitly stop it.
```
sc stop DHCP
```
This may take a few moments. Use sc query DHCP to see if it eventually transitions to STOPPED.
Isolate the Service: Configure the DHCP service to run in its own dedicated svchost.exe process instead of sharing one with other services.
```
sc config DHCP type= own
```
Note the space between type= and own. The default type for DHCP is shared.
Start the Service: Attempt to start the service again in its isolated process.
```
sc start DHCP
```
Verify Status and Attempt RDP: Check the status with sc query DHCP. If it now shows RUNNING, attempt your RDP connection.
Contact Support: If the service still fails to start, hangs, or crashes even after isolating it, there may be deeper system corruption or conflicts. In this case, it is best to contact Azure Support for expert assistance.

Repair the VM Offline¶

If the Serial Console is not accessible, the commands fail, or the issue persists after trying the Serial Console solutions, repairing the VM offline by directly modifying its OS disk is the next step. This involves attaching the OS disk to a working VM and making necessary changes to its file system and registry.

Attach the OS disk to a recovery VM¶

Detach OS Disk: Stop the affected VM in the Azure portal and detach its OS disk.
Attach to Recovery VM: Attach the detached OS disk as a data disk to another working Windows VM in the same region. This working VM will be your “recovery VM”. Instructions for this process are available in the Azure documentation on troubleshooting Windows VMs by attaching the OS disk.
Access the Disk: Connect via Remote Desktop to your recovery VM. Open the Disk Management console (diskmgmt.msc). Ensure the attached OS disk is online and has a drive letter assigned (e.g., F:). Note this drive letter, as you will need it to access files and the registry on the attached disk.
Load the Registry Hive: Open an elevated Command Prompt (Run as administrator) on the recovery VM. Use the reg load command to load the SYSTEM registry hive from the attached OS disk. This makes the registry of the offline OS accessible through the recovery VM’s registry editor under a temporary key.
```
reg load HKLM\BROKENSYSTEM F:\windows\system32\config\SYSTEM
```
Replace F: with the drive letter of your attached OS disk. BROKENSYSTEM is a temporary key name you choose; it can be anything descriptive.
Reset DHCP Service Configuration: Now, use the reg add command to modify the DHCP service configuration within the loaded registry hive (HKLM\BROKENSYSTEM). These commands reset the start, ObjectName (logon account), and type registry values for the DHCP service to their default healthy states for both ControlSet001 and ControlSet002 (representing different boot configurations, modifying both increases the chance of the fix applying).
```
REM Set default values back on the broken service
reg add "HKLM\BROKENSYSTEM\ControlSet001\services\DHCP" /v start /t REG_DWORD /d 2 /f
reg add "HKLM\BROKENSYSTEM\ControlSet001\services\DHCP" /v ObjectName /t REG_SZ /d "NT Authority\LocalService" /f
reg add "HKLM\BROKENSYSTEM\ControlSet001\services\DHCP" /v type /t REG_DWORD /d 16 /f

reg add "HKLM\BROKENSYSTEM\ControlSet002\services\DHCP" /v start /t REG_DWORD /d 2 /f
reg add "HKLM\BROKENSYSTEM\ControlSet002\services\DHCP" /v ObjectName /t REG_SZ /d "NT Authority\LocalService" /f
reg add "HKLM\BROKENSYSTEM\ControlSet002\services\DHCP" /v type /t REG_DWORD /d 16 /f
```
- /v start /t REG_DWORD /d 2 /f: Sets the start type to 2 (Automatic) as a DWORD value, forcing the overwrite (/f).
- /v ObjectName /t REG_SZ /d "NT Authority\LocalService" /f: Sets the ObjectName to NT Authority\LocalService as a String value, forcing the overwrite.
- /v type /t REG_DWORD /d 16 /f: Sets the type to 16 (Own Process - SERVICE_WIN32_OWN_PROCESS) as a DWORD value, forcing the overwrite. This is equivalent to sc config DHCP type= own.
These commands directly edit the registry of the offline disk, reverting the DHCP service configuration to its standard, automatically starting state under the correct service account in its own process.
6. Unload the Registry Hive: Once you have finished modifying the registry, unload the hive from the recovery VM’s registry.
```
reg unload HKLM\BROKENSYSTEM
```
This step is crucial to ensure the changes are flushed to the disk and the disk is ready to be detached.
7. Detach Disk and Recreate VM: Detach the modified OS disk cleanly from the recovery VM. Then, use this disk to recreate the original VM via the Azure portal. Azure provides options to create a new VM from an existing disk.
8. Attempt RDP Connection: Start the newly created VM and attempt to connect via Remote Desktop. The DHCP Client service should now be configured to start automatically with the correct account, allowing the VM to obtain network configuration and become accessible via RDP.

If you have followed these steps and the RDP issue persists, there may be other underlying system issues affecting the network stack or service dependencies. In such cases, contacting Azure Support is recommended for more in-depth investigation.

Were you able to resolve your Azure VM RDP issue using these steps? Share your experience or ask questions in the comments below!

Computacionvinchi