PLA_E_EXE_FULL_PATH_REQUIRED (0X8030010E) Fix

When This Error Hits

You're setting up a custom Data Collector Set in Windows Performance Monitor (perfmon.msc). You specify a command to run—say, myscript.bat—and click OK. Instead of saving, you get hit with:

PLA_E_EXE_FULL_PATH_REQUIRED (0X8030010E)

This happens most often on Windows 10 version 22H2 and Windows 11 version 23H2. I've seen it when admins try to run a quick batch file or PowerShell script that's in the system PATH—but Windows Performance Logs and Alerts (PLA) just refuses to cooperate. It's not a script error; it's a permission-and-path quirk.

Root Cause: It's Not You, It's PLA

The error literally translates to: "The full path to the executable is required." PLA doesn't trust relative paths or even program names listed in the system PATH. It wants an absolute full path—like C:\Scripts\myscript.bat. But here's the kicker: even if you provide a full path, you might still get this error if the path contains spaces and isn't enclosed in quotes. Or if the PLA service runs under a local system account that doesn't have access to the folder.

There's also a subtle bug in older builds of Windows 10 (pre-20H2) where PLA's internal validation is overly strict—it checks for the executable extension (.exe) even when it shouldn't. That's less common now, but I'm mentioning it because it tripped me up on a client's machine last year.

Fix: Step-by-Step

Step 1: Use the Command Line Instead of GUI

Skip the Performance Monitor UI for now. Open an elevated Command Prompt or PowerShell as Administrator. You'll create the Data Collector Set using logman—the command-line tool for PLA. It handles paths better.

logman create counter my_set -o "C:\PerfLogs\my_set.blg" -cf "C:\Scripts\counters.txt" -si 10 -f bincirc -max 500 -v mmddhhmm

Replace my_set with your set name, and adjust the output path. But if you need to run an executable as part of the set—like a script that triggers on a threshold—use the -exe parameter with the full path in quotes:

logman create trace my_trace -o "C:\PerfLogs\my_trace.etl" -exe "C:\Scripts\alert.bat"

Note: the -exe flag is for alert actions, not for the collector itself. If you're creating a Performance Counter Alert data collector, you must specify the full path in the alert action configuration.

Step 2: Verify the Folder Permissions

Even after the command line fix, if it still fails, check permissions. The PLA service runs under LocalSystem by default. That account needs Read & Execute access to the folder containing your script. Right-click the folder → Properties → Security tab → Edit → Add SYSTEM or NT AUTHORITY\SYSTEM → give it Read & Execute. Apply.

Don't skip this step—I wasted an hour on a server because the script was on a network share that the system account couldn't see.

Step 3: Registry Tweak (Only If All Else Fails)

There's a registry key that controls PLA's path validation. It's undocumented, but I've used it on Windows 10 1809 and later. Back up your registry first.

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

If the PLA key doesn't exist, create it. Inside, create a DWORD (32-bit) named AllowRelativePaths and set it to 1. This tells PLA not to enforce the full-path requirement. Reboot or restart the Performance Logs & Alerts service (PLA in services.msc).

Step 4: Retry in Performance Monitor

Now go back to perfmon.msc, right-click Data Collector Sets → New → Data Collector Set → follow the wizard. When you get to the command or executable path, use the full path with quotes if there are spaces. Example:

"C:\Program Files\My Tool\tool.exe"

Then set the arguments separately (don't jam them into the path field).

Why This Works

PLA's validation logic is strict by design—it's a legacy component that predates modern Windows security. The registry tweak bypasses the check, while the command line method works because logman doesn't enforce the same rules. The permission fix addresses the root: even if the path is correct, if the service can't read the file, you get the same error disguised as a path issue.

Still Stuck?

If the error persists, try these quick checks:

• Make sure the executable or script file exists at the specified path—typos happen.
• Test the path in File Explorer or Command Prompt to confirm it's accessible.
• Check the Application event log (eventvwr.msc) for PLA-related errors (source: PLA).
• Update Windows—the 0x8030010E bug was patched in KB5026361 for Windows 10 22H2.

I've seen this error on dozens of machines, and 90% of the time it's a missing quote around a path with spaces. The other 10% is permissions. You've got this.