O processo líquido waitforexit trava

o registro de walter.
. Escrevendo enquanto aprende.
Sexta-feira, 18 de novembro de 2011.
Process. WaitForExit (Int32) bloqueia o problema.
Como você pode ver, o código inicia um processo "cmd. exe" e passa para ele o comando que eu quero ser executado.
No código eu usei o comando ping - t 8.8.8.8 que, por causa da opção - t, pings o host sem parar. O que acontece? O processo "cmd. exe" juntamente com o comando ping - t nunca sai e nunca fecha o fluxo de stdout e, portanto, o nosso código trava no Output = process. StandardOutput. ReadToEnd (); linha, porque não pode ter sucesso em ler todo o fluxo.
O mesmo acontece também se um comando em um arquivo em lotes trava por qualquer motivo e, portanto, o código acima pode funcionar continuamente por anos e, em seguida, pendure de repente sem nenhum motivo aparente.
você pode enfrentar um impasse se o comando que você atribui a "cmd. exe" ou o processo que você está chamando preenche a saída padrão ou erro padrão. Isso porque nosso código não pode alcançar as linhas.
Na verdade, o processo filho (o comando ping ou um arquivo em lote ou o processo que estiver executando) não pode continuar se o nosso programa não ler os buffers preenchidos dos fluxos e isso não pode acontecer porque o código está pendurado na linha com o processo. WaitForExit () que aguardará para sempre que o projeto filho saia.
O tamanho padrão de ambos os fluxos é de 4096 bytes. Você pode testar esses dois tamanhos com esses arquivos em lote:

processo waitforexit trava
Obter através da App Store Leia esta publicação em nosso aplicativo!
process. WaitForExit () de forma assíncrona.
Quero aguardar um processo para terminar, mas process. WaitForExit () trava minha GUI. Existe uma maneira baseada em eventos, ou eu preciso gerar um segmento para bloquear até sair, depois delegar o evento eu mesmo?
A partir de 4.0 / C # 5, é melhor representar isso usando o padrão assíncrono.
Se você escolher a resposta do MgSam, esteja ciente, se você passar por WaitForExitAsync algum CancelamentoToken, que será automaticamente cancelado após o atraso especificado, você pode obter uma InvalidOperationException. Para corrigir isso, você precisa mudar.
P. S .: não esqueça de dispor o seu CancelamentoTokenSource no tempo.
De acordo com este link, o método WaitForExit () é usado para fazer o thread atual aguardar até o processo associado terminar. No entanto, o processo possui um evento Exitado ao qual você pode se conectar.

Exemplo de uso.
Resolvi assim:
Eu redirecionava a entrada, a saída e o erro e administrai a leitura dos fluxos de saída e erro. Esta solução funciona para o SDK 7- 8.1, tanto para o Windows 7 como para o Windows 8.
Eu tentei fazer uma aula que resolva seu problema usando a leitura de fluxo assíncrono, levando em conta Mark Byers, Rob, Stevejay responde. Ao fazê-lo, percebi que existe um erro relacionado à leitura assíncrona do fluxo de saída do processo.
Você não pode fazer isso:
Você receberá System. InvalidOperationException: StandardOut não foi redirecionado ou o processo ainda não começou.
Então, você deve iniciar a saída assíncrona lida após o processo ser iniciado:
Fazendo isso, faça uma condição de corrida porque o fluxo de saída pode receber dados antes de configurá-lo como assíncrono:
Então algumas pessoas podem dizer que você só precisa ler o fluxo antes de configurá-lo como assíncrono. Mas o mesmo problema ocorre. Haverá uma condição de corrida entre a leitura síncrona e configurará o fluxo em modo assíncrono.
Não há como conseguir uma leitura assíncrona segura de um fluxo de saída de um processo na forma real "Processo" e "ProcessStartInfo" foi projetado.
Você provavelmente está melhor usando a leitura assíncrona, como sugerido por outros usuários para o seu caso. Mas você deve estar ciente de que você pode perder algumas informações devido à condição de corrida.
Nenhuma das respostas acima está fazendo o trabalho.
A solução Rob trava e a solução 'Mark Byers' obtém a exceção descarta. (Eu tentei as "soluções" das outras respostas).
Então eu decidi sugerir outra solução:
Este código é depurado e funciona perfeitamente.
Eu acho que isso é uma abordagem simples e melhor (não precisamos do AutoResetEvent):
Eu estava tendo o mesmo problema, mas a razão era diferente. No entanto, isso aconteceria no Windows 8, mas não no Windows 7. A seguinte linha parece ter causado o problema.
A solução era NÃO desativar UseShellExecute. Agora recebi uma janela popup do Shell, que é indesejável, mas muito melhor do que o programa esperando que nada de particular aconteça. Então eu adicionei o seguinte trabalho para isso:
Agora, o único problema que me incomoda é o porquê isso está acontecendo no Windows 8, em primeiro lugar.
Introdução.
A resposta atualmente aceita não funciona (lança exceção) e há muitas soluções alternativas, mas nenhum código completo. Isso é, obviamente, desperdiçando muito tempo das pessoas porque esta é uma questão popular.
Combinando a resposta de Mark Byers e a resposta de Karol Tyl, escrevi um código completo baseado em como eu quero usar o método Process. Start.
Eu usei-o para criar um diálogo de progresso em torno dos comandos git. É assim que eu usei isso:
Em teoria, você também pode combinar stdout e stderr, mas não testei isso.
Eu sei que isso é velho, mas, depois de ler toda essa página, nenhuma das soluções estava funcionando para mim, embora eu não tentei Muhammad Rehan porque o código era um pouco difícil de seguir, embora eu acho que ele estava no caminho certo . Quando eu digo que não funcionou, isso não é inteiramente verdade, às vezes funcionaria bem, acho que é algo a ver com a duração da saída antes de uma marca EOF.
De qualquer forma, a solução que funcionou para mim era usar diferentes threads para ler o StandardOutput e StandardError e escrever as mensagens.
Espero que isso ajude alguém, que pensou que isso poderia ser tão difícil!
As outras soluções (incluindo o EM0) ainda estão bloqueadas para o meu aplicativo, devido a tempos de espera internos e ao uso de StandardOutput e StandardError pela aplicação gerada. Aqui está o que funcionou para mim:
Editar: inicialização adicionada de StartInfo para codificar a amostra.
Este post talvez esteja desactualizado, mas descobri a principal causa por que normalmente ele trava é devido ao excesso de pilha para o redirectStandardoutput ou se você tem redirectStandarderror.
Como os dados de saída ou os dados de erro são grandes, isso causará um tempo de espera, pois ele ainda está processando por tempo indefinido.

