Manipulação na API de criação de perfil de exceções

As notificações de exceção são mais difíceis de todas as notificações de descrever e compreender. Este tópico descreve o processamento de exceção e explica como a API de criação de perfil trata vários tipos de exceções.

Fluxograma de notificação de exceção

Processamento de exceção é inerentemente complexo. As notificações de exceção descritas neste tópico fornecem todas as informações que requer um criador de perfil sofisticado para acompanhar a passagem (fase de Pesquisar ou desenrolar fase), o quadro, a filtere o finally bloco é executado para cada thread no processo de perfil. Notificações de exceção não fornecem nenhum ThreadIDs, mas você pode chamar o ICorProfilerInfo::GetCurrentThreadID método para descobrir qual thread gerenciado lançou a exceção.

A ilustração a seguir mostra como o criador de perfil de código recebe vários retornos de chamada quando ele monitora eventos de exceção. Cada segmento começa no estado de execução normal. Quando o thread está em um estado dentro do sistema de exceção (na Pesquisar da fase ou desenrolar fase), ela é controlada pelo sistema de exceção. Os retornos de chamada não relacionados à exceção (por exemplo, ICorProfilerCallback::ObjectAllocated) que ocorrem enquanto o thread está em um desses estados podem ser atribuídos ao próprio sistema de exceção. Quando o thread está em um estado fora do sistema de exceção, ele está em execução arbitrário de código gerenciado.

Sequência de retorno de chamada de exceções

Exceções aninhadas

Segmentos que tenham ultrapassado em código gerenciado durante o processamento de exceção podem lançar outra exceção, o que resultaria em uma nova passagem de tratamento de exceção. (Essa nova passagem é indicada por "Passagem de manipulação de exceção nova" na ilustração anterior.) Se uma exceção aninhada elimina o filter/finally/catch blocos de exceção original, esse pode afetam a exceção original sistema autônomo segue:

• Se ocorreu a exceção aninhada dentro de um filter bloco e sai do filter bloco, o filter serão consideradas para retornar false e continuará a primeira passagem.

• Se ocorreu a exceção aninhada dentro de um finally bloco e sai do finally bloquear a exceção original processamento nunca será reiniciada.

• Se ocorreu a exceção aninhada dentro de um catch bloco e sai do catch bloquear a exceção original processamento nunca será reiniciada.

Manipuladores não gerenciados

Uma exceção pode ser manipulada em código não gerenciado. Nesse caso, o criador de perfil verá a fase de desenrolamento, mas não receberão a notificação de catch manipuladores. Execução apenas continuará normalmente em código não gerenciado. Um criador de perfil de reconhecimento de código não gerenciado será capaz de detectar essa situação, mas um criador de perfil gerenciados somente poderá várias coisas, incluindo, mas não se limitando à seguinte:

• An ICorProfilerCallback::UnmanagedToManagedTransition retorno de chamada quando o código não gerenciado chama ou retorna ao código gerenciado.

• Rescisão de thread (se o código não gerenciado na raiz do segmento).

• Encerramento de aplicativo (se o código não gerenciado encerra o aplicativo).

Manipuladores CLR

Uma exceção pode ser manipulada pelo Common linguagem tempo de execução (CLR) propriamente dito. Nesse caso, o criador de perfil verá a fase de desenrolamento, mas não receberão a notificação de catch manipuladores. Ele pode ver a execução continuar normalmente no código gerenciado ou.

Exceções Não Tratadas

Por padrão, uma exceção sem tratamento levará para processar o encerramento do .NET estrutura versão 2.0. Você pode forçar a conformidade com a diretiva de exceção do .NET estrutura versão 1, usando um sinalizar de compatibilidade de aplicativo, sistema autônomo descrito em Exceções em threads gerenciados.

Consulte também

Outros recursos

Conceitos chave na API de criação de perfil

Visão geral de criação de perfil