Fix ERROR_DUPLICATE_SERVICE_NAME 0X00000436 on Windows Server

Quick answer for advanced users

Run sc query | find "SERVICE_NAME" to list all service names, then sc queryex | find /i "DISPLAY_NAME" for display names. Find the conflict, then either sc delete ConflictName (if it's unused) or pick a unique name for your new service.

What's actually happening here

This error appears when sc create or installutil tries to register a Windows service, and the name you chose — either the internal SERVICE_NAME or the human-friendly DISPLAY_NAME — already exists in the Service Control Manager (SCM) database. On Windows Server 2019 and 2022, I've seen this most often during custom service installs that don't clean up after themselves, or when someone runs an installer twice without uninstalling first.

The SCM stores both names in a flat namespace, meaning no two services can share either value. The error code 0X00000436 maps to ERROR_DUPLICATE_SERVICE_NAME. It's a simple clash, not corruption — the fix is almost always just renaming or removing the conflicting entry.

Fix steps

Open Command Prompt as Administrator — Right-click Start, choose Windows Terminal (Admin) or Command Prompt (Admin).
Dump all service names and display names
```
sc query | find "SERVICE_NAME"
sc queryex | find /i "DISPLAY_NAME"
```
This gives you two lists. Compare them against the name you're trying to use.
Identify the conflict — If your new service is called MyAppService and you see it in the list, that's your problem. If the display name My Application Service appears, same thing.
Option A: Remove the old service (if it's orphaned or unused)
```
sc delete MyAppService
```
Run that, then try your install again.
Option B: Rename your new service (if the existing service is legit)
```
sc create MyAppService_v2 binPath= "C:\path\to\your.exe" displayname= "My App Service v2"
```
Pick a unique SERVICE_NAME and DISPLAY_NAME. The SCM won't let you rename an existing service on the fly — you'd have to delete and recreate it, which is risky for production services.
Retry your install — Whether it's an MSI, a manual sc create, or a .NET installer, it should now succeed.

Alternative fixes if the main one fails

If sc delete returns ACCESS_DENIED: You're not running as Administrator, or the service is protected (like a built-in Windows service). For custom services, check that the account you're using is a member of Administrators. For system services — stop trying to delete them. Change your new service's name instead.

If the service name doesn't appear in sc query but you still get the error: The display name might be the culprit. I've seen this when an installer reuses a display name but not the internal name. Check DISPLAY_NAME output carefully — it's case-insensitive but must match exactly.

If you're running an MSI that fails silently: Try msiexec /x {product-code} to fully uninstall first. Then install fresh. Or use Orca (Microsoft's MSI editor) to inspect the custom action that registers the service — sometimes it hardcodes the name.

Real-world trigger: I saw this on a Windows Server 2022 box running SQL Server 2019 and a custom app. The installer for the app was supposed to register MyAnalyticsService, but a database migration script had already created a service with that name for testing. The installer failed on the duplicate service name. Deleting the test service fixed it.

Prevention tip

Before installing any new custom service, run a quick check script:

@echo off
sc query | find /i "MyServiceName"
if %errorlevel% equ 0 (echo WARNING: Service name already exists!)

Also, always uninstall properly — don't just delete the executable. Use the installer's uninstall option, or run sc delete ServiceName from an admin prompt. MSI-based installers often leave orphaned services if the install cancels mid-way, so check for those too.

For display names, keep them unique by appending a version number or something specific to your environment. That avoids clashes when multiple teams deploy similar services on the same server.