Debugando aplicações ASP.NET: Descobrindo Exceptions (Level 100)

Novembro 29, 2006 at 1:01 am Deixe um comentário

Quando criamos uma aplicação ASP.NET localmente, é extremamente simples descobrirmos quando uma exceção é lançada. Mais simples ainda é descobrir onde e o porquê desta exceção.

Agora imagine este contexto: você termina o projeto e depois de toda aquela fase de testes, verificações, etc, o projeto é instalado no servidor de produção. De repente você começa a receber reclamações de lentidão, e não tem a mínima idéia do que pode ser. Um dos pontos a se analisar é o contador de performance, para verificar onde há problema.

Hoje vou falar especificamente sobre como verificar uma exceção lançada pela aplicação utilizando a ferramente WinDbg.

Um caso relatado recentemente nos fala que uma aplicação, depois que entrou em produção, começou a gerar exceções. Para ser mais exato, lançou 40.000 (verificado com o contador de performance .NET Exceptions). Isto ocorria porque quando um problema acontecia, era gravado um log em banco de dados. O que não era esperado era que este banco de dados (a conexão) estivesse errado, o que tentava novamente gravar o log.

Vou exemplificar o que foi utilizado para descobrir a fonte do problema, utilizando WinDbg. Para um start, recomendo o este blog (neste post não vou explicar como instalar, o que significa cada objeto – estou escrevendo um outro post para isso).

Neste exemplo, resolvi verificar o número de exceções lançadas pela aplicação. Foi constatado que o número não é excessivo, mas sempre é uma boa prática verificar a origem destes erros. Para isso, resolvi dar um “Attach to Process” (File – Attach to a Process) no w3wp.exe.

Como segundo passo básico, é necessário carregar a DLL sos.dll, que para .NET 2.0 deve ser carregado em %.NETFramewordDir%\sos.dll:

0:000> .load C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\sos.dll

 Agora o objetivo disto tudo é verificar quando uma exceção da aplicação acontece. Para isso, vamos executar um comando que irá parar o WinDbg quando qualquer exceção do CLR for lançada:

0:000> sxe CLR

O comando sxe (Set Exception), irá para imediatamente quando uma exceção ocorrer, antes de seu tratamento. Isto é chamado de First Chance Handling. Execute este comando e depois comece a debugar, digitando “g” e <Enter>:

0:000> sxe CLR
0:000> g

Agora o debugger irá parar quando qualquer exceção for lançada.
Provavelmente você verá algo como o texto abaixo, quando isto acontecer:

(1328.828): CLR exception – code e0434f4d (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
(…)

Agora, o que fazer com esta informação? O que queremos é identificar quem lançou esta exceção, e se possível qual a mensagem.
Para identificarmos qual exceção foi lançada, devemos executar o comando !PrintException (ou !pe):

0:016> !pe
Exception object: 0262664c
Exception type: System.Threading.ThreadAbortException
Message: Thread was being aborted.
InnerException: <none>
StackTrace (generated):
<none>
StackTraceString: <none>
HResult: 80131530

Agora conseguimos identificar o tipo de exceção lançada, a mensagem de retorno e o objeto da exceção. Devemos agora verificar onde a aplicação estava quando a exceção aconteceu, através do comando !clrstack:

0:016> !clrstack
OS Thread Id: 0x828 (16)
ESP EIP
019cf31c 77e55e02 [HelperMethodFrame_1OBJ: 019cf31c] System.Threading.Thread.AbortInternal()
019cf374 793d7e50 System.Threading.Thread.Abort(System.Object)
019cf388 65ffff2c System.Web.HttpResponse.End()
019cf39c 65ffee5b System.Web.HttpResponse.Redirect(System.String, Boolean)
019cf3b0 65ffec7f System.Web.HttpResponse.Redirect(System.String)
019cf3b4 09a53b30 ExtraCommerceSite.ExtraSiteLayout.OnLoad(System.EventArgs)
(…)

Com o resultado do comando !pe, identificamos que o tipo de exceção é do tipo ThreadAbortException. Com o comando !clrstack, podemos verificar que o comando que está gerando a exceção está sendo executado dentro do método OnLoad, na classe ExtraSiteLayout. Foi executado um Response.Redirect que gerou a exceção (de cima para baixo, a pilha de execução da aplicação).

Para continuar a verificação de exceções, utilize o comando gn.

Este pequeno e rápido post foi para demonstrar como a ferramenta WinDbg pode ser poderosa. Este exemplo foi extremamente simples, mas espero ter dado uma idéia do que virá por aí, relacionado a Debugging.

Anúncios

Entry filed under: .NET.

Ordering Commerce 2007 Search Results IE6 e IE7 na mesma máquina

Deixe uma Resposta

Preencha os seus detalhes abaixo ou clique num ícone para iniciar sessão:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão / Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão / Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão / Alterar )

Google+ photo

Está a comentar usando a sua conta Google+ Terminar Sessão / Alterar )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed


Calendário

Novembro 2006
S T Q Q S S D
    Dez »
 12345
6789101112
13141516171819
20212223242526
27282930  

Most Recent Posts


%d bloggers like this: