Active Directory Web Services (ADWS) Not Starting: Resolving Port 9389 and Event 1000 Errors

What You’re Seeing

It is 03:15 during an emergency operational call. Your identity monitoring dashboard alerts that overnight account provisioning and privileged group audits have failed across the entire infrastructure. Junior administrators report that while domain users can authenticate and access network shares without interruption, automated scripts and management consoles have broken down completely. You open PowerShell on your workstation to inspect domain health, execute Get-ADDomain, and receive an immediate terminating exception:

# Attempting standard domain queries via Active Directory PowerShell module
Get-ADDomain

Get-ADDomain : Unable to contact the server. This may be because this server does not exist, 
it is currently down, or it does not have the Active Directory Web Services running.
At line:1 char:1
+ Get-ADDomain
+ ~~~~~~~~~~~~
    + CategoryInfo          : ResourceUnavailable: (corp.example.com:RootDse) [Get-ADDomain], ADServerDownException
    + FullyQualifiedErrorId : ActiveDirectoryServer:1355,Microsoft.ActiveDirectory.Management.Commands.GetADDomain

Attempting to open the Active Directory Administrative Center (dsac.exe) on the primary domain controller produces a blank interface accompanied by a blocking dialogue:

# Active Directory Administrative Center startup dialogue
Cannot connect to any domain. Refresh or try again later.

Connecting to the domain controller and querying the service status confirms that the service is halted. Attempting to start the service manually via Start-Service ADWS either stalls until timing out with error 1053 or appears to start briefly before terminating silently:

# Query the status and configuration of the ADWS service
Get-Service -Name ADWS | Select-Object -Property Name, DisplayName, Status, StartType

Name DisplayName                    Status  StartType
---- -----------                    ------  ---------
ADWS Active Directory Web Services  Stopped Automatic

Opening Event Viewer (eventvwr.msc) and inspecting the Application log reveals a pairing of error events logged at the exact moment the service failed. The first is an Event ID 1000 from Application Error:

# Application Event Log - Event ID 1000 (Application Error)
Log Name:      Application
Source:        Application Error
Date:          10/21/2026 03:18:22 AM
Event ID:      1000
Task Category: Application Crashing Events
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      DC01.corp.example.com
Description:
Faulting application name: Microsoft.ActiveDirectory.WebServices.exe, version: 10.0.26100.1, time stamp: 0x661f9342
Faulting module name: KERNELBASE.dll, version: 10.0.26100.1, time stamp: 0x661fa114
Exception code: 0xe0434352
Fault offset: 0x0000000000053f3c
Faulting process id: 0x18ec
Faulting application start time: 0x01db23456789abcd
Faulting application path: C:\Windows\ADWS\Microsoft.ActiveDirectory.WebServices.exe
Faulting module path: C:\Windows\System32\KERNELBASE.dll

Directly preceding the Event 1000 record is the underlying diagnostic record: an Event ID 1026 from the .NET Runtime source, detailing the exact managed exception that triggered process termination:

# Application Event Log - Event ID 1026 (.NET Runtime)
Log Name:      Application
Source:        .NET Runtime
Date:          10/21/2026 03:18:21 AM
Event ID:      1026
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      DC01.corp.example.com
Description:
Application: Microsoft.ActiveDirectory.WebServices.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.ServiceModel.AddressAlreadyInUseException: There is already a listener on IP endpoint 0.0.0.0:9389.
   at System.ServiceModel.Channels.SocketConnectionListener.Listen()
   at System.ServiceModel.Channels.BufferedConnectionListener.Listen()
   at System.ServiceModel.Channels.ExclusiveTcpTransportManager.OnOpen()
   at System.ServiceModel.Channels.TransportManager.Open(TransportChannelListener channelListener)

What It Actually Means

Think of Active Directory Web Services as a modern API translation proxy sitting directly in front of the directory engine. Classic administration tools like Active Directory Users and Computers (dsa.msc) and ADSI Edit communicate using raw LDAP (TCP 389/636) or legacy MSRPC directly to the Local Security Authority Subsystem Service (LSASS). These tools work today exactly as they did in Windows 2000 Server.

