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

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    });

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.