Erro ao criar identificador de janela / Error creating window handle

[Renan Henrique]

Galera, meu sistema está travando depois que eu abro e fecho algumas telas.

Da o erro: "Error creating window handle". "erro ao criar identificador de janela" e trava todo o sistema, não consigo abrir mais nenhuma tela.

O sistema é um ERP.

No meu computador e computadores mais forte, abro e fecho umas 50 vezes pra dar esse erro, mas em uma máquina com 1 giga de ram, mais fraquinha, na décima vez mais ou menos acontece o erro, cliente ta ficando doido comigo, rs..

Já tentei de tudo, tentei nas telas pais, filhas, quando da closed, fazer um for nos controls dando um dispose, colocando null nas variáveis, chamando o GC.Collect, etc, etc, fiz várias tentativas e nada.

Toda vez que eu abro e fecho uma tela, e acompanho no gerenciador de tarefas, ele aumenta os "objects user" aumenta uns 30 quando eu abro a tela e depois que fecho, diminui uns 25, sempre sobra uns 5, 10...

Memória também, só vai aumentando.

Baixei um programa para liberar memória, liberou, mas também não adiantou, logo da o erro... Então creio que o problema não seja exatamente a memória.

[Matheus Lima]

Use um profiler. Ele vai dizer que ponto do código gera o problema. Mas assim, esse problema está relacionado a recursos que são alocados mas não são desalocados pelos seus Forms. MAs enfim, sem um profiler não dá para descobrir o que é o problema.

--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br
---
Você está recebendo esta mensagem porque se inscreveu no grupo ".Net Architects" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para dotnetarchitec...@googlegroups.com.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.

--

Matheus Lima
Desenvolvedor de Software - ViaSoluti

Graduando em Engenharia de Teleinformática - UFC

[Renan Henrique]

Indica algum profiler? 

Renan Henrique
Analista Desenvolvedor .Net/SQL

MCTS - Microsoft Certified Technology Specialist
GTalk - MSN: rena...@gmail.com 

[Matheus Lima]

as versões pagas do visual studio possuem um profiler integrado muito bom. Vai em analyze --> profile e dá uma olhada nas opções.

[Eric Lemes]

Está com cara de vazamento de handles isso aí.

Sai criando janelas, componentes, etc e não está matando as instâncias ou seu código não libera handles alocados.

Possiveis causas: uso de componentes de terceiros mal escritos ou código com p/invoke não liberando handles.

--

[Renan Henrique]

Matheus, vou testar.

Eric, tirei os componentes de terceiros mas não mudou nada, na verdade único componente que usamos é bem famoso, "elegant ribbon"...

Vou dar uma analisada melhor nas coisas, to ficando doido já, rs...

Valeu pelas dicas..

[Eric Lemes]

Ligue o task manager, ou outro aplicativo de monitorar processos e acompanhe conforme vai operando sua aplicação o número de handles (traduzido no Windows portugues como manipuladores se não me engano).

Se o número só cresce, mesmo quando você fecha janelas, está " vazando" handles.

O duro é que quase tudo no windows é um handle. Botão, janela, socket, mutex, arquivos.

Por isso é legal ter linguagem gerenciada. Os desenvolvedores pensam que recurso de máquina é infinito.

Depois dá uma olhada com carinho no comportamento da interface IDisposable no .Net. tem um post no meu blog que explica o que é e como funciona (também em relação ao GC).

Entendendo essas coisas direitinho vc provavelmente chegará à solução do seu problema.

Abraços

Eric

[Luciano Azevedo]

Bem, se serve de consolo, até o VS2010 pré SP1 teve esse problema. Vc não está sozinho! Hehe. agora achar o culpado é que vai ser f....

[ ]´s

Luciano Azevedo

[ ]'s

Luciano Azevedo

[Renan Henrique]

Passa o link que do uma olhada.

Já implementei uma classe dispose também e nada, rs...

Sim não para de aumentar, mesmo eu fechando...

Engraçado que tem uma tela que não herda nada, ela tem 4 textbox só, ela vaza um pouco também, mas é quase nada, mas vaza.

Luciano, eu vi mesmo na internet q muitas pessoas ja passaram por esse problema, e como era de se esperar, não tem uma receita de bolo pra resolver. Foda que não fui eu que desenvolvi o framework da empresa e entender tudo que ele faz, ta tenso..

Em 23 de agosto de 2013 20:02, Eric Lemes <eric...@gmail.com> escreveu:

[Luciano Azevedo]

Pra te ajudar esse monitor da sysinternals é bem bom. http://technet.microsoft.com/en-us/sysinternals//bb795533.aspx

