Server execution failed
You haven't shown much research, you should always look in the Windows application event log to get more details about this. I'll just assume you are suffering from the typical problem with using Excel from a .NET program.
This error description is always accurate, COM can literally not start Excel.exe. This is almost always because the operating is flat out of resources, the kernel memory pool is usually the one that runs out. You can typically see why by starting Task Manager (hopefully it still works), and look at the Processes tab. Good odds that you'll see dozens of copies of Excel.exe running. If you can't get Task Manager started then keep an eye on the list when you restart your app.
Excel is a "fat" process, it uses many operating system resources. It was really written for desktop use, only one instance of Excel.exe would be running. Even if you start it up again, the 2nd instance starts and notices that another instance is already running. It talks to the 1st one and ask it to do what you meant it to do, like opening another document. And quits, leaving only the 1st running. This same mechanism is not in place when you use COM. Not without you taking care of it yourself by only ever creating one instance and have it do all the work.
There's a good reasons why these Excel.exe instances don't quit when you stop using them. You have a problem with garbage collection in your program. The collector doesn't run often enough. It is easy to get into this kind of trouble, you'd typically have Excel doing all the heavy lifting and don't yourself ever allocate enough objects to get the garbage collector to run.
That spells trouble, Excel can only quit when its interface instance get garbage collected. Memory management is very different in a COM interop scenario, it is reference counted. When you start using an interface, like Application, then the reference count goes up. It goes down when the finalizer runs. Which will not happen until after a garbage collection.
Many programmers work around this problem by calling Marshal.ReleaseComObject() to force the reference count to go down. Many of those programmers also get in trouble with this, it won't work unless you call it for every interface reference. Are there are some that are not visible in a program.
The best way to do this is by triggering a garbage collection forcibly after you are done using Excel. Set any interface reference to null and call GC.Collect() + GC.WaitForPendingFinalizers(). Be sure to test this for the Release build without a debugger attached. And be sure to do it in a method that is separate from the method that uses the Excel interfaces. Task Manager tells you whether you're ahead.
It is still a bad idea to run Excel on a server, but if this approach works for you then you'll have some breathing room.