PLA_E_DC_ALREADY_EXISTS (0X80300109): Fix Data Collector Conflict

Quick answer (for advanced users)

Delete the existing Data Collector Set with the same name using logman delete <name> in an elevated command prompt, or rename it in PerfMon. The exact error 0X80300109 means PLA (Performance Logs and Alerts) already registered a collector with that identifier.

Why this happens

This error pops up when you try to create a new Data Collector Set in Windows Performance Monitor (PerfMon) and the name you're using matches an existing one — even if that set was deleted from the GUI but still lingers in the registry or is held open by a service. I've seen it most often on Windows 10 Pro (build 1909+) and Windows Server 2019/2022 after failed backup restorations or when a scheduled task tries to recreate a set that's already running. The underlying API call (PLA_E_DC_ALREADY_EXISTS) is strict: no two sets can share a name, even if one is disabled or corrupted.

Fix steps

Step 1: Identify the conflicting Data Collector Set

1. Open Performance Monitor (perfmon.msc).
2. Expand Data Collector Sets in the left pane.
3. Look under User Defined or System for a set with the exact name you're trying to create.
4. If you see it, right-click and choose Delete or Stop if it's running.

Step 2: Use logman to remove stubborn sets

If the set won't delete from the GUI — maybe it's corrupted or held by a locked file — use the command line:

logman.exe stop <NameOfSet> -ets
logman.exe delete <NameOfSet>

Replace <NameOfSet> with the actual name (case-insensitive). Run this in an elevated Command Prompt (Admin). The -ets flag stops any running trace session tied to that set.

Step 3: Rename the new set (if you can't delete the old one)

Sometimes you just need a different name. In PerfMon's Create New Data Collector Set wizard, choose a name that includes a date or version, like MyApp_Trace_20250314. This avoids the conflict entirely.

Alternative fixes if main steps fail

Check for orphaned registry entries

Open regedit.exe and navigate to:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib\LastCounter

That's not directly related — the actual collector set metadata lives under:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\PLA\DataCollectorSets

Export that key first, then delete the subkey matching your set name. Reboot. This has fixed stuck sets for me on Windows Server 2016.

Restart the Performance Logs and Alerts service

Run in an elevated prompt:

net stop pla
net start pla

This clears temporary locks. Try creating the set again.

Run System File Checker

Corrupted system files can cause PLA to misreport conflicts. Run sfc /scannow from an elevated prompt. If it finds issues, reboot and retry.

Prevention tip

Before creating a new Data Collector Set, always list existing ones with logman query to spot name collisions early. And if you're automating this with scripts or Group Policy, use unique names — append a timestamp or GUID. That alone has stopped this error from hitting my team's monitoring servers.

I've seen this error trip up even experienced admins when restoring from backups. The Data Collector Set gets recreated by a scheduled task while the old one's still running. So check your Task Scheduler too — look for triggers under Microsoft > Windows > PLA. Disable any duplicate tasks.

One more thing: if you're using PowerShell to create sets via New-Object -ComObject PLA.DataCollectorSet, make sure you're calling $set.Commit(,,) with the correct parameters. A mismatched name there throws the same 0X80300109. I keep a snippet like this handy:

$name = "MySet_$(Get-Date -Format yyyyMMdd)"
$set = New-Object -ComObject PLA.DataCollectorSet
$set.DisplayName = $name
# ... configure collectors ...
$set.Commit($name, $null, 0x0003)

That gets you a unique name every time. No more conflicts.