[ ]'s

Luciano Azevedo

[Eric Lemes]

http://ericlemes.com/2011/06/09/gc/

[Mário Meyrelles]

Cuidado com o número de handlers: não pode passar de 10 mil por app. Deve ser um vazamento de handle mesmo.

Coloca o contador de handles do process explorer e analisa como é o comportamento da sua aplicação.

2013/8/23 Eric Lemes <eric...@gmail.com>

[Renan Henrique]

Parece que esses profilers só passa informações sobre o .exe.

Minha aplicação abre um exe e cada form é uma dll, parece que não carrega informações dessas dll.

To lendo esse artigo william.

Mário, passa sim de 10 mil as vezes, rs, cada form que abre aumenta uns 30 handler, e quando fecha diminui só uns 10.

Em 23 de agosto de 2013 21:54, Willian Lima <willian...@gmail.com> escreveu:

Da olhada neste link tem bastante informação e pode te dar um norte para o que fazer.

http://msdn.microsoft.com/pt-br/magazine/cc163528.aspx

Você disse que pelo task do Windows da para perceber a memória presa quando fecha o form.
Faça um teste com  ''GC.WaitForPendingFinalizers();''

Willian Lima
Analista de Sistemas
11 9 6148 6770
Sent from my device

[Eric Lemes]

Renan,

Esse é o conceito de processo. Vc tem um processo, se tem 5000 DLL's rodando lá dentro, é um processo só, que compartilham a mesma área de memória. Pode até ter divisões de App Domains (raramente usado), mas mesmo assim, é um processo só.

Você mesmo já deu a resposta. Se abre uns 30 e diminui uns 10, está ocorrendo vazamento. 

Só cuidado que o ideal para lidar com recursos gerenciados é implementar IDisposable, jogar o código que libera o recurso não gerenicado no Dispose, só que mesmo assim, é necessário ao construir essas classes que instanciam os recursos utilizar o "using" ou forçar a execução do Dispose na liberação.

Se você não fizer nenhum dos dois, o recurso somente será liberado quando o GC resolver passar e liberar a memória não usada, o que pode demorar um bom tempo. 

Tive um caso parecido recentemente e o recurso não gerenciado era só uma conexão de banco... rs. 

Abraço,

Eric

2013/8/24 Renan Henrique <rena...@gmail.com>

--

Abraço,

Eric

http://ericlemes.com

[danielzhe]

Tentei te ajudar na DotNet Brasil, mas os moderadores de lá são meio retardados e demoram dias pra liberar os posts, pq sou membro novo.
Então vou tentar te ajudar por aqui

Essas dlls, são externas ou você tem o código delas?

Eu nunca consegui usar o profiler do VS pra memória, pois fica lento pra cacete. Recomento do ANTS Profiler. Tem uma versão trial por 15 dias, totalmente funcional:
http://www.red-gate.com/products/dotnet-development/ants-memory-profiler/

E como te disse lá na outra lista, concordo com o colega: tá com jeito de handlers prendendo seus objetos.

Outra coisa importante, que tentei te responder lá, é que o Dispose() não faz mágica. É importante primeiro você analisar o que está alocando de memória e não porque ela não está sendo desalocada. Lembre-se que o Dispose() não libera os objetos na hora, ele apenas libera recursos não gerenciados (exemplo: Brushes, Streams, etc.). A limpeza de memória de fato é feita quando o GC achar que deve fazê-la.

[Luiz Carlos Faria]

Renan,

você está tentando gerenciar informações de UI em threads secundárias. Repense ou remova para garantir que o problema é esse mesmo. 

Reimplemente transitando mensagens ou sincronizando.

Tem alguns posts no google sobre isso.

[Gustavo Cruz]

Luiz,

Não existe problema nenhum em gerenciar informações de UI em threads que não sejam de UI.

Isso se resolve facilmente utilizando BeginInvoke(). Não digo que é uma boa prática, eu sempre separo as responsabilidades, mas no final das contas você sempre acaba tendo que sincronizar as threads.

Gustavo Figueiredo
.NET System Architect
+55 31 9253.5062

2013/8/28 Luiz Carlos Faria <luizcar...@gmail.com>

[Renan Henrique]

Verifiquei que um dos componente que criamos, ele tem uma imagem, quando retira essa imagem o vazamento não ocorre, como liberar os handlers desse componente? 

É um button com uma imagem de calendário como background.

[Renan Henrique]

vou fazer a implementação da interface idisposable agora, vamos ver.

fiquei um tempo sem trabalhar com isso, estava com outras prioridade.