In contrast, modern Windows administration components do not speak raw LDAP. When Microsoft introduced Windows Server 2008 R2, they implemented the Active Directory module for Windows PowerShell and the Active Directory Administrative Center. Rather than bundling complex LDAP parsing and ASN.1 encoding libraries into PowerShell, Microsoft built ADWS as a Windows Communication Foundation (WCF) host application. Client cmdlets format directory queries into standard XML-based SOAP envelopes conforming to WS-Transfer and WS-Enumeration specifications. These envelopes are transmitted over TCP port 9389 to ADWS, which unwraps the SOAP payload, queries the local NTDS.DIT database in-process, and returns structured objects back to the caller.

[PowerShell / ADAC] ─── SOAP / WCF (TCP 9389) ───▶ [ADWS (Microsoft.ActiveDirectory.WebServices.exe)]
                                                                     │
                                                             In-Process / Local RPC
                                                                     ▼
[Classic Tools: dsa.msc] ─── Raw LDAP (TCP 389/636) ───────▶ [LSASS / NTDS.DIT Database]

Because ADWS is a .NET managed service running as NT AUTHORITY\SYSTEM, its lifecycle is governed by the Common Language Runtime (CLR). When Microsoft.ActiveDirectory.WebServices.exe initializes, it must successfully complete four sequential operations:

First, it reads its application settings and WCF bindings from C:\Windows\ADWS\Microsoft.ActiveDirectory.WebServices.exe.config. Second, it attempts to open a raw TCP listening socket on port 9389 bound to all interfaces. Third, it connects to the cryptographic subsystem in C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys to secure endpoint channels and read server certificates. Fourth, it attaches to the active directory database instance hosted by the local NTDS service.

If any one of these stages encounters an unhandled exception, the CLR crashes the process, throwing Windows error code 0xe0434352 into the Application log. Classic directory functions like Kerberos authentication and domain replication remain operational, but your modern administrative control plane goes dark.

How to Diagnose

Diagnosing an ADWS startup failure requires walking through the service initialization sequence in order, moving from simple network socket checks to application configuration and cryptographic permissions.

Step 1: Check service configuration and startup state. Confirm that the service is configured for automatic startup and verify its binary image path using sc.exe:

# Verify the registered service configuration and binary image path
sc.exe qc ADWS

The output must confirm START_TYPE : 2 AUTO_START, SERVICE_START_NAME : LocalSystem, and BINARY_PATH_NAME : C:\Windows\ADWS\Microsoft.ActiveDirectory.WebServices.exe.

Step 2: Inspect TCP port 9389 listeners. The most frequent cause of Event 1026 and Event 1000 is socket collision. Query whether another process has already seized TCP port 9389:

# Check for active listeners or bound sockets on TCP port 9389
Get-NetTCPConnection -LocalPort 9389 -ErrorAction SilentlyContinue | Select-Object -Property LocalAddress, LocalPort, State, OwningProcess

# Identify the process name and command line holding the socket
Get-Process -Id (Get-NetTCPConnection -LocalPort 9389 -ErrorAction SilentlyContinue).OwningProcess | Select-Object -Property Id, ProcessName, Path

If a lingering, zombie instance of Microsoft.ActiveDirectory.WebServices.exe or a rogue third-party monitoring agent is listening on port 9389 while the Service Control Manager considers the service stopped, subsequent start attempts will fail immediately with AddressAlreadyInUseException.

Step 3: Extract the exact managed exception from event logs. Do not rely solely on the generic Event 1000 message. Query the Application log specifically for recent Event 1026 entries from the .NET Runtime:

# Extract recent .NET Runtime unhandled exceptions for ADWS
Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='.NET Runtime'; Id=1026} -MaxEvents 3 | Format-List -Property TimeCreated, Message

Inspect the Exception Info: line. A CryptographicException points to cryptographic key permissions; a ConfigurationErrorsException indicates XML corruption in the configuration file; an AddressAlreadyInUseException confirms a port conflict.

Step 4: Check the dedicated Active Directory Web Services event log. Windows maintains a dedicated operational log channel under Applications and Services Logs > Active Directory Web Services. Query it for instance registration failures:

# Query the dedicated ADWS event log channel for instance and certificate errors
Get-WinEvent -FilterHashtable @{LogName='Active Directory Web Services'; Id=1202,1400} -MaxEvents 5 -ErrorAction SilentlyContinue | Format-List -Property TimeCreated, Id, Message

Event ID 1400 indicates that ADWS could not locate an operational directory instance or valid server certificate, while Event ID 1202 warns that ADWS detected the local NTDS instance but could not service it.

Step 5: Validate the XML syntax of the service configuration file. Administrators sometimes edit Microsoft.ActiveDirectory.WebServices.exe.config to adjust group member limits or enable tracing. Test whether PowerShell’s XML parser can read the file without syntax errors:

# Validate that the service configuration file contains well-formed XML
[xml]$config = Get-Content -LiteralPath "C:\Windows\ADWS\Microsoft.ActiveDirectory.WebServices.exe.config" -Raw
$config.configuration.appSettings.add | Select-Object -Property key, value

If this command throws a parser exception, the configuration file contains an unclosed tag, invalid character, or syntax defect that prevents the .NET ConfigurationManager from bootstrapping the service.

Step 6: Audit permissions on RSA MachineKeys. ADWS requires read access to cryptographic keys stored in the machine keystore. Check the Access Control List (ACL) on the system folder:

# Inspect NTFS permissions on the MachineKeys cryptographic repository
icacls "C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys"

Healthy baseline permissions require BUILTIN\Administrators:(F) (Full Control) and Everyone:(R,W) (Read and Write) applied to the folder. If inheritance was severed or the SYSTEM account was stripped of permissions, ADWS throws a CryptographicException: Keyset does not exist error.

Common Causes

The Fix: Restoring Service Operation Step-by-Step

Once you have identified the primary cause from the diagnostic logs, execute the matching remediation steps to bring Active Directory Web Services back into operational status.

Step 1: Terminate rogue socket holders and release port 9389. When AddressAlreadyInUseException prevents ADWS from starting, an orphaned process or previous crashed instance is locking the TCP socket. Identify the offending PID and kill it:

# Identify and terminate any process blocking port 9389
$socket = Get-NetTCPConnection -LocalPort 9389 -ErrorAction SilentlyContinue
if ($socket) {
    Write-Warning "Found process $($socket.OwningProcess) holding port 9389. Terminating..."
    Stop-Process -Id $socket.OwningProcess -Force
}

Step 2: Restore baseline cryptographic permissions on MachineKeys. If security hardening scripts or GPO filesystem templates stripped inherited permissions from the machine keystore, reset permissions on the directory:

# Reset permissions on RSA MachineKeys to Microsoft baseline specifications
icacls "C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys" /grant "BUILTIN\Administrators:(OI)(CI)F"
icacls "C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys" /grant "NT AUTHORITY\SYSTEM:(OI)(CI)F"
icacls "C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys" /grant "Everyone:(OI)(CI)(R,W)"

Ensure that inheritance flags (OI)(CI) propagate down to the child key containers so that certificates used by ADWS can be accessed by the LocalSystem account.

Step 3: Revert or repair the application configuration file. If Microsoft.ActiveDirectory.WebServices.exe.config has been edited and corrupted, restore the factory defaults. If you do not have a pre-change backup, copy the clean configuration file from a healthy domain controller running the same operating system build, or verify the core settings:

