App.Config concurrent read failures? Design Flaw?

I've had a new system in place for polling client data for a few weeks and everything was running successfully. Now every few days I start getting the following error in increasing volume with the most recent event having thousands of these errors:

System.ComponentModel.Win32Exception (0x80004005): Unknown error (0xfffffffe)
System.InvalidOperationException: Cannot start process because a file name has not been provided.
   at System.Diagnostics.Process.Start()
   at System.Diagnostics.Process.Start(ProcessStartInfo startInfo)
   at CloudPollingService.CloudPoller.ProcessPolling() in C:\<PATH>\CloudPoller.cs:line 88

The error is technically self-correcting because if this process fails the message it consumed will not be acknowledged and is able to be consumed from the queue by another worker or even the same worker. However, this is impacting performance and generally makes me uneasy as I cannot explain what is occurring.

The problem exists in my console app, which is effectively a wrapper around old code, when my console app attempts to start another console app. Here is a sample:

private string _fileToRun = ConfigurationManager.AppSettings["ExePath"];

var startInfo = new ProcessStartInfo()
{
    FileName = _fileToRun,
    Arguments = _fileArgs                       
};

Process.Start(startInfo);

Again, when this fails the message isn't acknowleged so it is likely the same intance of a worker will not enounter an error with the same message immediately after failing.

I've unsuccessfully tried advice like that contained in: Starting process (one console application from another)

So my question: Given that the error indicates there is no file name provided. Is this an issue with reading values from App.Config? Am I engaging in terrible design by spawning up 8-10 instances of a worker console app that share a single config file? If that is terrible, do I have alternatives?

The worker is incredibly simple, it consumes a message and passes in the message data as commandline args to the exe targeted by Process.Start(StartInfo).

If it makes any difference, this is running on a compute-optimized EC2 instance, Windows Server 2012 R2. I didn't run into this issue locally, but I also could only run 3-4 instances before hitting 100% CPU utilization. I would think it was resource pressure, but why are there days in between without issue?