Cómo depurar procesadores fijo

Seleccione idioma Seleccione idioma
Id. de artículo: 133722 - Ver los productos a los que se aplica este artículo
Expandir todo | Contraer todo

En esta página

Resumen

Depuración planos thunks generados por el compilador thunk puede ser difícil porque el mecanismo de procesador es complejo y herramientas de depuración capaces de seguimiento a través de thunks son difíciles de utilizar. Este artículo presenta una estrategia general para depurar los procesadores sencillos, varias técnicas de depuración específicas y una guía de solución de problemas que se explica cómo corregir muchos problemas comunes de thunk.

Más información

Limitaciones en qué puede hacer una DLL de destino

Antes de comenzar la depuración thunks, tenga en cuenta que hay algunas limitaciones en qué un destino puede hacer DLL dentro de un thunk. Esto es porque una aplicación Win16 llamar a una DLL de Win32 no es un proceso basado en Win32; igualmente, una aplicación basada en Win32 llamar a un archivo DLL basado en Win16 no es un proceso basado en Win16. Limitaciones específicas comunes incluyen:

  • No puede crear subprocesos dentro de un thunk desde una aplicación basado en Win16 a una DLL de Win32.
  • El código basado en Win32 DLL llama a los procesadores debe requieren espacio de pila poco porque los procesos de basado en Win16 llamados tienen pilas mucho menores que las aplicaciones basadas en Win32.
  • Archivos DLL basado en Win16 que contienen rutinas de servicio de interrupción (ISR) no deben thunk a basadas en Win32 DLL mientras se controla las interrupciones.
  • Aplicaciones basadas en Win32 no deben pasar punteros a datos ubicados en la pila como parámetros de thunks o DLL basado en Win16 que cambie las pilas de llamada.

¿Por qué procesadores fijo de depuración puede ser difícil

Depuración de los procesadores sencillos es difícil parcialmente porque el mecanismo de thunk plana es una parte compleja del núcleo de Windows. Su proviene de la complejidad del hecho de que deben transformar las llamadas de función en código compilado de 32 bits en llama a compatible con código de 16 bits y viceversa. Puesto que el código de 32 bits utiliza diferentes tipos de datos y CPU registrar conjuntos de código de 16 bits, el mecanismo de thunk plana debe traducir parámetros de función, cambie las pilas y traducir los valores devueltos. Se ha optimizado para velocidad, pero debe permitir preferente código de Win32 para llamar a código no preferente de Win16. El compilador de procesador facilita creación los procesadores sencillos que crearlos manualmente, pero no es infalible.

Depuración de los procesadores sencillos es difícil no sólo porque el mecanismo de sí mismo es complejo, pero también porque las herramientas de depuración necesarias son más difíciles de dominar. Nivel de aplicación depuradores como el depurador de Microsoft Visual C++ y WinDBG no seguimiento a través de thunks porque constar de código de 32 bits y 16 bits y provocar que el sistema solicitar o liberar el Win16Mutex. Para realizar el seguimiento a través de un thunk, necesitará utilizar a un depurador de nivel del sistema como WDEB386.EXE. Los principales inconvenientes utilizar WDEB386.EXE son que necesita conocer el lenguaje ensamblador de Intel x 86, saber cómo funcionan los microprocesadores Intel x 86 y recuerde muchos comandos del depurador.

La estrategia de procedimientos para utilizar

La mejor estrategia para la depuración thunks es divide y vencerás porque es relativamente fácil y elimina la mayoría de los problemas antes de que tiene que traza mediante código de lenguaje de ensamblado en un depurador de nivel del sistema. Los procesadores sencillos se componen de una DLL basada en Win32 y una DLL basado en Win16, por lo que es posible probar cada uno de ellos de forma aislada antes de probar ellos juntos. Cree una aplicación basado en Win16 para probar la DLL de Win16 y crear una aplicación basada en Win32 para probar la DLL de Win32. Esto permite utilizar una amplia variedad de herramientas de depuración para comprobar que cada lado funciona correctamente.

Lista de comprobación preliminar - antes de compilar con el compilador de procesador

Una vez haya comprobado que cada lado funciona correctamente, es hora de poner los dos juntos para probar el código thunk propio. Antes de compilar el código thunk con el compilador de código thunk, realice una comprobación preliminar de los siguientes elementos:
  1. En la secuencia de comandos thunk, asegúrese de que cada función tiene el número correcto y los tipos de parámetros. Además Asegúrese de que los tipos de parámetros son compatibles con el compilador de procesador. Si no, tendrá que cambiar de alguna manera el parámetro para pasar los datos con un tipo compatible.
  2. Si pasa las estructuras como parámetros, asegúrese de que utilizar la misma estructura en su DLL basadas en Win32, basado en Win16 DLL y secuencia de comandos thunk. Establecer empaquetado de estructura en la línea de comandos del compilador de C/C ++ en el y en la línea de comandos del compilador de código thunk. Observe que el modificador de empaquetado del compilador de procesador es del lado de 16 bits, mayúsculas y minúsculas para el lado de 32 bits.
  3. Asegúrese de que las funciones que está thunk a se exportan correctamente y utilizan el PASCAL llamar a convención si son de 16 bits o _stdcall si son de 32 bits. El compilador de procesador no admite el _cdecl y convenciones de llamada __fastcall.
  4. Asegúrese de que el archivo DLL basadas en Win32 llama a ThunkConnect32() cada vez se llama a su función DllMain(). Asimismo, asegúrese de que la DLL de Win16 tiene una función exportada de DllEntryPoint(), independiente de su LibMain(), que llama ThunkConnect16() y devuelve TRUE si se realiza correctamente ThunkConnect16().

    Nota : es realmente llamada XXX_ThunkConnect16() y XXX_ThunkConnect32() donde XXX es el símbolo de definir con modificador -t del compilador de procesador. El código generado por el compilador de procesador utiliza estos símbolos para generar tablas que llamar a ThunkConnect16() y ThunkConnect32.
  5. Asegúrese de que el valor especificado en modificador de -t de línea de comandos del compilador de procesador es el mismo para el Win32 y la DLL de Win16 thunk. El valor también debe corresponder al prefijo de las llamadas ThunkConnect en su DLL basado en Win16 y basadas en Win32 (consulte la nota en el paso 4).
  6. Compruebe que la DLL de Win16 tiene DLLEntryPoint exportado con la palabra clave RESIDENTNAME en su archivo de definición (.def) de módulo. Sin la palabra clave RESIDENTNAME, fallará la llamada de ThunkConnect32/ThunkConnect16 y no se cargará la DLL.
  7. Compruebe que la DLL de 16 bits tiene XXX_ThunkData16 exportado con la palabra clave RESIDENTNAME en su archivo de definición (.def) de módulo.
  8. Compruebe en el archivo MAKE su basado en Win16 del archivo DLL que el compilador de recursos es marcar el archivo DLL como 4.0. Si está marcada menor que 4.0, no se pudo cargar y el código thunk se producirá.
  9. Si la función de código thunk de 32 bits a 16 bits devuelve un puntero, asegúrese de que el tipo base es el mismo tamaño en los lados de 16 bits y 32 bits de thunk. Si el tamaño del tipo base es distinto, a continuación, el compilador de código thunk emite un mensaje de error que indica, "No se puede devolver el punteros a tipos non-identical". Uno para evitar este problema consiste en devolver un puntero a un tipo de datos distintas pero compatibles. Por ejemplo, un código thunk no puede devolver un puntero a un int porque un int es de dos bytes en el lado de 16 bits, pero cuatro bytes en el lado de 32 bits. Cambiar tipo devuelto del código thunk de un puntero a un int a un puntero a un largo en la secuencia de comandos thunk y el código fuente de la DLL basado en Win16 y basadas en Win32.

    Si escribe un thunk de 16 bits a 32 bits que devuelve un puntero, el compilador de código thunk emite un mensaje de error que indica "no se pueden devolver tipos de puntero." El compilador de procesador no permite los thunks de 16 bits a 32 bits devolver tipos de puntero porque después de que el código thunk haya devuelto desde la función de 32 bits, el puntero no señalará a datos en el espacio de dirección de proceso correcto basadas en Win32. Esto es porque los espacios de direcciones de todos los procesos basadas en Win32, utilizan las mismas direcciones intervalo y se están cambiado previamente en el contexto.
  10. Si el vinculador notifica un error "sin resolver externo" y el símbolo es un nombre de función que está escrito de forma coherente en todo el código fuente, archivos de definición de módulo y la secuencia de comandos thunk, asegúrese de que todas las apariciones de su prototipo son coherentes. En el lado de Win32, la función de thunk debe declararse con el tipo de __stdcall; en el lado de Win16, la función debe declararse con el tipo de PASCAL. En proyectos de C++, asegúrese de declarar y definir ambos lados de la función de thunk con el especificador de vinculación extern "C" así como la __stdcall o el tipo de PASCAL.

Guía trouble-Shooting - después de compilar con el compilador de procesador

Después de comprobar los preliminaries, generar el código thunk dll e intente ejecutarlos. Si ejecuta, continúe con más pruebas para asegurarse de que está bailan sólido. Si no ejecuta, utilice a la Guía de solución de problemas siguiente para determinar y corregir la causa del problema.

Se produce ThunkConnect16() Win16 las ThunkConnect32() en el lado de Win32:

  1. Ejecutar versiones de depuración de las DLL del sistema. Las versiones de depuración de Kernel32.dll y Krnl386.exe contienen muchos mensajes de diagnósticos que le indicará el código thunk no inicializó. Para ejecutar las versiones de depuración de las DLL del sistema, utilice el icono de "Cambiar a depurar DLLs" en el menú Inicio bajo herramientas SDK de Win32. Utilice el "cambiar a la DLL de depuración no" para volver a la versión comercial.
  2. Compruebe que la DLL de Win16 tiene una llamada a ThunkConnect16() y la DLL basadas en Win32 tiene una llamada correspondiente a ThunkConnect32(). Si falta uno de estos, a continuación, el otro fallará y no el código thunk dll se cargará.
  3. Coloque puntos de interrupción en DllMain() de la DLL Win32 y en su archivo DLL de Win16 DllEntryPoint() y LibMain() funciones para ver qué archivos DLL no se cargan.
Si las llamadas a ThunkConnect16() y ThunkConnect32() funcionan correctamente, pero todavía no es el código thunk, es el momento para simplificar el código thunk. Realmente pueden atacar de dos maneras. En primer lugar, empiece por quitar parámetros el código thunk uno por uno y volver a compilar se. O, en segundo lugar, cree un thunk simple que funciona y genérelo hasta que se produce un error; para ello, siga estos pasos:
  1. Crear un thunk simple y ejecutar que simplemente Asegúrese de que el mecanismo de procesador configurado correctamente. Una buena elección para un thunk simple es una función con ningún valor devuelto y sin parámetros. Si no funciona incluso el código thunk simple, ejecutar a través de la lista preliminar de comprobación anterior para asegurarse de que dispone de cosas que se ha configurado correctamente. Continúe con el paso 2.
  2. Asegúrese de que la DLL de destino y las DLL que se basa en se pueden encontrar y cargadas. Si falta uno o el cargador no lo encuentra, el código thunk no funcionará.
  3. Asegúrese de que la DLL no está haciendo algo que no es posible en el contexto de un thunk de destino.
Una vez que tiene un thunk simplificado que funciona, pero el thunk real sigue sin funciona, siga estos pasos:
  1. Agregar parámetros a thunk simple uno a la vez para determinar si un parámetro es la causa del error. Si uno es, asegúrese de que el parámetro es el tipo correcto, que se declara la función y se define con el mismo número y tipos de parámetros en ambos archivos DLL y el compilador de procesador, y que la función está declarada como PASCAL o _stdcall.
  2. Si la DLL de destino es una DLL basado en Win16 y no puede tener acceso a sus datos globales o estáticos, asegúrese de que ha exportado correctamente la función. Si utiliza el modificador de /Gd, esta con Visual C++, debe declarar y definir la función con la palabra clave __export en código fuente de la DLL basado en Win16. Enumerar sólo el nombre la función en archivo de definición (.def) de la DLL módulo no es suficiente porque el compilador no procesa el archivo .def, por lo que no se generará el prólogo y requieren código de epílogo funciones exportadas.
  3. Si las llamadas a LocalAlloc() en los errores de protección general (GP) destino basado en Win16 DLL causa, asegúrese de que la función se exporta como se describe en el paso 2.
  4. Si recibe un error de protección general en KERNEL32 justo después de la función basado en Win16 de destino devuelve, asegúrese de que se declara la función de destino y se define como PASCAL. No se puede utilizar la convención de llamada de C. Aunque es raro que en código C o C++, pero lo más probable en lenguaje ensamblador, asegúrese de que la función de destino no modifica los registros de DS, SS, BP, SI o DI.
  5. Si recibe un error de protección general en el código thunk de 32 bits DLL o KERNEL32 inmediatamente después de la función de destino basado en Win32 devuelve, asegúrese de que la función de destino se declara como _stdcall y que no modifique los registros de DS, ES, FS, SS, EBP, EBX, ESI o EDI. Código de C o C++ no debe hacer los registros que se va a modificar, pero debe comprobarse cuidadosamente código en lenguaje ensamblador.
  6. Si su basado en Win16 función de destino devuelve a una ubicación no válida, asegúrese de que se declara y define como FAR. Esto es especialmente importante para archivos DLL de modelo pequeño; las funciones de DLL del modelo de medianas y grandes son FAR de manera predeterminada.
  7. Si experimenta un error GP en una función basado en Win16 cuando tiene acceso a más de 64 KB de datos de un puntero pasado como un parámetro (es decir, un puntero thunked), deberá asignar una matriz de los selectores en mosaico, como se describe en el artículo siguiente en Microsoft Knowledge Base:
    132005DOCERR: AllocSelector & FreeSelector documentación incompletos
    En el lado de Win16 punteros thunked siempre constan de un selector único con un límite de 64 KB, lo que significa que no puede utilizar como punteros de grandes. Todo el rango original de datos que el puntero direcciones es accesible para el destino basado en Win16 DLL - pero sólo si crea una matriz de los selectores en mosaico a hacer referencia a él y, si utiliza variables de puntero enorme tener acceso a los datos.
  8. Asegúrese de que sólo utilice un puntero thunked en el contexto de thunk. Selectores asignados por el compilador de código thunk para su uso por basado en Win16 destinos se liberan tan pronto como devuelve el código thunk.
  9. Colocar puntos de interrupción al principio de las funciones de destino para asegurarse de que obtiene en ellos. Si está y ha depurado el lado de destino independientemente del thunk y el error se produce dentro del destino, a continuación, probable que el destino está haciendo algo que no puede realizarse en un procesador o hacer referencia a memoria que no existe. Consulte los pasos 7 y 8.

Propiedades

Id. de artículo: 133722 - Última revisión: lunes, 11 de julio de 2005 - Versión: 2.3
La información de este artículo se refiere a:
  • Microsoft Platform Software Development Kit-January 2000 Edition sobre las siguientes plataformas
    • Microsoft Windows 95
    • Microsoft Windows 98 Standard Edition
    • Microsoft Windows Millennium Edition
Palabras clave: 
kbmt kbhowto kbkernbase kbprogramming KB133722 KbMtes
Traducción automática
IMPORTANTE: Este artículo ha sido traducido por un software de traducción automática de Microsoft (http://support.microsoft.com/gp/mtdetails) en lugar de un traductor humano. Microsoft le ofrece artículos traducidos por un traductor humano y artículos traducidos automáticamente para que tenga acceso en su propio idioma a todos los artículos de nuestra base de conocimientos (Knowledge Base). Sin embargo, los artículos traducidos automáticamente pueden contener errores en el vocabulario, la sintaxis o la gramática, como los que un extranjero podría cometer al hablar el idioma. Microsoft no se hace responsable de cualquier imprecisión, error o daño ocasionado por una mala traducción del contenido o como consecuencia de su utilización por nuestros clientes. Microsoft suele actualizar el software de traducción frecuentemente.
Haga clic aquí para ver el artículo original (en inglés): 133722

Enviar comentarios

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com