Process spawned through Process.Start in .NET hangs the thread

Question

Our application has a background thread which spawns a process through System.Diagnostics.Process:

Process.Start(
    new ProcessStartInfo
    {
        FileName = url,
        UseShellExecute = true
    }
);

This used to have no issues at all. But now, the background thread is silently dying; it never returns from the call to Process.Start. The catch block for this code, which handles System.Exception, is not getting reached either. Even if I enable handling exceptions when thrown in the Visual Studio debugger, I see no exceptions. Strangely, the process is getting spawned just fine; the default browser for the user is launched with the expected URL.

Our process's entry point is marked with [STAThread] as recommended.

What could be causing our thread to silently terminate? Are there any techniques I can use to debug what's happening during thread termination?

Update:

It looks like the thread is alive after all; it's just not returning from the call. Here's its stack trace:

• [In a sleep wait or join]
• System.dll!System.Diagnostics.ShellExecuteHelper.ShellExecuteOnSTAThread() + 0x63 bytes
• System.dll!System.Diagnostics.Process.StartWithShellExecuteEx(System.Diagnostics.ProcessStartInfo startInfo) + 0x19d bytes
• System.dll!System.Diagnostics.Process.Start() + 0x39 bytes
• System.dll!System.Diagnostics.Process.Start(System.Diagnostics.ProcessStartInfo startInfo) + 0x32 bytes
• My method

Update 2:

Launching cmd.exe without using the shell to execute works as a workaround. Thanks a bunch! However, I'd still like to know why the call isn't returning.

Update 3:

Shell hooks do sound like a logical explanation for what could be causing the call to not return. I couldn't find the rogue module, but after the last attempt to run things through shell execution, the call did return.

In any case, it's possible that users may have shell extensions loaded that could be messing with the process launching and causing my code to not return. We can't do anything about that, so the right answer is to use the workaround of launching a cmd.exe process.

Answer 1

As mentioned by Hans Passant, a hanging Process.Start call might be the reason. When using Process.Start with UseShellExecute set to true, the Windows API function ShellExecuteEx is called under the hood which might not return under certain circumstances.

You can check whether this is the case by adding trace messages to your code:

System.Diagnostics.Trace.WriteLine("About to start process.");
Process.Start(
   new ProcessStartInfo
   {
       FileName = url,
       UseShellExecute = true
   }
);
System.Diagnostics.Trace.WriteLine("Process started.");

To listen to the trace messages you can either use a TraceListener, check the output window of Visual Studio or use a tool such as DebugView.

As a workaround you may use the start command. The following code launches a hidden shell window which "starts" the url:

Process.Start(
    new ProcessStartInfo()
    {
        FileName = "cmd.exe",
        Arguments = "/c start http://www.google.com",
        WindowStyle = ProcessWindowStyle.Hidden,
        UseShellExecute = false
    });

Answer 2

Nah, threads don't silently terminate, they make a loud kaboom sound. At the very least you'll see the thread exit notification in the Output window. The Process.Start() method blocking would be another explanation, albeit that there's no explanation for it. You're snippet is far too short to come up with a decent diagnostic. Something environmental perhaps.

---

Your stack trace helps, ShellExecuteOnSTAThread() does in fact perform a blocking Thread.Join() on a little helper thread. This thread is necessary to call the native ShellExecuteEx() API function, it can only be called from an STA thread. It has a flaw though, an STA thread must also pump a message loop. This little helper doesn't.

That this causes a problem on your machine still points to an environmental problem, some kind of system add-on that hijacks the ShellExecuteEx() call. And counts on running a real STA thread. You should be able to find that helper thread back in the Debug + Windows + Threads window. It should contain "ShellExecuteFunction" on the stack. The kind of 'system add-on' that pulls stunts like this are virus scanners, for example. You should be able to find that alienware back in the Debug + Windows + Modules window after you checked the "Enable unmanaged debugging" in the project's Debugging tab.

The workaround to use UseShellExecute = false is quite acceptable here btw. Just the fact that your machine is kinda messed up, by the looks of it, isn't of course.