processo waitforexit trava
Obter através da App Store Leia esta publicação em nosso aplicativo!
Depuração do Visual Studio - System. Diagnostics. Process trava no WaitForExit.
No Console Application, Windows 10, Visual Studio 2015, 4.6 eu chamo método único no Main chamado TestProcess. Build mode Debug, se eu executar o aplicativo sem depurar, imprime o texto correto:
Pressione qualquer tecla para continuar . . .
Se eu executar o aplicativo com depuração, aguarda 3 segundos antes da impressão.
Erro falso falso falso '' ''
Esta é apenas a simplificação do problema real, este código é uma espinha dorsal de algum código complexo que também trava na versão sem depuração para md5sums. exe, mas funciona para alguns outros programas. O código Coplex também trava em var a = proc. WaitForExit (tempo limite); até o tempo limite como no exemplo em anexo. Por outro lado, esta simplificação funcionará na versão sem depurador. Além disso, todos esses problemas começaram com o Windows 10, no Windows 7, tudo funcionou bem.
[EDIT] Não consigo entender por que md5sums. exe causaria problemas e se eu usar algo mais, ou seja. FileName = "ping", Arguments = "localhost" tudo funciona conforme o esperado.
[EDIT2] Meu programa complexo parou de funcionar no Windows 10 (Release - Run without debugging), mas esse exemplo também trava no Windows 7 (Debug - Run with debugging)
Houve 3 capturas para resolver isso:
md5sums. exe em alguns casos interrompe a execução após o término quando iniciado com as minhas configurações:
Pressione ENTER para sair.
Isso pode ser observado se CreateNoWindow estiver configurado para false e stdout, o redirecionamento stderr será removido. Isso pode ser corrigido usando a opção - e: 'Sair imediatamente; não faça uma pausa antes de retornar '. Isso solucionará todos os casos. Mas, como não usei, eu tinha comportamento inconsistente, dependendo do depurador e da versão do Windows.
Quando executado sem a pausa de depuração não foi disparado, embora todas as configurações fossem as mesmas e "Pressione ENTER para sair" não estava em saída. Mas correr com a depuração causou uma pausa para bloquear o programa até o tempo limite, onde md5sums iria pendurar no gerenciador de tarefas à espera de Enter. No modo de lançamento, execute sem depuração, embora a pausa seja disparada e "Pressione ENTER para sair" estava em saída no Windows 7 md5sums retornados e a execução continuou sem bloquear e pressionando o tempo limite. Este não era o caso no Windows 10, onde os md5sums viviam no time manager esperando por Enter e o programa continuasse após o tempo limite.