Fix PLA_E_NETWORK_EXE_NOT_VALID (0x80300106) UNC Path Error

1. Move the executable to a local drive (most common fix)

I've seen this error trip up everyone from IT pros to folks running a simple monitoring script. The trigger is almost always the same: you set up a Data Collector Set or a scheduled task that launches an EXE from \\server\share\app.exe. The Performance Logs and Alerts (PLA) service — which runs as LOCAL SERVICE — refuses to touch network paths. It's not being stubborn; it's by design.

The fastest fix: copy the EXE to C:\Scripts\ or any local folder, update the path, and restart the task. Here's how:

1. Create a local folder, say C:\Monitoring\.
2. Copy the executable there from your network share.
3. Open Performance Monitor (perfmon.msc).
4. Under Data Collector Sets, find your set, right-click, choose Properties.
5. In the Performance Counter or Command tab (depending on your collector type), change the executable path to C:\Monitoring\app.exe.
6. Click OK, then start the collector set.

This works every time. If you absolutely must keep the EXE on a network share (maybe it's a shared tool that updates centrally), skip to the next fix.

2. Grant SeImpersonatePrivilege to the account running the task

This is the fix when you really can't move the EXE locally. The PLA service needs the right to impersonate the security context of a network resource — that's the SeImpersonatePrivilege. By default, LOCAL SERVICE has this, but if you changed the service account or run the task under a different user (like a domain account), that account might lack it.

Check which account runs the task:

1. Open Task Scheduler (taskschd.msc).
2. Find the task that corresponds to your Data Collector Set. It's usually named something like $\Microsoft\Windows\PLA\YourCollectorSetName.
3. Right-click > Properties > General tab. Note the user account under Security options.

Now grant that account the impersonate privilege:

1. Click Start, type secpol.msc, press Enter.
2. Go to Local Policies > User Rights Assignment.
3. Find Impersonate a client after authentication.
4. Add the user account (e.g., DOMAIN\YourUser).
5. Click OK, then run gpupdate /force in an admin Command Prompt.
6. Restart the PLA service: net stop pla && net start pla.

Test the task again. This fix is a bit more involved, but it avoids moving files around.

3. Use runas with /netonly to map the network drive

Sometimes the error pops up even after you've granted impersonation rights. Here's the real-world scenario I see most: the EXE lives on a share that requires different credentials than the ones the PLA service uses. For example, your monitoring tool is on \\FileServer\Tools\monitor.exe, and that server requires a specific service account to access it.

The trick is to use runas /netonly to start the EXE with those remote credentials. You don't change the service account; you just wrap the launch command.

1. Create a batch file, say run-monitor.bat, with this content:

runas /netonly /user:DOMAIN\ServiceAccount "\\FileServer\Tools\monitor.exe"

2. Place that batch file locally, e.g., C:\Scripts\run-monitor.bat.
3. In your Data Collector Set, set the executable path to C:\Scripts\run-monitor.bat.
4. Make sure the batch file is readable by the PLA service account.

One gotcha: runas /netonly asks for a password interactively. For automated tasks, you'll need to save the credential using cmdkey:

cmdkey /add:FileServer /user:DOMAIN\ServiceAccount /pass:YourPassword

Don't love putting plaintext passwords in scripts? Neither do I. But for dedicated monitoring boxes with limited scope, it's a pragmatic tradeoff.

Quick reference table

If none of these work, double-check that your EXE isn't blocked by Windows Defender or AppLocker on the network share — that's a separate error but can masquerade as this one.