Process.WaitForExit（）/ StandardOutputデッドロック状態を解除する

Question

私はこのコードdeadlock conditionについて読んだことがあります。私が理解していないのは、このコードが過去12年間Windows Server 2003（.net 2.0）上で動作していたことです。今は常にデッドロックのあるWindows Server 2012に移行しようとしています。

私のDLLは "anyCPU"（まだ.net 2.0をターゲットにしています）用にビルドされていますが、実行可能なプロセスは絶対に32ビットで、Server 2003からServer 2012への移行は32ビットから64ビットになります。 。

私はこの問題を解決するために何をすべきかを理解していると思いますが、この動作がServer 2003からServer 2012に変更された理由を知っていますか？

public string DoMyProcess(string filenameAndPath, string arguments) 
{ 
    string stdout=""; 
    int exitCode = 0;    

    try 
    {    
     ProcessStartInfo procStartInfo = new ProcessStartInfo(); 
     procStartInfo.FileName = filenameAndPath; 
     procStartInfo.CreateNoWindow = true; 
     procStartInfo.Arguments = arguments;    
     procStartInfo.RedirectStandardOutput = true; 
     procStartInfo.UseShellExecute = false; 

     System.Diagnostics.Process theProcess = null; 
     try 
     { 
      theProcess = Process.Start(procStartInfo); 
      theProcess.WaitForExit(); 

      exitCode = theProcess.ExitCode; 

      // moving this ABOVE WaitForExit should eliminate deadlocks 
      // But why did it always work on Server 2003 but not on Server 2012? 
      stdout = theProcess.StandardOutput.ReadToEnd(); 

     } 
     catch (System.Exception e) 
     { 
      string errMsg = e.Message; 
      log_the_error("threw an exception: " + e.Message); 
     }     
    }   

    return stdout; 
} 

UPDATE：

ミステリーデッドロックがまだでも推奨されているように上記のコードを変更した後に、存在する：

 try 
     { 
      theProcess = Process.Start(procStartInfo); 
      stdout = theProcess.StandardOutput.ReadToEnd();      
     } 
     catch (System.Exception e) 
     { 
      string errMsg = e.Message; 
      log_the_error("threw an exception: " + e.Message); 
     }     
    }   

そのデッドロックが発生する可能性があり、他にどのような条件？もし私がStandardErrorを調べるとすれば、それは有用なものを明らかにするだろうか？

UPDATE＃2：

FWIW、私たちは時折と（このコードは、12年間で走ったオリジナルマシン構成したIIS 6を実行している別のWindows Server 2003（32ビット）を、プロビジョニングされていますデッドロック）。サーバー2012でデッドロックされた同じコードIIS 8はこのサーバー2003でデッドロックしません。

ここでは、問題を再現する独自の完全なコードを用意しました。しかし、私たちがライセンスを取得した.exeは、このプロセスによって実行されており、私たちの投稿を妨げる守秘義務条項を持っています。私はそれが専門家をここで助けてくれないことに気づきます。

実際のサーバーにインストールされているVisual Studio 2013デバッガー経由で実行すると、プロセスがデッドロック/ハングすることはなく、サーバーの外にあるブラウザーからプロセスを呼び出すことができます。そして、奇妙なことに、2012年のサーバー上のブラウザからは、そのテストページに接続できません。ブラウザは単に「接続する」と言いますが、最終的にタイムアウトします（ただし、同じサーバーでホストされている他のサイト/同じIIS 8に到達できます

管理コマンドシェルまたは管理者以外のコマンドシェルから手動で実行されるのと同じコマンドラインパラメータが完全に機能するため、これは64ビット/ WOW64の問題とは考えにくい32ビットの実行可能ファイルまたは必要なDLLです。権限が問題を引き起こしている可能性のある場所を探し続けます（プロセスは一時的なフォルダに書き込む必要がありますが、これはc：\ tempに配置されています）。

Answer 1

いいえMinimal, Complete, and Verifiable code exampleがなければ、完全に答えることはできません。

私はあなたのコードは常に壊れていて、常にデッドロックの可能性があることを伝えます。プロセスからプロセスが終了するまで何かを読み取ることができませんが、バッファがプロセスをいっぱいにしてブロックする標準出力に大量のデータを書き込む場合、プロセスは終了できません。

何も再コンパイルしていないのに、デッドロックが発生していないときに見つかった場合は、開始するプロセスがこれまでよりもstdoutに書き込む可能性が高いと考えられます。私。以前はすべての出力がバッファに収まっていましたが、現在は出力されていません。 （私は、新しいOSでバッファサイズが縮小されている可能性もあると思うが、そうは思わない。）

あなたが先に行くとReadToEnd()への呼び出しを移動する必要があります。実際には、WaitForExit()を削除する必要があります。 ReadToEnd()に電話している場合は、プロセスが実際に終了するまで完了しないため、後でWaitForExit()を呼び出すことは意味がありません。