Visão geral de depuração do CLR
O common language runtime (CLR) API de depuração permite que os fornecedores de ferramentas escrever os depuradores para depurar aplicativos executados no ambiente CLR. O código a ser depurado pode ser qualquer tipo de código que suporta do CLR.
API de depuração CLR é implementado principalmente com código não gerenciado. Portanto, a API de depuração é apresentada como um conjunto de interfaces de modelo de objeto componente (COM). A API consiste em:
Uma coleção de objetos COM e interfaces que são implementadas pelo CLR.
Uma coleção de interfaces de retorno de chamada COM que deve ser implementada pelo depurador.
Esta visão geral contém as seções a seguir:
Cenários de depuração do CLR
Categorias da API
Anexando a ou iniciar um programa.
Controlando a Execução
Examinando o estado do programa
Modificando o estado do programa
Usando o editar e continuar
Avaliação de funções
A injeção de código dinamicamente
Ambientes compatíveis
Tópicos relacionados
Cenários de depuração do CLR
As seções a seguir descrevem como o common language runtime debugging API trata a cenários típicos de depuração. Observe que o runtime oferece suporte a alguns cenários diretamente e interopera com os métodos atuais para oferecer suporte a outras pessoas.
Depuração de fora do processo
Na depuração de fora do processo, o depurador está em um processo separado do processo que está sendo depurado (isto é, está fora o debuggee). Esse cenário reduz as interações entre o depurador e o depurado. Portanto, permite que um quadro mais preciso do processo.
API de depuração CLR oferece suporte a depuração diretamente fora de processo. A API trata todas as comunicações entre o depurador gerenciadas partes e do elemento a ser depurado para oferecer suporte à depuração de código gerenciado.
Embora a API de depuração CLR é usada fora de processo, parte da lógica de depuração (por exemplo, a sincronização de thread) ocorre em processo com o depurado. Na maioria dos casos, isso é um detalhe de implementação deve ser transparente para o depurador. Para obter mais informações sobre sincronização de threads, consulte Arquitetura de depuração do CLR. Uma desvantagem é que a API de depuração não pode ser usada para inspecionar os despejos de memória quando ele é usada fora de processo.
No processo de depuração
No.NET Framework versão 1.0 e 1.1, o CLR API de depuração com suporte limitado no processo de depuração, no qual um gerador de perfil poderia usar os recursos de inspeção da API de depuração. No .NET Framework 2.0, no processo de depuração foi substituído por um conjunto de funcionalidades que são mais consistente com a API de criação de perfil. Para obter mais informações sobre essas alterações, consulte o instantâneo da pilha e a inspeção de objeto recursos da Visão geral de criação de perfil.
Depuração remota do processo
No processo remoto de depuração, a interface do usuário do depurador é em um computador separado do processo que está sendo depurado. Esse cenário pode ser útil se o depurador interferir com o depurado quando eles estiverem em execução no mesmo computador. A interferência pode ser causada pelo seguinte:
Recursos limitados.
Dependências de local.
Bugs que interferem com o sistema operacional.
API de depuração CLR não dá suporte a depuração diretamente de processo remoto. Um depurador que se baseia na API de depuração CLR ainda deve existir fora de processo do elemento a ser depurado. Portanto, essa solução requer um processo de proxy no computador que possui o depurado.
Depuração de código não gerenciado
Código gerenciado e código não gerenciado freqüentemente coexistam no mesmo processo. A depuração simultânea de ambos os tipos de código é uma necessidade comum.
Percorrendo os limites entre código gerenciado e oferece suporte à API de depuração CLR, mas ele não oferece suporte direto a depuração de código não gerenciado. No entanto, o CLR API de depuração pode coexistir com um depurador de código não gerenciado compartilhando os recursos de depuração do Win32.
Além disso, a API de depuração CLR fornece duas opções para um processo de depuração:
A anexe o soft opção na qual apenas as partes gerenciadas do processo são depuradas. Um depurador soft-anexado a um processo pode subseqüentemente desanexar do processo.
A rígidos anexar opção em que tanto as gerenciados e partes de um processo são depuradas, e todos os eventos de depuração do Win32 são expostos por meio da API de depuração.
Ambientes mistos de idioma
No software de componente, os diferentes componentes podem ser criadas com idiomas diferentes. Um depurador deve compreender as diferenças de linguagem para que ele possa exibir dados no formato correto, avaliam expressões com a sintaxe correta e assim por diante.
API de depuração CLR não fornece qualquer suporte direto para ambientes de idioma misto, pois o CLR tem nenhum conceito de idioma de origem. Instalações de mapeamento de fonte existente do depurador deve ativá-lo mapear de uma determinada função para o idioma no qual a função foi implementada.
Vários processos e programas distribuídos
Um programa do componente pode incluir componentes de cooperação que são executados em processos diferentes ou mesmo em diferentes computadores em uma rede. Um depurador deve ser capaz de lógica de execução de rastreamento entre os processos e os computadores para fornecer que uma visão lógica do que está acontecendo.
API de depuração CLR não fornece qualquer suporte direto para depuração de vários processos. Novamente, um depurador que está usando a API deve oferecer esse suporte diretamente, e os métodos existentes para fazer isso devem continuar a trabalhar.
Voltar ao topo
Categorias da API
A API de depuração inclui os seguintes grupos de três das interfaces, tudo o que normalmente usado por um depurador CLR e todas implementadas como código não gerenciado:
Interfaces que oferecem suporte a depuração de aplicativos do CLR.
Interfaces que fornecem acesso a simbólico de informações, que são normalmente armazenadas em arquivos de banco de dados (PDB) do programa de depuração.
Interfaces que oferecem suporte à consulta de processos e domínios de aplicativo em um computador.
A API de depuração depende de dois conjuntos adicionais de interfaces:
API de metadados para lidar com a inspeção de informações de programa estáticos como, por exemplo, classes e as informações sobre o tipo de método.
API de armazenamento de símbolo para oferecer suporte a depuração de nível de origem para os depuradores de código gerenciado.
As interfaces de depuração também podem ser organizadas nas categorias funcionais mostradas na tabela a seguir.
Categoria de API |
Descrição |
|---|---|
Registro |
Interfaces que o depurador chama para registrar com o CLR e solicitar uma notificação quando ocorrem eventos específicos. |
Notificação |
Interfaces de retorno de chamada que o CLR usa para notificar o depurador de vários eventos e para retornar as informações solicitadas. Essas interfaces devem ser implementadas pelo depurador. |
Ponto de interrupção |
Interfaces que o depurador chama para recuperar informações sobre pontos de interrupção. |
Execução |
Interfaces que o depurador chama para controlar a execução de um elemento a ser depurado e pilhas de chamadas de acesso. |
Informações |
Interfaces que o depurador chama para obter informações sobre o depurado. |
Enumeração |
Interfaces que o depurador chama para enumerar os objetos. |
Modification |
Interfaces que o depurador chama para modificar o código que está sendo depurado. |
As seções a seguir descrevem a funcionalidade que o common language runtime (CLR) depuração de serviços fornece.
Voltar ao topo
Anexando a ou iniciar um programa.
O CLR permite que você anexe o depurador a um programa em execução ou iniciar um processo. Os serviços de depuração CLR suportam a depuração do just-in-time (JIT), permitindo que você anexar o depurador a um programa que lança uma exceção não tratada. No entanto, um programa que não está sendo executado no modo depurável pode ter menos informações de depuração disponíveis. Um programa pode ser sempre executado em modo depurável para evitar esse problema. Para obter mais informações sobre o modo depurável, consulte o seguinte:
Voltar ao topo
Controlando a Execução
Os serviços de depuração do CLR fornecem várias maneiras de controlar a execução de um programa. Elas incluem pontos de interrupção, depuração de passo único, notificação de exceção, a avaliação da função e outros eventos relacionados à inicialização e desligamento de um programa.
API de depuração CLR fornece controle de execução somente para código gerenciado. Se você deseja executar o controle de execução em código não gerenciado, você deve implementar essa funcionalidade separadamente no seu depurador.
Pontos de interrupção
Você pode criar pontos de interrupção, especificando o código e a Microsoft intermediate language (MSIL) ou o deslocamento nativo do local onde a quebra deve ocorrer. O depurador, em seguida, será notificado quando o ponto de interrupção é encontrado. A API de depuração não suporta diretamente os pontos de interrupção condicionais. No entanto, um depurador pode implementá-las, avaliando uma expressão em resposta a um ponto de interrupção e decidir se deve informar ao usuário da parada.
Revisão
Os serviços de depuração do CLR fornecem uma ampla variedade de funcionalidades de depuração. Um programa pode percorrer uma instrução de código em um momento (único-stepping) ou um intervalo de instruções ao mesmo tempo (- stepping intervalo). Ela pode ignorar, step into ou step out of uma função. Os serviços de depuração do CLR também podem notificar o depurador se ocorrer uma exceção, que interrompe a operação de revisão.
Embora os serviços de depuração não apóiam percorrendo o código não gerenciado, eles fornecerão retornos de chamada quando uma operação de revisão atinge o código não gerenciado, para entregar fora de controle para o depurador. Eles também fornecem funcionalidade que permite o depurador para determinar quando o código gerenciado está prestes a ser inseridos no código não gerenciado.
O CLR não fornece diretamente a revisão do nível de origem. Um depurador pode fornecer essa funcionalidade usando a revisão de intervalo juntamente com suas próprias informações de mapeamento de origem. Você pode usar as interfaces de armazenamento de símbolo para obter informações de origem. Para obter mais informações sobre essas interfaces, consulte O armazenamento de símbolo de diagnóstico (referência de API não gerenciada).
Exceções
Os serviços de depuração CLR permitem a um depurador a ser informado de exceções de primeira chance e a segunda chance em código gerenciado. O objeto lançado está disponível para inspeção em cada ponto.
O CLR não manipula exceções nativas em código não gerenciado, a menos que eles se propaguem para código gerenciado. No entanto, você ainda pode usar os serviços de depuração do Win32 que são compartilhados com os serviços de depuração do CLR para lidar com exceções não gerenciadas.
Eventos de programa
Os serviços de depuração CLR notificam um depurador quando ocorrem vários eventos de programa. Esses eventos incluem o processo de criação e sair, criação do thread e sair, criação de domínio do aplicativo e sair, assembly carregar e descarregar o módulo para carregar e descarregar e o carregamento e descarregamento de classe. Para garantir o bom desempenho, você pode desativar o carregamento de classe e descarregamento de eventos para um módulo. Por padrão, os eventos de classe para carregar e descarregar estão desativados.
Controle de segmento.
Os serviços de depuração CLR fornecem interfaces para suspender e retomar os threads (gerenciados) individuais.
Voltar ao topo
Examinando o estado do programa
Os serviços de depuração CLR fornecem uma maneira detalhada para inspecionar as partes de um processo que estão executando o código gerenciado quando o processo estiver em um estado parado. Um processo pode ser inspecionado para obter uma lista de segmentos físicos.
Um segmento pode ser examinado para inspecionar sua pilha de chamada. Pilha de chamadas do thread é decomposta em dois níveis: a cadeia de nível e no nível de quadro de pilha. Primeiro, a pilha de chamadas é decomposta em cadeias. Uma cadeia é um segmento de pilha de chamada contíguos de lógica. Ela contém tanto os quadros de pilha gerenciado ou não gerenciado, mas não ambos. Além disso, todos gerenciados chamada quadros em uma única cadeia compartilham o mesmo contexto CLR. Uma cadeia pode ser gerenciada ou não.
Cada cadeia gerenciada pode ser decomposta além em quadros de pilha única. Cada quadro de pilha representa uma chamada de método. Você pode consultar um quadro de pilha para obter o código que está sendo executado ou para obter seus argumentos, variáveis locais e registradores nativos.
Uma cadeia não gerenciada não contiver quadros de pilha. Em vez disso, ele fornece o intervalo de endereços de pilha alocados para código não gerenciado. Ele é um depurador de código não gerenciado para decodificar a parte não gerenciada da pilha e fornecer um rastreamento de pilha.
Observação
Serviços de depuração do CLR não suportam o conceito de variáveis locais que ocorrem no código-fonte.Ele é o depurador para mapear a variáveis locais para suas alocações.
Os serviços de depuração do CLR também fornecem acesso global, estática de classe e variáveis locais do thread.
Voltar ao topo
Modificando o estado do programa
Serviços de depuração CLR permite um depurador de alterar a localização física do ponteiro de instrução durante a execução, embora isso possa ser uma operação perigosa. O ponteiro de instrução pode ser alterado com êxito quando as seguintes condições forem verdadeiras:
O ponteiro de instrução atual e o ponteiro de instrução de destino estão em pontos de seqüência. Pontos de seqüência aproximadamente representam os limites de instrução.
O ponteiro de instrução de destino não está localizado em um filtro de exceção, uma catch bloco, ou um finally bloco.
O ponteiro de instrução atual está em um catch block e o ponteiro de instrução de destino não está localizado fora do catch bloco.
O ponteiro de instrução de destino está no mesmo quadro em que o ponteiro de instrução atual.
Quando a localização física do ponteiro de instrução é alterado, variáveis de local do ponteiro de instrução atual serão mapeadas para as variáveis no local do ponteiro de instrução de destino. Referências de coleta de lixo no local do ponteiro de instrução de destino serão inicializadas corretamente.
Depois que o ponteiro de instrução é alterado, os serviços de depuração CLR marcar qualquer informação armazenada em cache de pilha como inválido e atualizar as informações na próxima vez que for necessário. Depuradores ponteiros para informações de pilha como quadros e cadeias de cache devem atualizar essas informações após alterar o ponteiro de instrução.
O depurador também pode modificar os dados de um programa quando o programa é interrompido. O depurador pode alterar as variáveis locais e os argumentos de uma função quando a função está em execução, de maneira semelhante à inspeção. O depurador também pode atualizar campos de matrizes e objetos e também campos estáticos e variáveis globais.
Voltar ao topo
Usando o editar e continuar
Durante uma sessão de depuração, você pode usar o editar e continuar o recurso para fazer o seguinte:
Edite o código-fonte.
Recompile a fonte modificadas.
Preserve o resto do estado do tempo de execução do executável que está sendo depurado.
Continue a sessão de depuração sem ter que executar novamente o executável a partir do início.
Voltar ao topo
Avaliação de funções
Para avaliar expressões do usuário e propriedades dinâmicas de objetos, um depurador precisa de uma maneira de executar o código do processo que está sendo depurado. Os serviços de depuração CLR permitem que o depurador tornar uma função ou método de chamada e que ele seja executado dentro do processo de depuração.
O CLR permite que o depurador interromper essa operação, porque pode ser perigoso (por exemplo, ele pode disparar um deadlock com o código existente). Se a avaliação for interrompida com êxito, o segmento é tratado como se nunca tivesse ocorrido a avaliação, exceto para os efeitos colaterais em variáveis locais da avaliação parcial. Se a função chama código não gerenciado ou bloqueia de alguma maneira, talvez seja impossível finalizar a avaliação.
Quando a avaliação da função for concluída, o CLR usa um retorno de chamada para notificar o depurador se a avaliação concluída corretamente ou a função emitiu uma exceção. Você pode usar ICorDebugValue e ICorDebugValue2 métodos para inspecionar os resultados de uma avaliação.
O thread no qual a avaliação da função está ocorrer deve ser interrompido em código gerenciado em um ponto que é seguro para coleta de lixo. (Avaliação da função também é permitida para exceções não tratadas.) No código não otimizado, esses pontos de seguros são muito comuns; a maioria dos ponto de interrupção ou operações no nível da MSIL etapa serão concluída em um. No entanto, esses pontos podem ser raros no código otimizado. Às vezes, uma função inteira pode não ter quaisquer pontos de seguros. A freqüência de pontos que são seguros para coleta de lixo irá variar de função à função. Mesmo em código não otimizado, é possível não parar em um. No código otimizado ou não otimizado, o ICorDebugController::Stop método raramente cair em um ponto de seguro.
Serviços de depuração CLR irá configurar a uma nova cadeia no thread para iniciar a avaliação da função e chamar a função solicitada. Assim que a avaliação é iniciada, todos os aspectos da API de depuração estão disponíveis: controle de execução, inspeção, a avaliação da função e assim por diante. Avaliações aninhadas são suportadas e pontos de interrupção são tratados como de costume.
Voltar ao topo
A injeção de código dinamicamente
Alguns depuradores permitem que um usuário inserir instruções arbitrárias na imediata janela e execute as instruções. Os serviços de depuração do CLR, suporte para esse cenário. Dentro do motivo, não existem restrições em que o código que você pode injetar dinamicamente. (Por exemplo, não-local goto instruções não são permitidas.)
Injeção de código dinâmico é implementada usando uma combinação de operações de edição e continuação e avaliação da função. O código seja injetado é empacotado em uma função e injetado usando o Edit and Continue. A função injetada é avaliada. Se desejar, você pode fornecer ByRef argumentos para o wrapper de função para que o lado efeitos são imediata e permanentes.
Voltar ao topo
Ambientes compatíveis
Instalações de depuração CLR estão disponíveis em todos os processadores e sistemas operacionais que ofereça suporte o CLR, com as seguintes exceções:
Não há suporte para editar e continuar e depuração de modo misto em sistemas operacionais de 64 bits. O SetIP métodos (ICorDebugILFrame::SetIP e ICorDebugNativeFrame::SetIP) tem restrições adicionais em sistemas operacionais de 64 bits. A funcionalidade de restante é equivalente em todos os processadores (embora haja representações de dados específicos do processador como, por exemplo, os tamanhos de ponteiro, contextos de registro e assim por diante).
Não há suporte para editar e continuar e depuração de modo misto em sistemas operacionais baseados no Win9x. A funcionalidade restante deve ser equivalente em todos os sistemas operacionais. No entanto, existem algumas exceções específicas, que estão indicadas na documentação das funções individuais.
Voltar ao topo
Tópicos relacionados
Título |
Descrição |
|---|---|
Descreve como os diferentes componentes do CLR API de depuração interagem com o CLR e o depurador. |
|
Descreve as alterações e aprimoramentos de depuração na.NET Framework versão 2.0. |
|
Descreve como algumas interfaces de depuração CLR exigem que o processo que está sendo depurado em um estado específico. |
|
Fornece uma descrição passo a passo de como um processo de tempo de execução é depurado. |
|
Descreve como um depurador usa a API de depuração CLR para definir pontos de interrupção, para percorrer o código gerenciado e e lidar com exceções. |
|
Descreve como um depurador usa a API de depuração CLR para acessar os quadros de pilha gerenciada e avaliar expressões. |
|
Descreve a injeção de código dinâmico, no qual o CLR seqüestros de um thread ativo para executar o código que não estava presente no original arquivo executável portável (PE). |
|
Resume o processo publishing interfaces CLR, que enumerar e fornecem informações sobre os processos e os domínios de aplicativo em um computador. |
|
Discute considerações sobre segurança usando a API de depuração CLR. |
|
Descreve os coclasses de não gerenciados que usa a API de depuração. |
|
Descreve as interfaces não gerenciadas que lidam com a depuração de um programa que está sendo executado no common language runtime. |
|
Descreve as funções estáticas globais de não gerenciadas que usa a API de depuração. |
|
Descreve as enumerações não gerenciadas que usa a API de depuração. |
|
Descreve as estruturas de não gerenciadas que usa a API de depuração. |
Voltar ao topo