Gewusst wie: Festplatte Thunks Debuggen

SPRACHE AUSWÄHLEN SPRACHE AUSWÄHLEN
Artikel-ID: 133722 - Produkte anzeigen, auf die sich dieser Artikel bezieht
Alles erweitern | Alles schließen

Auf dieser Seite

Zusammenfassung

Flache Thunks, die vom Compiler Thunk generierten Debuggen kann schwierig sein, weil der Thunk-Mechanismus komplex ist und debugging Tools kann der Ablaufverfolgung über Thunks schwierig sind zu verwenden. Dieser Artikel bietet eine allgemeine Strategie für Debuggen flache Thunks, mehrere bestimmte Debugverfahren und eine Problembehandlung Dokumentation, die erläutert, wie viele allgemeine thunking Probleme zu beheben.

Weitere Informationen

Einschränkungen auf wie ein Ziel-DLL werden kann

Bevor Sie Thunks Debuggen beginnen, müssen Sie berücksichtigen, die bestehen einige Einschränkungen für welche ein Ziel-DLL in einen Thunk tun kann. Dies ist, da eine Win16-basierte Anwendung eine Win32-DLL aufrufen kein Win32-Prozess ist; ebenso eine Win32-basierte Anwendung Aufrufen einer Win16-DLL ist keinen Win16-Prozess. Allgemeine bestimmte Einschränkungen umfassen:

  • Threads innerhalb eines Thunk kann nicht aus einer Win16-basierten Anwendung auf eine Win32-DLL erstellt werden.
  • Der Code in Win32-DLLs durch Thunks aufgerufen sollte wenig Stapelspeicher erfordern, da der aufrufende Win16-Prozesse viel kleinere Stapel haben als Win32-basierten Anwendungen.
  • Win16-DLLs Interrupt Service-Routinen (ISRs enthalten) müssen nicht mit Win32-DLLs thunk, während der Verarbeitung von Interrupts.
  • Win32-basierten Anwendungen müssen nicht Zeiger übergeben, an Daten auf dem Stapel als Parameter des Thunks oder Aufruf Win16-DLLs, die Stapel zu wechseln.

Warum Debuggen flach Thunks schwer werden kann.

Flache Thunks Debuggen ist schwierig, teilweise, da der flachen Thunk-Mechanismus komplexe Teil der Windows-Kernel ist. Seine Komplexität Stielen aus der Tatsache, der es Funktionsaufrufe in 32-Bit-kompilierten Code in transformieren muss ruft kompatibel mit 16-Bit-Code und umgekehrt. Da 32-Bit-Code unterschiedliche Datentypen verwendet und CPU registrieren Sätze von 16-Bit-Code, muss der flachen Thunk-Mechanismus Funktionsparameter übersetzen, Stacks wechseln und Rückgabewerte zu übersetzen. Für Geschwindigkeit optimiert ist, aber dennoch präemptiven Win32-Code zum Aufrufen von nicht präemptiven Win16-Code muss zulassen. Der Compiler Thunk Erstellen flacher Thunks ist viel einfacher, manuell zu erstellen, aber es ist nicht sicher.

Flache Thunks Debuggen ist schwierig nicht nur da der Mechanismus selbst komplex, sondern auch, ist da die erforderlichen debugging Tools schwieriger zu sind master. Anwendungsebene Debugger wie z. B. Microsoft Visual C++-Debugger und WinDBG durch Thunks Ablaufverfolgung kann nicht, da Sie von 32-Bit- und 16-Bit-Code bestehen und bewirken, dass das System in Anspruch nehmen oder Version der Win16Mutex. Um über einen Thunk verfolgen möchten, müssen Sie einen Debugger auf Systemebene, wie z. B. WDEB386.EXE verwenden. Die wichtigsten Nachteile mit WDEB386.EXE sind, müssen Sie wissen Intel X 86-Assemblysprache, wissen, wie Intel X 86-Mikroprozessoren zu arbeiten, und denken viele Befehle debugger.

Die optimale Strategie zur Verwendung

