PLA_E_DCS_IN_USE (0X803000AA): Data Collector Set Locked Fix

Cause 1: The Data Collector Set is already running (most common)

This is the one you'll run into 9 times out of 10. You try to start a Data Collector Set in Performance Monitor or through a scheduled task, and boom — PLA_E_DCS_IN_USE. It means the set is already active, but you can't see it in the UI because it's running as a hidden instance. Happened to me last week with a client who had a nightly log collection job that overlapped its own schedule. The previous run hadn't stopped cleanly, so the new one couldn't start.

How to check if a set is running

Open an admin Command Prompt or PowerShell and run:

logman query

You'll see a list of Data Collector Sets. Look for the one throwing the error. It'll show "Running" or "Stopped". If it's running and you didn't start it, something's stuck.

How to stop it

Use this command, replacing "YourSetName" with the exact name from the list:

logman stop "YourSetName"

If the set name has spaces, keep the quotes. If it doesn't stop, try forcing it with:

logman stop "YourSetName" -ets

The -ets flag tells it to stop even if the set is in an error state. I've used this to kill sets that hung for days on a server that wasn't rebooted in 6 months.

When you don't know the exact name

If you're not sure which set is causing the problem, check the Event Log under Applications and Services Logs > Microsoft > Windows > Diagnostic-Performance. Look for Event ID 1001 or 1003 — they'll name the set. Or just nuke all running sets with:

logman stop -ets *

That stops every running Data Collector Set on the machine. Use it only if you're sure nothing critical depends on them.

Cause 2: The Performance Logs & Alerts service (PLA) is stuck

Sometimes the set isn't actually running — it's the PLA service itself that's wedged. This happens after a crash or a forced shutdown. The service holds a handle to a semaphore that should be released, but it's not. I saw this on a Windows 10 machine that got power-cycled mid-collection.

How to restart the PLA service

Open an admin Command Prompt and run:

net stop pla

Wait a few seconds, then:

net start pla

If it doesn't stop, use taskkill to force it:

taskkill /f /im svchost.exe /fi "SERVICES eq pla"

That kills the specific svchost instance hosting PLA. Then start the service again with net start pla. After that, try your Data Collector Set again. I've had this fix work when logman stop wouldn't touch the set.

Check for dependent services

PLA depends on Remote Procedure Call (RPC). If RPC is wonky (it happens), restart it too, but be careful — other critical services rely on it. Better to reboot the machine if you suspect RPC issues. Unless you're on a server with uptime requirements, then you're stuck with the manual fix above.

Cause 3: Corrupted Data Collector Set configuration

Less common, but nasty. The XML files that define the Data Collector Set are corrupted or have permissions set wrong. This usually happens when someone manually edited the set's XML in %SystemRoot%\System32\PerfMonBackup or %ProgramData%\Microsoft\Performance\DataCollectorSets. I had a client who tried to copy a set across machines by hand and broke the schema.

How to fix it

Delete the corrupted set and recreate it. First, export the set if you can (skip if it's broken):

logman export "YourSetName" -xml "C:\backup.xml"

Then delete it:

logman delete "YourSetName"

Now recreate it from scratch in Performance Monitor or import a clean copy. If you can't even export, go to the directory above and delete the set's folder manually (make a backup first). After that, restart PLA service — see Cause 2 for that.

When all else fails

Run the System File Checker to rule out OS corruption:

sfc /scannow

If that finds nothing, use DISM:

DISM /Online /Cleanup-Image /RestoreHealth

I've only needed DISM once for this error, but it's worth a try if you've tried everything else.

Quick-Reference Summary Table

Pro tip: If you're setting up scheduled Data Collector Sets, add a gap of at least 5 minutes between the end time and the next start time. Overlapping runs are the #1 cause of this error.