PLA_E_DCS_NOT_RUNNING (0x80300104) – Fix When Data Collector Sets Won't Start

The Fix You Came For

I know the frustration — you set up a Data Collector Set in Performance Monitor (PerfMon), hit Start, it says "Running" in the status column, but then you get PLA_E_DCS_NOT_RUNNING (0x80300104). Or maybe the status literally says "Not Running" and you can't start it. Either way, here's the fix.

1. Open an administrative Command Prompt or PowerShell — Windows+X, then Terminal (Admin) or Command Prompt (Admin).
2. Run this command to restart the service and its dependent components in one shot:

net stop pla && net stop wmiApSrv && net start wmiApSrv && net start pla

That stops Performance Logs & Alerts (pla), then the WMI Performance Adapter (wmiApSrv), then starts them back in reverse order. Wait 15 seconds after the commands finish.

3. Now go back to PerfMon, right-click your Data Collector Set, and choose Start. It should actually start this time.

If the set was already stuck in a "Running" state, you might need to stop it first: right-click → Stop. Then click Start again.

That's it for nine out of ten cases. If the error comes back immediately, skip down to the "Less Common Variations" section.

Why This Works

What's actually happening here is that the pla service gets into a weird state where it thinks a Data Collector Set is running, but the internal tracking data — stored in memory and in the registry — got corrupted or desynchronised. The service reports back "not running" or "running-but-broken" because the set's thread or timer didn't actually hook into the collector engine properly.

Stopping pla clears its in-memory state. Stopping wmiApSrv is the trick — that's the WMI Performance Adapter, which feeds counter data into the collectors. If that adapter is hung or disconnected from WMI, pla can't get the performance data it needs to start the collection. Starting wmiApSrv first, then pla, forces a clean handshake between the two services. The reason step 3 works is that the Data Collector Set can now register its event sinks with both services without hitting an orphaned session handle.

Less Common Variations

User Account Control (UAC) Blocks the Start

If you're not running PerfMon as an administrator, even if your account is in the Administrators group, UAC strips the SE_SERVICE_START_NAME privilege needed to start the Data Collector Set. Symptoms: you click Start, it shows "Running" for a split second, then goes back to "Not Running" with the 0x80300104 error. Fix: right-click PerfMon.exe → Run as administrator, then start the set.

Corrupt Data Collector Set Template

If you imported a Data Collector Set from another machine — say an XML template — and it references performance counters that don't exist on your machine (like a specific logical disk on a drive letter that doesn't exist), the set will fail to start silently. The error code is the same. Check the set's properties: right-click → Properties → Performance Counters tab. Remove any counters that show a red X or a warning icon.

Missing Performance Counter DLL

On older Windows 10 builds (pre-1909) or Windows Server 2016/2019, some performance counter DLLs can get unregistered after a Windows Update or a .NET Framework repair. Run this command to rebuild the counter list:

lodctr /R

Then reboot. This re-reads the counter definitions from the registry and re-registers all DLLs. After reboot, try the Data Collector Set again.

The "Stuck Running" Ghost State

Sometimes the service shows the Data Collector Set as running even after you've deleted it or after a reboot. This is a known bug in the PLA service's state machine — it holds a reference to the set's GUID in memory. The fix is more aggressive: stop the service, clear the schedule file from disk, then restart. Open an admin Command Prompt and run:

net stop pla
sc queryex pla

Note the PID. Then run taskkill /F /PID [PID] to force-kill it. Then delete all files in C:\Windows\System32\sdtree\*.xml (these are the schedule files). Finally:

net start pla

Re-create your Data Collector Set from scratch. Don't reuse the old template.

Windows 11 24H2 Specific Issue

On Windows 11 24H2 (build 26100.xxxx), Microsoft changed how the Performance Logs service interacts with the new WMI infrastructure. If you see this error on 24H2 consistently, the fix is to add a registry key that forces the legacy WMI adapter mode:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\WmiApSrv" /v "DisableNewWMI" /t REG_DWORD /d 1 /f

Then restart both services as shown in the main fix. Microsoft will likely fix this in a future cumulative update, but for now this gets it working.

Prevention

The root cause in most environments is a service dependency chain that breaks during boot. The pla service starts automatically but sometimes starts before wmiApSrv is fully ready, especially on systems with slow disks or heavy startup applications. To bulletproof this:

• Set pla to Automatic (Delayed Start). Open services.msc, find Performance Logs & Alerts, right-click → Properties → Startup type: Automatic (Delayed Start). This waits 2 minutes before starting, giving WMI and the Performance Adapter time to settle.
• If you use Data Collector Sets as part of monitoring (SCOM, third-party tools), schedule a daily task that runs the restart command from the fix section — it's harmless and prevents the stuck state from accumulating.
• Avoid importing Data Collector Set templates from machines running different Windows versions. The counter GUIDs can shift between builds. Always create sets fresh on each machine if you can.

One more thing: if you see this error after a Windows Update, run sfc /scannow followed by dism /online /cleanup-image /restorehealth. Updates can bludgeon the WMI repository, and those commands fix it without a full repair install.