Die beste Strategie für das Debuggen Thunks besteht darin, Teile und herrsche da ist relativ einfach und die meisten Probleme beseitigt, bevor Sie Ablaufverfolgung durch den Code in einem Debugger auf Systemebene Assembly Language müssen. Flache Thunks bestehen aus einer Win32-DLL und einer DLL Win16-daher ist es möglich, jede dieser isoliert, bevor Sie diese zusammen testen testen. Erstellen einer Win16-basierten Anwendung, die Win16-DLL zu testen, und Erstellen einer Win32-basierten Anwendung, die Win32-DLL zu testen. Dadurch können Sie verwenden eine Vielzahl von debugging Tools überprüfen, ob jeder Seite ordnungsgemäß funktioniert.

Vorläufige Prüfliste - vor dem Kompilieren mit der Compiler Thunk

Sobald Sie überprüft haben, dass jede Seite ordnungsgemäß funktioniert, ist es Zeit, die zwei zusammen, um den Thunk selbst zu testen. Stellen Sie vor den Thunk mit dem Compiler Thunk kompilieren, eine vorläufige Überprüfung die folgenden Elemente:
  1. Ihr Skript Thunk stellen Sie sicher, dass jede Funktion die richtige Anzahl und Typen der Parameter hat. Außerdem stellen Sie sicher, dass die Parametertypen vom Compiler Thunk unterstützt werden. Wenn Sie nicht möchten, müssen Sie den Parameter irgendwie ändern, um die Daten mit einem unterstützten Typ übergeben.
  2. Wenn Sie alle Strukturen als Parameter übergeben, stellen Sie sicher Sie dieselbe Struktur auf Lieferschein in den Win32-DLL, Win16-DLL und Thunk-Skript verwenden. Sie festlegen Struktur Lieferschein in Ihre C/C++-Compiler-Befehlszeile und in der Thunk Compiler-Befehlszeile. Beachten Sie, dass der Thunk Compiler Lieferschein Schalter für die 16-Bit-Seite klein- und Großbuchstaben für die 32-Bit-Seite ist.
  3. Stellen Sie sicher, dass Sie zu thunking sind Funktionen ordnungsgemäß exportiert und verwenden Sie die PASCAL-Aufrufkonvention, wenn Sie 16-Bit- oder _stdcall aufgerufen wird, wenn Sie 32-Bit. Der Thunk-Compiler unterstützt die _cdecl und Aufrufkonventionen __fastcall nicht.
  4. Stellen Sie sicher, dass die Win32-DLL ThunkConnect32() jedes Mal aufruft, seine DllMain()-Funktion aufgerufen wird. Analog dazu stellen Sie sicher die Win16-DLL eine exportierte DllEntryPoint() Funktion, unabhängig von Ihrer LibMain() verfügt, die ThunkConnect16() aufruft und gibt TRUE zurück, wenn ThunkConnect16() erfolgreich.

    Hinweis : Sie tatsächlich rufen Sie XXX_ThunkConnect16() und XXX_ThunkConnect32() XXX, wobei das Symbol ist Sie mit der Thunk-Compiler -t-Schalter definieren. Der Code vom Compiler Thunk generiert verwendet diese Symbole, um Tabellen zu generieren, die ThunkConnect16() und ThunkConnect32 aufrufen.
  5. Stellen Sie sicher, dass der in der Thunk Compiler Befehlszeile -t-Schalter angegebene Wert für die Win32- und die Win16 Thunk-DLLs identisch ist. Der Wert muss auch für das Präfix der ThunkConnect Aufrufe in Ihre DLLs Win16- und Win32-basierten (Siehe die Anmerkung in Schritt 4) entsprechen.
  6. Prüfen Sie, ob die DLL Win16-DLLEntryPoint mit dem RESIDENTNAME-Schlüsselwort in der Moduldefinitionsdatei (.def) exportiert verfügt. Ohne das Schlüsselwort RESIDENTNAME der ThunkConnect32-ThunkConnect16-Aufruf schlägt fehl, und die DLLs werden nicht geladen.
  7. Prüfen Sie, ob die 16-Bit-DLL mit dem RESIDENTNAME-Schlüsselwort in der Moduldefinitionsdatei (.def) exportiert XXX_ThunkData16 verfügt.
  8. Überprüfen Sie in Ihre Win16-DLL Makefile, dass der Ressourcencompiler die DLL als 4.0 markiert ist. Wenn es kleiner als 4.0 markiert ist, wird es nicht geladen, und der Thunk schlägt fehl.
  9. Falls Ihre 32-Bit-16-Bit-Thunk-Funktion einen Zeiger liefert, stellen Sie sicher, dass der Basistyp über die gleiche Größe auf den 16-Bit- und 32-Bit-Seiten der der Thunk ist. Wenn die Größe des Basistyps unterschiedlich ist, gibt der Compiler Thunk ein Fehlermeldung, die besagt, "Kann nicht Zeiger zu non-identical Typen zurück." Eine Möglichkeit, um dieses Problem zu umgehen besteht darin, einen Zeiger auf ein anderes, aber kompatibel ist, zurückzugeben. Beispielsweise kann kein Thunk einen Zeiger in einen Int zurückgeben, da Int zwei Bytes auf der Seite 16-Bit-aber vier Bytes auf 32-Bit-ist. Ändern Sie den Thunk Rückgabetyp von einem Zeiger in einen Int ein Zeiger auf eine lange in der Thunk-Skript und den Quellcode der Win16 und Win32-DLLs.

    Wenn Sie einen 16-Bit-32-Bit-Thunk, der einen Zeiger zurückgibt schreiben, gibt der Compiler Thunk ein Fehlermeldung, die besagt, "Zeigertypen nicht zurückgegeben werden können." Der Compiler Thunk lässt nicht zu 16-Bit-32-Bit-Thunks Zeigertypen zurückgeben, da nach der Thunk aus der 32-Bit-Funktion zurückgegeben hat, der Zeiger nicht auf Daten in der richtigen Win32-Prozess-Adressbereich zeigen wird. Dies ist da die Adressräume aller Win32-Prozesse die gleichen Bereich Adressen verwenden und Kontext ohne gewechselt werden.
  10. Wenn der Linker einen Fehler "unresolved externen meldet" und das Symbol ist ein Funktionsname, die einheitlich im gesamten alle Quellcode, Moduldefinitionsdateien und Thunk-Skript geschrieben ist, stellen Sie sicher, dass alle Vorkommen der Prototyp konsistent sind. Auf der Seite Win32 Thunk-Funktion muss mit dem Typ __stdcall deklariert werden; auf der Seite Win16 muss die Funktion mit dem PASCAL-Typ deklariert werden. In C++-Projekten unbedingt deklarieren und beide Seiten der Thunk-Funktion mit der Extern "C" Bindungsspezifizierer zusätzlich zu den __stdcall oder der PASCAL-Typ zu definieren.

