🚀 Running EXE from ASPX Web Service Fails After Hosting on IIS – Solved!

If you’ve ever tried to call a .exe file from an ASP.NET web service, you probably noticed something strange — it runs perfectly fine on your local system, but once deployed to IIS, it silently fails or throws connection errors.

That happened to me recently when I tried to execute a VB6 executable from an ASPX web service. Here’s how I diagnosed the issue and got it working on IIS.

---

🧩 Background

In my web app, I needed to trigger a VB6 EXE that performs SQL database updates. During development in Visual Studio, it worked exactly as expected.

Here’s the simplified code that starts the process:

ProcessStartInfo startInfo = new ProcessStartInfo();
startInfo.FileName = exePath;
startInfo.WorkingDirectory = basePath;
startInfo.WindowStyle = ProcessWindowStyle.Hidden;
startInfo.CreateNoWindow = true;
startInfo.UseShellExecute = false;
startInfo.RedirectStandardOutput = true;
startInfo.RedirectStandardError = true;

if (File.Exists(startInfo.FileName))
{
    using (Process process = Process.Start(startInfo))
    {
        // Optionally capture output
    }
}

Running locally, the executable connected to SQL Server, completed its task, and exited successfully.

---

⚠️ What Went Wrong on IIS

After deploying the same application to IIS, the EXE stopped working.
Instead, it produced a SQL connection error:

Run-time error ‘-2147467259 (80004005): [DBNETLIB] ConnectionOpen (Connect()). SQL Server does not exist or access denied.

Clearly, the issue was not with the web service itself — it occurred inside the EXE when trying to connect to the database.

---

🔍 Root Cause

After some digging, I realized what was happening:

1. When running locally, the web service (and thus the EXE) used my Windows account, which had full access to SQL Server.
2. When hosted in IIS, the web service ran under the Application Pool identity (e.g. IIS APPPOOL\MyApp or Network Service), which didn’t have:
   • Permission to run the EXE.
   • Access to SQL Server.
3. The runtime environment in IIS is completely different — no desktop interaction, limited file access, and restricted user rights.

So while Process.Start() worked, the executable itself failed when it tried to reach the database.

---

🧠 Solution That Worked

After several experiments, here’s what solved it for me:

✅ Step 1. Grant Proper Permissions

First, I gave Read & Execute permissions on the EXE file to Everyone.
You can later restrict it to the specific App Pool user, once confirmed working.

✅ Step 2. Adjust ProcessStartInfo

Next, I enabled shell execution and specified the runas verb to elevate execution:

ProcessStartInfo psi = new ProcessStartInfo();
psi.FileName = exePath;
psi.WorkingDirectory = basePath;
psi.Verb = "runas";                // run with elevated privileges
psi.UseShellExecute = true;        // required when using Verb
psi.WindowStyle = ProcessWindowStyle.Hidden;

Process.Start(psi);

This combination ensured the EXE had enough permission to access external resources like SQL Server.

✅ Step 3. Verify SQL Access

Lastly, I tested SQL connectivity under the same user that IIS runs with.
You can either:

• Switch to SQL Authentication (with username/password), or
• Grant the IIS App Pool identity access to your database.

Once I did that, everything started working — both locally and on the live server.

---

🔒 Important Notes

• Avoid giving “Full Control” to Everyone permanently — it’s okay for testing but insecure for production.
• For a safer setup, assign permissions only to the Application Pool identity (visible under Advanced Settings → Identity).
• If you frequently need to run system-level executables, consider a Windows Service or background worker instead of calling .exe directly from IIS.

---

🧭 Lessons Learned

• IIS runs your application under a different user context than your development machine.
• Always verify file permissions, database rights, and network access for that account.
• Using UseShellExecute = true is often necessary when calling external processes that depend on user-level permissions.
• Migrating legacy VB6 or native EXEs to a .NET background service can simplify deployment and improve reliability.

---

💬 Final Thoughts

After fixing permissions and adjusting ProcessStartInfo, my VB6 executable now runs smoothly when triggered from the web service — even under IIS.

Sometimes, the hardest bugs aren’t about code — they’re about context.
Understanding how IIS isolates user identities makes all the difference when dealing with external executables.

---

Author: Algolassi
Published on: October 9, 2025
Category: ASP.NET, IIS, Troubleshooting
Tags: asp.net, iis, vb6, process.start, sqlserver, algolassi