# Backup the corrupted configuration file before attempting repairs
Copy-Item -LiteralPath "C:\Windows\ADWS\Microsoft.ActiveDirectory.WebServices.exe.config" `
          -Destination "C:\Windows\ADWS\Microsoft.ActiveDirectory.WebServices.exe.config.bak"

# Test XML parsing on the active file
$xml = New-Object System.Xml.XmlDocument
$xml.Load("C:\Windows\ADWS\Microsoft.ActiveDirectory.WebServices.exe.config")
Write-Output "XML validation passed. Configuration elements: $($xml.configuration.ChildNodes.Count)"

Ensure that default limits such as MaxReceivedMessageSize inside the <netTcpBinding> section match standard settings (1048576 bytes) and that custom app settings like MaxGroupOrMemberEntries are positive integers wrapped in valid XML tags.

Step 4: Verify DSRM status and directory readiness. If the domain controller was recently restored or repaired and restarted in Directory Services Restore Mode, ADWS cannot connect to NTDS. Inspect the boot configuration data:

# Verify whether the operating system is instructed to boot into Directory Services Restore Mode
bcdedit /enum {current} | Select-String "safeboot"

If the output contains safeboot DSRM, delete the value and restart the domain controller:

# Clear DSRM safeboot flag and restart domain controller into standard mode
bcdedit /deletevalue safeboot
Restart-Computer -Force

Step 5: Start the service and verify TCP listening status. With the socket freed and permissions restored, start the ADWS service and verify that it maintains a running state:

# Start Active Directory Web Services and verify operational status
Start-Service -Name ADWS
Get-Service -Name ADWS

# Verify that ADWS is actively listening on TCP port 9389
Get-NetTCPConnection -LocalPort 9389 -State Listen | Select-Object -Property LocalAddress, LocalPort, State, OwningProcess

Finally, validate end-to-end functionality by running a standard query through the Active Directory PowerShell module against the local server:

# Validate end-to-end SOAP connectivity over TCP port 9389
Get-ADRootDSE -Server "localhost:9389" | Select-Object -Property dnsHostName, domainFunctionalityVersion, defaultNamingContext

If this cmdlet returns the domain naming context and host metadata without errors, Active Directory Web Services is fully restored.

How to Prevent It

Preventing ADWS disruptions requires securing its dedicated communication port, protecting filesystem ACLs from misconfigured Group Policy objects, and monitoring service health proactively.

Reserve TCP port 9389 against dynamic port allocations. Windows Server assigns ephemeral TCP ports for outbound RPC connections starting from port 49152 by default. However, legacy systems or custom applications may lower the dynamic range. To ensure that the TCP stack never allocates port 9389 to a transient client connection during system boot, register an administrative port exclusion:

# Add an administrative port exclusion for ADWS on TCP port 9389
netsh int ipv4 add excludedportrange protocol=tcp startport=9389 numberofports=1

Verify the reservation using netsh int ipv4 show excludedportrange protocol=tcp. For a comprehensive overview of all required domain controller ports and boundaries, review our Active Directory Firewall Ports Reference.

Audit Group Policy filesystem templates. Never apply generic filesystem security templates to the C:\ProgramData\Microsoft\Crypto\ folder structure. In enterprise environments, security baseline GPOs designed for standard member servers can inadvertently strip the Everyone and SYSTEM permissions from MachineKeys when applied to domain controllers. Restrict security template modifications in your Default Domain Controllers Policy to explicit, tested paths.

Implement automated TCP 9389 synthetic monitoring. Because traditional monitoring tools only check whether the server responds to ICMP pings or standard LDAP queries on port 389, an ADWS crash can remain undetected until an administrative script fails. Deploy an automated canary check on your monitoring hosts:

# Automated synthetic health probe for ADWS from monitoring infrastructure
$test = Test-NetConnection -ComputerName "dc01.corp.example.com" -Port 9389 -WarningAction SilentlyContinue
if (-not $test.TcpTestSucceeded) {
    Write-Error "CRITICAL: ADWS listener unreachable on dc01.corp.example.com:9389"
}

For maintaining administrative automation scripts that rely heavily on healthy ADWS endpoints, see our guide on Finding and Disabling Stale Computer Accounts in Active Directory.

Final Thoughts

Active Directory Web Services is frequently misunderstood as an optional luxury because classic graphical consoles like dsa.msc function without it. In modern infrastructure, ADWS is the foundational communication bridge for PowerShell, administrative web portals, and directory automation pipelines. When it terminates unexpectedly with Event ID 1000, resist the urge to restart the domain controller blindly. Inspect the .NET Runtime Event ID 1026 for the underlying exception, verify that port 9389 is clear of orphan socket holders, check MachineKeys permissions, and validate the WCF configuration. By addressing the specific failure mode systematically, you can restore administrative services without impacting domain authentication.