Trouble-Shooting Guide - nach dem Kompilieren mit der Compiler Thunk

Nach der Überprüfung der Preliminaries erstellen Sie der Thunk DLLs und versuchen Sie, diese auszuführen. Wenn Sie ausgeführt werden, fahren Sie mit weiteren Tests sicher Sie unglaublich sind solide. Wenn Ausführung nicht, verwenden Sie die folgende Problembehandlung Führungslinie zu bestimmen und beheben die Ursache des Problems.

Im Win16 oder ThunkConnect32() ThunkConnect16(), der Win32-Seite schlägt fehl:

  1. Führen Sie die debugging Versionen von System-DLLs. Die Debuggen Versionen von Kernel32.dll und KRNL386.exe enthalten viele Diagnosemeldungen Ihnen mitteilen, warum der Thunk nicht initialisiert wurde. Um das Debuggen Versionen von System-DLLs verwenden Sie das "Wechseln zu debuggen DLLs"-Symbol im Startmenü unter Win32-SDK. Verwenden Sie den "Schalter Debuggen von nicht-DLL" um zurück zur die Verkaufsversion zu wechseln.
  2. Überprüfen Sie, ob die Win16-DLL einen Aufruf von ThunkConnect16() hat und die Win32-DLL einen entsprechenden Aufruf von ThunkConnect32() hat. Wenn eines dieser fehlt, ist die andere fehl, und der Thunk DLLs wird nicht geladen.
  3. Legen Sie Haltepunkte in der Win32-DLL DllMain(), und in DllEntryPoint() und LibMain() Win16 DLL Funktionen finden Sie unter welche DLLs nicht geladen.
Wenn Ihre ThunkConnect16() und ThunkConnect32() Aufrufe ordnungsgemäß funktionieren, aber der Thunk ist noch nicht, ist es Zeit, um Ihre Thunk vereinfachen. Sie können dies tatsächlich auf zweierlei Weise angreifen. Zuerst starten Sie, indem Parameter aus der Thunk einzeln entfernen und neu zu kompilieren. Oder, Zweitens erstellen Sie einen einfachen Thunk, der funktioniert, und erstellen Sie, bis er, fehlschlägt gehen Sie folgendermaßen vor:
  1. Erstellen Sie einen einfachen Thunk, und führen Sie ihn einfach um sicherzustellen, dass Sie den Thunk-Mechanismus ordnungsgemäß eingerichtet. Eine gute Wahl für einen einfachen Thunk ist eine Funktion keinen Wert zurückgibt und keine Parameter. Wenn auch der einfache Thunk nicht funktioniert, führen Sie die vorläufige Prüfliste oben, um sicherstellen Sie Dinge, die ordnungsgemäß eingerichtet haben. Fahren Sie mit Schritt 2.
  2. Überprüfen Sie, sicherzustellen, dass das Ziel-DLL, und es abhängig DLLs gefunden und geladen werden können. Wenn eine fehlt oder das Ladeprogramm kann es nicht finden, funktioniert der Thunk nicht.
  3. Vergewissern Sie sich Ihre DLL etwas tun nicht ist, die es im Kontext des einen Thunk kann nicht Ziel.
Nachdem Sie einen vereinfachten Thunk, der funktioniert, aber Ihre echte Thunk weiterhin nicht funktioniert, folgendermaßen Sie vor:
  1. Fügen Sie Parameter hinzu einfache Thunk eine zu einem Zeitpunkt bestimmen, ob ein Parameter den Fehler verursacht. Wenn eine ist, stellen Sie sicher, dass der Parameter den richtigen Typ ist, dass die Funktion deklariert und mit derselben Anzahl und Typen der Parameter in beide DLLs und der Compiler Thunk, definiert ist und, dass die Funktion als PASCAL oder _stdcall deklariert ist.
  2. Wenn Ziel-DLL eine Win16-DLL ist, und es kann nicht auf globalen oder statischen Daten zugreifen, müssen Sie die Funktion ordnungsgemäß exportiert haben. Wenn Sie den Schalter/Gd mit Visual C++ verwenden, müssen Sie deklarieren und definieren Sie die Funktion mit dem __export-Schlüsselwort in das Win16-DLL-Quellcode. Nur auflisten Namen der Funktion in der DLL-Moduldefinitionsdatei (.def) ist nicht ausreichend, da der Compiler nicht die DEF-Datei, verarbeitet damit es wird nicht den Prolog generieren und Epilogcode, der exportierten Funktionen erforderlich.
  3. Wenn Aufrufe an LocalAlloc() in Ihrem Ziel Win16-DLL Ursache allgemeine (GP) Schutzverletzungen, stellen Sie sicher wird Ihre Funktion exportiert, wie in Schritt 2 beschrieben.
  4. Wenn Sie unmittelbar nach Ihrem Ziel Win16-Funktion gibt einen DB-Fehler in Kernel32 erhalten haben, stellen Sie sicher die Zielfunktion deklariert und als PASCAL definiert. Kann die C-Aufrufkonvention nicht verwendet werden. Obwohl selten in C oder C++-Code jedoch eher in Assemblysprache, stellen Sie sicher, dass die Zielfunktion DS, SS, BP, SI oder DI Register ändern nicht.
  5. Wenn Sie einen DB-Fehler in der 32-Bit-Thunk DLL oder Kernel32 unmittelbar nach Ihrer Funktionsrückgaben Ziel Win32-basierten erhalten, stellen Sie sicher, dass die Zielfunktion als _stdcall deklariert ist und nicht die DS, ES, EA, SS, EBP, EBX, ESI oder EDI-Register ändern. C- oder C++-Code sollte nicht die Register geändert werden, jedoch Assemblersprache Code sorgfältig überprüft werden sollen.
  6. Wenn Ihre Win16-Zielfunktion einer ungültigen Position wieder sicher deklariert und als FAR definiert. Dies gilt insbesondere für kleine Modell DLLs; Funktionen in mittleren und großen Modell DLLs sind FAR standardmäßig.
  7. Wenn einen GRUPPENRICHTLINIEN-Fehler in einer Win16-Funktion beim Zugriff auf mehr als 64 KB Daten von einem Zeiger als Parameter (d. h. ein thunked Zeiger) im übergebenen auftreten, müssen Sie ein Array von nebeneinander Selektoren reservieren, wie in der folgenden Artikel der Microsoft Knowledge Base beschrieben:
    132005DOCERR: AllocSelector & FreeSelector Dokumentation unvollständig
    Auf der Seite Win16 umfassen thunked Zeiger immer eine einzelne Auswahl mit einer Begrenzung von 64 KB, d. h., Sie als riesige Zeiger verwenden zu können. Der gesamte ursprüngliche Bereich der Daten, die Adressen der Zeiger ist für das Ziel Win16-DLL - jedoch nur, wenn er erstellt ein Array von nebeneinander Auswahlen auf Sie verweisen und riesige Zeigervariablen verwendet, um den Zugriff auf Daten zugänglich.
  8. Stellen Sie sicher Sie einen thunked Zeiger nur im Kontext der Thunk verwenden. Selektoren, die durch den Compiler Thunk für die Verwendung von Win16-Zielen zugewiesen werden freigegeben, sobald der Thunk gibt.
  9. Platzieren Sie Haltepunkte, am Anfang des Ziel Funktionen sicherstellen, dass Sie darin erhalten. Wenn Sie Sie die Seite Ziel unabhängig der Thunk gedebuggt haben und der Fehler, in das Ziel verursacht wird, sind Chancen gut, dass das Ziel tun etwas, das in einen Thunk erfolgen kann nicht, oder verweisen auf Speicher, der nicht vorhanden ist. Finden Sie die Schritte 7 und 8.

