0X000002BA

Fix ERROR_OBJECT_NAME_EXISTS (0x000002BA) – Object Name Already Exists

Windows Errors Intermediate 👁 0 views 📅 Jun 10, 2026

This error pops up when Windows tries to create an object—like a file, registry key, or named pipe—that's already there. The fix is usually simpler than you think.

1. Application or service is trying to create a duplicate named pipe or kernel object

This is the #1 cause in my experience. Some dev writes code that calls CreateNamedPipe() or CreateFile() with CREATE_ALWAYS or OPEN_ALWAYS on an object that's already open. Happens constantly with custom services, antivirus drivers, or backup agents.

The real fix is to stop the duplicate service or process. Open Task Manager, go to the Details tab, and look for multiple instances of the same executable. Sort by name—if you see svchost.exe entries with the same PID? That's not it. But if you see two copies of myapp.exe, kill one.

If that doesn't work, check the System Event Log:

Get-WinEvent -LogName System | Where-Object { $_.Id -eq 7000 -or $_.Id -eq 7001 } | Format-List

Look for a service that failed to start because "a duplicate object name was specified." Disable that service with:

sc stop BadServiceName
sc config BadServiceName start= disabled

Skip the registry hunt if the error comes from a service—it's almost always the service itself causing the conflict.

2. Registry key already exists with different permissions or value type

This one's a classic when you're deploying registry changes via Group Policy or SCCM. You try to create HKLM\SOFTWARE\MyApp\Settings, but the key already exists—just with different ACLs or a different data type. The API call fails because it can't overwrite without explicit permission.

Quick check: Open Regedit, go to the parent key, and check if the child key exists. If it does, right-click → Permissions → check if SYSTEM or Administrators have Full Control. They usually do. The real problem is often a subkey created by a previous install that's read-only.

Fix it with:

takeown /f "HKLM\SOFTWARE\MyApp\Settings" /r /d y
icacls "HKLM\SOFTWARE\MyApp\Settings" /grant "SYSTEM:(OI)(CI)F" /T

On a 64-bit machine, don't forget the WOW6432Node path:

HKLM\SOFTWARE\WOW6432Node\MyApp\Settings

Also check if the key uses REG_SZ when the installer expects REG_DWORD. Delete the key with reg delete and let the installer recreate it—or just change the value type in the installer script.

3. File or directory already exists with a different case or hidden attribute

Windows NTFS is case-insensitive but case-preserving. That means C:\Temp\Data.txt and C:\Temp\data.txt are the same file. But some third-party apps (looking at you, Adobe and old Java apps) try to create both and fail with 0x000002BA.

Also happens when a file is hidden or has the FILE_ATTRIBUTE_SYSTEM flag set. The CreateFile() call with CREATE_NEW fails because the object exists, but you can't see it in Explorer. Run this from an admin prompt:

dir /a:hs C:\Path\To\File

If you see it, remove the attributes with:

attrib -h -s C:\Path\To\File

Then delete it if needed:

del /f /q C:\Path\To\File

For directories, same thing but use rmdir /s /q. Watch out for junction points—if the directory is a symlink to another location, deleting it deletes the target. Check with dir /aL first.

Quick-reference summary

CauseTypical scenarioFix
Duplicate named pipe or kernel objectService or app tries to create an object already in useStop/kill duplicate service or process
Registry key exists with wrong permissions or typeGroup Policy or installer fails to writeTake ownership, grant Full Control, or delete key
Hidden or case-sensitive file conflictThird-party app can't create file with different caseRemove hidden/system attributes, then delete

If none of these work, run Process Monitor (procmon.exe) from Sysinternals. Filter on Result = NAME_COLLISION and watch what's failing. That'll show you the exact object path. Then you'll know which cause above applies.

Was this solution helpful?