Información general sobre la depuración en CLR
La API de depuración de Common Language Runtime (CLR) permite a los proveedores de herramientas escribir depuradores para depurar aplicaciones que se ejecuten en el entorno de CLR. El código que se va a depurar puede ser cualquier tipo de código que admita CLR.
La API de depuración de CLR se implementa principalmente con código no administrado. Por tanto, la API de depuración se presenta como un conjunto de interfaces del Modelo de objetos componentes (COM). La API consta de lo siguiente:
Una colección de objetos e interfaces COM implementados por CLR.
Una colección de interfaces de devolución de llamada COM que debe el depurador debe implementar.
Esta información general contiene las siguientes secciones:
Escenarios de depuración de CLR
Categorías de API
Adjuntar o iniciar un programa
Controlar la ejecución
Examinar el estado de un programa
Modificar el estado de un programa
Usar Editar y continuar
Evaluar funciones
Insertar código dinámicamente
Entornos compatibles
Temas relacionados
Escenarios de depuración de CLR
En las siguientes secciones se describe cómo administra la API de depuración de Common Language Runtime los escenarios de depuración típicos. Tenga en cuenta que el motor en tiempo de ejecución admite directamente algunos escenarios e interopera con métodos actuales para admitir otros.
Depuración fuera de proceso
En la depuración fuera de proceso, el depurador está en un proceso independiente del proceso que se depura (es decir, está fuera del código que está siendo depurado). Este escenario reduce las interacciones entre el depurador y el código que está siendo depurado. Por consiguiente, habilita una imagen más precisa del proceso.
La API de depuración de CLR admite directamente la depuración fuera de proceso. La API administra toda la comunicación entre el depurador y las partes administradas del código que está siendo depurado para admitir la depuración de código administrado.
Aunque la API de depuración de CLR se utiliza fuera de proceso, parte de la lógica de depuración (por ejemplo, la sincronización de subprocesos) se produce fuera de proceso con el código que está siendo depurado. En la mayoría de los casos, éste es un detalle de implementación que debe ser transparente para el depurador. Para obtener más información sobre la sincronización de subprocesos, vea Arquitectura de depuración de CLR. Una desventaja es que la API de depuración no se puede utilizar para inspeccionar volcados cuando se utiliza fuera de proceso.
Depuración en proceso
En las versiones 1.0 y 1.1 de .NET Framework, la API de depuración de CLR admitía una depuración en proceso limitada, en la que un generador de perfiles podía usar las características de inspección de la API de depuración. En .NET Framework 2.0, la depuración en proceso se ha reemplazado por un conjunto de funciones más coherente con la API de generación de perfiles. Para obtener más información sobre estos cambios, vea las características de captura de la pila e inspección de objetos en Información general sobre la generación de perfiles.
Depuración de procesos remotos
En la depuración de procesos remotos, la interfaz de usuario del depurador está en un equipo independiente del proceso que se depura. Este escenario puede ser útil si el depurador interfiere con el código que se está depurando cuando se están ejecutando en el mismo equipo. La interferencia puede deberse a lo siguiente:
Recursos limitados.
Dependencias de la ubicación.
Errores que interfieren con el sistema operativo.
La API de depuración de CLR no admite directamente la depuración de procesos remotos. Aún debe existir un depurador basado en la API de depuración de CLR fuera de proceso del código que está siendo depurado. Por tanto, esta solución necesita un proceso proxy en el equipo que tiene el código que se está depurando.
Depuración de código no administrado
A menudo coexiste código administrado y código no administrado en el mismo proceso. La depuración simultánea de ambos tipos de código es una necesidad frecuente.
La API de depuración de CLR admite atravesar los límites entre código administrado y código no administrado, pero no admite directamente la depuración de código no administrado. Sin embargo, la API de depuración de CLR pueden coexistir con un depurador de código no administrado compartiendo los medios de depuración de Win32.
Además, la API de depuración de CLR proporciona dos opciones para depurar un proceso:
Una opción de asociación flexible en la que se depura solamente las partes administradas del proceso. Un depurador con asociación flexible a un proceso puede desasociarse después del proceso.
Una opción de asociación rígida en la que se depura tanto las partes administradas de un proceso como las no administradas y todos los eventos de depuración de Win32 se exponen a través de la API de depuración.
Entornos de lenguaje mixto
En software de componentes, diferentes componentes pueden compilarse con lenguajes diferentes. Un depurador debe entender las diferencias de lenguaje, de forma que pueda mostrar los datos en el formato correcto, evaluar las expresiones con la sintaxis correcta, etc.
La API de depuración de CLR no proporciona ninguna compatibilidad directa para los entornos de lenguaje mixto, porque CLR no tiene el concepto de lenguaje de origen. Los medios de asignación de origen existente de un depurador deben permitirle asignar una función determinada al lenguaje en el que se implementó la función.
Procesos múltiples y programas distribuidos
Un programa componente puede incluir componentes cooperativos que se están ejecutando en procesos diferentes o incluso en equipos diferentes de una red. Un depurador debería poder seguir paso a paso la lógica de ejecución entre procesos y equipos para proporcionar una vista lógica de lo que está pasando.
La API de depuración de CLR no proporciona compatibilidad directa para la depuración de procesos múltiples. De nuevo, un depurador que está utilizando la API debe proporcionar directamente tal compatibilidad y métodos existentes para hacer que continúe funcionando.
Volver al principio
Categorías de API
La API de depuración incluye los tres grupos siguientes de interfaces, todos utilizados normalmente por un depurador CLR y todos implementados como código no administrado:
Interfaces que admiten la depuración de aplicaciones CLR.
Interfaces que proporcionan acceso a información de depuración simbólica, que se almacena normalmente en archivos de base de datos de programa (PDB).
Comunica que admiten la consulta de los procesos y dominios de aplicación en un equipo.
La API de depuración se apoya en dos conjuntos adicionales de interfaces:
La API de metadatos para administrar la inspección de información estática sobre el programa, tal como la información sobre clases y tipo de método.
La API del almacén de símbolos para admitir la depuración en el nivel de origen para depuradores de código administrado.
Las interfaces de depuración también se pueden organizar en las categorías funcionales que se muestran en la tabla siguiente.
Categoría de API |
Descripción |
|---|---|
Registro |
Interfaces a las que el llama el depurador para registrarse con CLR y solicitar que se notifique cuando se produzcan eventos concretos. |
Notificación |
Interfaces de devolución de llamada que usa CLR para notificar al depurador diversos eventos y devolver información solicitada. Estas interfaces debe implementarlas el depurador. |
Punto de interrupción |
Interfaces a las que el llama el depurador para recuperar información sobre puntos de interrupción. |
Execution |
Interfaces a las que llama el depurador para controlar la ejecución del código que está siendo depurado y tener acceso a pilas de llamadas. |
Información |
Interfaces a las que llama el depurador para obtener información sobre el código que está siendo depurado. |
Enumeración |
Interfaces a las que llama el depurador para enumerar objetos. |
Modificación |
Interfaces a las que llama el depurador para modificar el código que se está depurando. |
En las siguientes secciones se describe la funcionalidad que proporcionan los servicios de depuración de Common Language Runtime (CLR).
Volver al principio
Adjuntar o iniciar un programa
CLR permite asociar el depurador a un programa en ejecución o iniciar un proceso. Los servicios de depuración de CLR son compatibles con la depuración Just-In-Time (JIT) permitiendo asociar el depurador a un programa que inicia una excepción no controlada. Sin embargo, un programa que no está ejecutándose en modo depurable puede tener menos información de depuración disponible. Un programa siempre se puede ejecutar en modo depurable para evitar este problema. Para obtener más información sobre el modo depurable, vea lo siguiente:
Volver al principio
Controlar la ejecución
Los servicios de depuración de CLR proporcionan varias maneras de controlar la ejecución de un programa. Entre ellas están los puntos de interrupción, el recorrido paso a paso, notificación de excepciones, la evaluación de la función y otros eventos relacionados con el inicio y el cierre de un programa.
La API de depuración de CLR solamente proporciona control de ejecución para código administrado. Si desea realizar el control de ejecución en código no administrado, debe implementar esa funcionalidad de forma independiente en el depurador.
Puntos de interrupción
Puede crear puntos de interrupción especificando el código y el lenguaje intermedio de Microsoft (MSIL) o el desplazamiento nativo de la ubicación donde debe producirse el salto. A continuación, se notificará al depurador cuando se encuentre el punto de interrupción. La API de depuración no admite directamente puntos de interrupción condicionales. Sin embargo, un depurador puede implementarlos evaluando una expresión como respuesta a un punto de interrupción y decidir si se va a informar o no al usuario de la detención.
Recorrido paso a paso
Los servicios de depuración de CLR proporcionan una gran variedad de funciones de recorrido paso a paso. Un programa puede recorrer el código de instrucción en instrucción (paso a paso) o por grupos de instrucciones (por intervalos). Puede omitir, entrar o salir de una función. Los servicios de depuración de CLR también pueden notificar al depurador si se produce una excepción que interrumpe el recorrido.
Aunque los servicios de depuración no son compatibles directamente con el recorrido por código no administrado, proporcionarán devoluciones de llamada cuando una operación de recorrido alcance código no administrado, para ceder el control al depurador. También proporcionan funcionalidad que permite el depurador determinar cuándo se está a punto de entrar en código administrado desde código no administrado.
El CLR no ofrece directamente el recorrido por el nivel de origen. Un depurador puede proporcionar esta funcionalidad utilizando el recorrido por intervalos con su propia información de asignación de origen. Puede utilizar las interfaces del almacén de símbolos para obtener información de nivel de origen. Para obtener más información sobre estas interfaces, vea Almacén de símbolos de diagnósticos (Referencia de la API no administrada).
Excepciones
Los servicios de depuración de CLR permiten informar un depurador de excepciones de primera y segunda oportunidad en código administrado. El objeto iniciado está disponible para la inspección en cada punto.
El CLR no administra excepciones nativas en código no administrado a menos que se propaguen hasta el código administrado. Sin embargo, todavía puede utilizar los servicios de depuración de Win32 que se comparten con los servicios de depuración de CLR para administrar excepciones no administradas.
Eventos de programa
Los servicios de depuración de CLR notifican a un depurador cuando se producen muchos eventos de programa. Estos eventos incluyen la creación y salida del proceso, creación y salida del subproceso, creación y salida del dominio de aplicación, carga y descarga del ensamblado, carga y descarga del módulo, carga y descarga de la clase. Para obtener un buen rendimiento, puede deshabilitar los eventos de carga y descarga de clase para un módulo. De forma predeterminada, los eventos de carga y descarga de clase están deshabilitados.
Control de subprocesos
Los servicios de depuración de CLR proporcionan interfaces para suspender y reanudar subprocesos individuales (administrados).
Volver al principio
Examinar el estado de un programa
Los servicios de depuración de CLR proporcionan una manera detallada de inspeccionar las partes de un proceso que están ejecutando código administrado cuando el proceso está en un estado detenido. Un proceso se puede inspeccionar para obtener una lista de subprocesos físicos.
Un subproceso se puede examinar para inspeccionar su pila de llamadas. La pila de llamadas de un subproceso se descompone en dos niveles: el nivel de la cadena y el nivel del marco de pila. La pila de llamadas se descompone primero en cadenas. Una cadena es un segmento de la pila de llamadas lógica contigua. Contiene marcos de pila administrados o no administrados, pero no ambos. Además, todos los marcos llamados administrados de una única cadena comparten el mismo contexto de CLR. Una cadena puede ser administrada o no administrada.
Cada cadena administrada se puede descomponer además en marcos de pila únicos. Cada marco de pila representa una invocación de método. Puede consultar un marco de pila para obtener el código que está ejecutando u obtener sus argumentos, variables locales y registros nativos.
Una cadena no administrada no contiene marcos de pila. En su lugar, proporciona el intervalo de direcciones de pila que se asignan al código no administrado. Depende de un depurador de código no administrado descodificar la parte no administrada de la pila y proporcionar un seguimiento de la pila.
.gif "Nota") Nota |
|---|
Los servicios de depuración de CLR no admiten el concepto de variables locales en código fuente.Depende del depurador asignar las variables locales a sus asignaciones. |
Los servicios de depuración de CLR también proporcionan acceso a variables globales, estáticas de clase y variables locales de subproceso.
Volver al principio
Modificar el estado de un programa
Los servicios de depuración de CLR permiten a un depurador cambiar la ubicación física del puntero de instrucción durante la ejecución, aunque ésta puede ser una operación peligrosa. El puntero de instrucción se puede cambiar correctamente cuando son ciertas las condiciones siguientes:
El puntero de instrucción actual y el puntero de la instrucción de destino están ambos en puntos de secuencia. Los puntos de secuencia representan aproximadamente los límites de instrucción.
El puntero de instrucción objeto no se encuentra en un filtro de excepciones, un bloque catch o un bloque finally.
El puntero de instrucción actual está en un bloque catch y el puntero de instrucción de destino no se encuentra fuera del bloque catch.
El puntero de la instrucción de destino está en el mismo marco que el puntero de instrucción actual.
Cuando la ubicación física del puntero de instrucción cambie, las variables de la ubicación del puntero de instrucción actual se asignarán a las variables de la ubicación del puntero de la instrucción de destino. Las referencias de la recolección de elementos no utilizados a la ubicación del puntero de instrucción se inicializarán correctamente.
Una vez cambiado el puntero de instrucción, los servicios de depuración de CLR marcan la información de pila que haya en memoria caché como no válida y actualizan la información la próxima vez que se necesita. Los depuradores que almacenan en memoria caché punteros para información de pila tales como marcos y cadenas deben actualizar esta información después de cambiar el puntero de instrucción.
El depurador también puede modificar los datos de un programa cuando se detiene el programa. El depurador puede cambiar las variables locales y los argumentos de una función mientras la función se está ejecutando, de manera similar a la inspección. El depurador también puede actualizar campos de matrices y objetos, así como campos estáticos y variables globales.
Volver al principio
Usar Editar y continuar
Durante una sesión de depuración, puede emplear la característica Editar y continuar para hacer lo siguiente:
Editar código fuente.
Volver a compilar el código fuente modificado.
Conservar el resto del estado en tiempo de ejecución del archivo ejecutable que se está depurando.
Continuar con la sesión de depuración sin tener que volver a ejecutar el archivo ejecutable desde el principio.
Volver al principio
Evaluar funciones
Para evaluar expresiones de usuario y propiedades dinámicas de objetos, un depurador necesita un medio de ejecutar el código del proceso que se está depurando. Los servicios de depuración de CLR permiten al depurador realizar una llamada de función o método y hacer que se ejecute dentro del proceso del código que se está depurando.
CLR permite al depurador detener este tipo de operación porque puede ser peligrosa (por ejemplo, puede desencadenar un interbloqueo con código existente). Si la evaluación se detiene correctamente, el subproceso se trata como si la evaluación nunca se hubiera producido, excepto por los efectos secundarios en las variables locales de la evaluación parcial. Si la función llama a código no administrado o se bloquea de alguna manera, puede ser imposible de finalizar la evaluación.
Cuando la evaluación de la función ha finalizado, el CLR usa una devolución de llamada para notificar al depurador si la evaluación se completó correctamente o si la función produjo una excepción. Puede utilizar los métodos ICorDebugValue e ICorDebugValue2 para inspeccionar los resultados de una evaluación.
El subproceso en el que se va a producir la evaluación de la función se debe detener en código administrado, en un punto que sea seguro para la recolección de elementos no utilizados. (La evaluación de la función también se permite para las excepciones no controladas.) En código no optimizado, estos puntos seguros son muy comunes; la mayoría de las operaciones de recorrido de nivel de MSIL se completarán en uno de ellos. Sin embargo, estos puntos pueden ser raros en el código optimizado. A veces, puede que una función completa no tenga ningún punto seguro. La frecuencia de los puntos seguros para la recolección de elementos no utilizados variará de función a función. Incluso en código no optimizado, es posible no detenerse en uno de ellos. En código optimizado o no optimizado, el método ICorDebugController::Stop raramente aterriza en un punto seguro.
Los servicios de depuración de CLR prepararán una nueva cadena en el subproceso para iniciar una evaluación de función y llamar a la función solicitada. En cuanto se inicie la evaluación, todos los aspectos de la API de depuración están disponibles: control de ejecución, inspección, evaluación de la función, etc. Se admiten las evaluaciones anidadas y los puntos de interrupción se tratan de la manera habitual.
Volver al principio
Insertar código dinámicamente
Algunos depuradores permiten a un usuario escribir instrucciones arbitrarias en la ventana Inmediato y ejecutar las instrucciones. Los servicios de depuración de CLR admiten este escenario. Dentro de lo razonable, no hay ninguna restricción sobre el código que puede insertar dinámicamente. (Por ejemplo, no se permiten las instrucciones goto no locales.)
La inyección dinámica de código se implementa utilizando una combinación de operaciones de Editar y continuar y evaluación de la función. El código que se va a insertar se contiene en una función y se inserta inserta utilizando Editar y continuar. A continuación, se evalúa la función insertada. Si lo desea, puede proporcionar a la función contenedora argumentos ByRef, de modo que los efectos secundarios sean inmediatos y permanentes.
Volver al principio
Entornos compatibles
Los medios de depuración de CLR están disponibles en todos los procesadores y sistemas operativos compatibles con el CLR, con las excepciones siguientes:
Editar y continuar y la depuración en modo mixto no son compatibles con sistemas operativos de 64 bits. Los métodos SetIP (ICorDebugILFrame::SetIP e ICorDebugNativeFrame::SetIP) tienen restricciones adicionales sobre sistemas operativos de 64 bits. La funcionalidad restante es equivalente en todos los procesadores (aunque habrá representaciones de datos específicas del procesador como tamaños de puntero, contextos de registro, etc.).
Editar y continuar y la depuración en modo mixto no son compatibles con sistemas operativos basados en Win9x. La funcionalidad restante debe ser equivalente en todos los sistemas operativos. Sin embargo, hay algunas excepciones concretas, que se indican en la documentación de las funciones individuales.
Volver al principio
Temas relacionados
Título |
Descripción |
|---|---|
Describe cómo los diferentes componentes de la API de depuración de CLR interactúan con CLR y con el depurador. |
|
Describe los cambios y mejoras de la depuración en .NET Framework 2.0. |
|
Describe cómo algunas de las interfaces de depuración de CLR requieren que el proceso que está depurando esté en un estado concreto. |
|
Proporciona una descripción paso a paso de cómo se depura un proceso en tiempo de ejecución. |
|
Describe cómo un depurador utiliza la API de depuración de CLR para establecer puntos de interrupción, recorrer paso a paso código administrado y no administrado, y administrar excepciones. |
|
Describe cómo un depurador utiliza la API de depuración de CLR para tener acceso a marcos de pila administrados y evaluar expresiones. |
|
Describe la inyección dinámica de código, en la que CLR secuestra un subproceso activo para ejecutar código que no estaba presente en el archivo ejecutable portable original (PE). |
|
Resume interfaces de publicación de procesos de CLR, que enumeran y proporcionan información sobre los procesos y dominios de aplicación en un equipo. |
|
Explica las consideraciones de seguridad para el uso de la API de depuración de CLR. |
|
Describe las coclases no administradas que utiliza la API de depuración. |
|
Describe las interfaces no administradas que controlan la depuración de un programa que se está ejecutando en Common Language Runtime. |
|
Describe las funciones estáticas globales no administradas que utiliza la API de depuración. |
|
Describe las enumeraciones no administradas que utiliza la API de depuración. |
|
Describe las estructuras no administradas que utiliza la API de depuración. |
Volver al principio