Eigenschaften

Artikel-ID: 133722 - Geändert am: Montag, 11. Juli 2005 - Version: 2.3
Die Informationen in diesem Artikel beziehen sich auf:
  • Microsoft Platform Software Development Kit January 2000 Edition, wenn verwendet mit:
    • Microsoft Windows 95
    • Microsoft Windows 98 Standard Edition
    • Microsoft Windows Millennium Edition
Keywords: 
kbmt kbhowto kbkernbase kbprogramming KB133722 KbMtde
Maschinell übersetzter Artikel
Wichtig: Dieser Artikel wurde maschinell und nicht von einem Menschen übersetzt. Die Microsoft Knowledge Base ist sehr umfangreich und ihre Inhalte werden ständig ergänzt beziehungsweise überarbeitet. Um Ihnen dennoch alle Inhalte auf Deutsch anbieten zu können, werden viele Artikel nicht von Menschen, sondern von Übersetzungsprogrammen übersetzt, die kontinuierlich optimiert werden. Doch noch sind maschinell übersetzte Texte in der Regel nicht perfekt, insbesondere hinsichtlich Grammatik und des Einsatzes von Fremdwörtern sowie Fachbegriffen. Microsoft übernimmt keine Gewähr für die sprachliche Qualität oder die technische Richtigkeit der Übersetzungen und ist nicht für Probleme haftbar, die direkt oder indirekt durch Übersetzungsfehler oder die Verwendung der übersetzten Inhalte durch Kunden entstehen könnten.
Den englischen Originalartikel können Sie über folgenden Link abrufen: 133722
Microsoft stellt Ihnen die in der Knowledge Base angebotenen Artikel und Informationen als Service-Leistung zur Verfügung. Microsoft übernimmt keinerlei Gewährleistung dafür, dass die angebotenen Artikel und Informationen auch in Ihrer Einsatzumgebung die erwünschten Ergebnisse erzielen. Die Entscheidung darüber, ob und in welcher Form Sie die angebotenen Artikel und Informationen nutzen, liegt daher allein bei Ihnen. Mit Ausnahme der gesetzlichen Haftung für Vorsatz ist jede Haftung von Microsoft im Zusammenhang mit Ihrer Nutzung dieser Artikel oder Informationen ausgeschlossen.

Ihr Feedback an uns

 

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