Windows Data Collector Error 0x8030010D: No Duplicates

When You'll See This Error

You'll get PLA_E_NO_DUPLICATES (0x8030010D) right when you try to start a Data Collector Set in Performance Monitor on Windows 10 or Windows 11. This happens almost always after you've edited an existing Data Collector Set manually — maybe you added a counter twice, or you copied a collector set from another machine and didn't realize the rules overlapped.

I've seen this most often when someone exports a collector set from one server, imports it on another, and the imported set has a rule that's already defined in the default system sets. Or when a user tries to run a custom set that includes both a performance counter alert and a trace provider with the same GUID. The Performance Logs and Alerts service (PLA) just won't allow it.

What's Actually Going On

The root cause is straightforward: Windows PLA insists that every rule, counter, or provider in a Data Collector Set be unique within that set. It's not a system-wide thing — it's within a single collector set. If you have two data collectors that reference the same performance counter path, or two alert rules that trigger on the same event, the service throws 0x8030010D.

This isn't a bug. It's by design. PLA's logic is that duplicate rules don't add value — they just waste resources logging the same data twice. But it's annoying because the error message doesn't tell you which rule is the duplicate. You have to hunt for it.

How to Fix It — Step by Step

Step 1: Identify the Problematic Data Collector Set

1. Open Performance Monitor. Hit Win + R, type perfmon.exe, press Enter.
2. On the left, expand Data Collector Sets. You'll see User Defined and System.
3. Look for any set under User Defined that's stopped with a red X or that fails to start. Right-click it and choose Properties. After you do this, you'll see the set's name and its data collectors listed in the main pane.

Step 2: Export the Set to XML

1. Still in Performance Monitor, right-click the problem set and choose Export Template...
2. Save it somewhere you can find, like C:\temp\. Name it something like problem_set.xml.
3. Open that XML file in Notepad (or any text editor). You'll see a bunch of <DataCollector> elements inside <DataCollectorSet>.

Step 3: Find the Duplicate Rule or Counter

This is where you need to look carefully. Search through the XML for any repeated block. Common culprits are:

• Performance Counters: Look for <Counter> elements. If you see the exact same counter path twice (like \Processor(_Total)\% Processor Time), that's your duplicate.
• Alert Rules: Look for <Alert> blocks with the same <Counter> and threshold value.
• Trace Providers: Look for <TraceDataProvider> with duplicate GUIDs.

For example, this is a duplicate you'd see:

<Counter>\Memory\Available MBytes</Counter>
<Counter>\Memory\Available MBytes</Counter>

Remove the duplicate entry entirely. Delete the entire <Counter> line or the whole <DataCollector> block if it's a single counter collector.

Step 4: Import the Fixed XML

1. Back in Performance Monitor, right-click User Defined and choose Import Template...
2. Select the XML file you just fixed. It'll ask if you want to overwrite the existing set — say Yes.
3. Now try to start the set again. Right-click it and choose Start.

After importing, the set should turn green and start logging. If it doesn't, you missed another duplicate. Go back to Step 2 and recheck the XML.

Alternative: Delete the Set and Recreate It

If editing XML sounds like a chore, you can just delete the set entirely and rebuild it from scratch. In my experience, that's faster for simple sets with just a few counters. Right-click the set, choose Delete, then create a new set under User Defined by right-clicking and choosing New > Data Collector Set. Name it, pick Create manually, and add your counters one by one. Make sure you don't add the same counter twice.

What If It Still Fails?

If after all that you still get 0x8030010D, check these things:

• System sets: Go under System in the left pane. Expand Event Trace Sessions and Startup Event Trace Sessions. Look for any running session that uses the same provider GUID as your set. If one exists, that's a conflict. You can stop that system session temporarily — but don't delete it unless you're sure it's safe.
• Corrupted XML: If you edited the XML by hand and missed a closing tag, the import will fail silently. Validate your XML by opening it in a browser — if it shows errors, fix them.
• Permissions: Rare, but if the Data Collector Set runs as a specific user account, that account might not have rights to read certain counters. Run the set as System in the set's properties under the Security tab.

Most of the time, though, it's just a plain duplicate counter. Strip it out, and you're good.