Dateiinformationen protokollieren
Dieser Dokumentation für die Vorschau nur ist und in späteren Versionen geändert. Leere Themen wurden als Platzhalter eingefügt.]
Sie können Protokolldateien erstellen, die Aktionen für die folgenden Vorgänge aufzeichnen:
Interoperabilität mit systemeigenem Code.
Laden von Programmen.
Netzwerk.
Weitere Informationen zu den Registrierungsschlüsseln, die Protokollierung und wie Sie Protokolldateien generieren, zu steuern, finden Sie unter SO WIRD'S GEMACHT: Erstellen von Protokolldateien.
In diesem Thema wird die Ausgabe geschrieben, die Protokolldateien für Interoperabilitäts- und Ladeprogramm Protokollierung beschrieben.
Interop-Protokolldateien
Die Ausgabe für Interop-Protokollierung besteht die Signaturen der Interop-Funktionsaufrufe, sobald Sie zur Laufzeit mit Fehlermeldungen auftreten.
.NET Compact Framework, Version 3.5 unterstützt erweiterte Interop-Protokollierung, die in der "Deep Marshalling" Abschnitt weiter unten in diesem Thema beschrieben wird.
Funktion Signaturen
Die Signaturen für verwaltete, systemeigene und systemeigene verwaltete Aufrufe werden protokolliert und umfassen die folgenden Arten von Anrufen:
Plattformaufruf aufrufen.
COM-Vtable und Dispatch-Aufrufe.
Delegieren Sie Rückrufe.
Interop-Protokollierung hilft Ihnen beim Behandeln von Problemen beim Aufrufen oder Zurückkehren von einem Interop-Funktionsaufruf, z. B. bei falscher Parametertypen gemarshallt werden oder das Programm unerwartet beendet wird.
Die Ausgabe für eine Funktion Signatureintrag besteht aus drei Zeilen für jeden Interop-Aufruf. Die erste Zeile enthält Flags, die den Typ des Funktionsaufruf zu identifizieren und enthält eine oder mehrere der folgenden Elemente:
[pinvokeimpl]
Identifiziert einen verwalteten, systemeigenen Aufruf, der das Attribut DllImportAttribute verwendet.[Ctor]
Identifiziert einen Konstruktor für eine vom Tlbimp.exe (Type Library Importer-Tool) generierte Interop-Assembly-Klasse.[preservesig]
Vorausgesetzt die verwalteten und systemeigenen Funktionen die gleiche Signatur mit keine Übersetzung von HRESULT in die Ausnahme, die von der Laufzeit erzwungen.[delegate]
Gibt an, dass die Funktion ein Rückruf systemeigenen verwalteten Delegaten ist. Der Delegat fungiert als Funktionszeiger in systemeigenem Code.
Die zweite Zeile der Interop-Protokolldatei stellt die verwaltete Signatur dar. Für verwaltete, systemeigene Funktion-Aufrufe kennzeichnet diese Zeile die verwaltete Funktion, die den systemeigenen Code aufruft. Für systemeigene verwaltete Funktionsaufrufe kennzeichnet diese Zeile die verwaltete Funktion, die von systemeigenem Code aufgerufen wird.
Die dritte Zeile stellt die systemeigene Signatur dar, wie von der Common Language Runtime erwartet. Diese Zeile identifiziert Datentypen für jeden Parameter und enthält Informationen wie die Daten des verwalteten Objekts gemarshallt werden. Die Common Language Runtime wird davon ausgegangen, dass die richtigen Typen durch das Attribut DllImportAttribute oder in der COM-Schnittstellendefinition Signatur angegeben sind. Fehler bei der die richtigen Typen angeben ist ein common Fehler, der zu unerwartetes Verhalten führen können, da die Funktion mit falschen Parameterwerten ausgeführt werden.
Hinweis
Ein falscher Parameter angeben kann zu einer NotSupportedException oder eine systemeigene Ausnahme führen.Um den Fehler zu isolieren, ändern Sie Parametertypen zu bekannten unterstützten Typen oder ein IntPtr ein.
Jeder Typ hat eine Standardmarshalling-Typ. Beachten Sie, dass das Marshallingverhalten eines verwalteten Typs für COM-Aufrufe und DllImportAttribute oder Delegaten ein Rückruf Aufrufe unterschiedlich sein kann. Das Attribut MarshalAsAttribute können Sie einen anderen als den Standardwert Marshalling geben. Sie müssen auch das ref-Schlüsselwort verwenden, um Parameter zu identifizieren, der einen Zeiger auf einen Werttyp oder ein Zeiger auf einen Zeiger für einen Verweistyp darstellt.
Die folgende Tabelle zeigt Interop-Protokollierung eines Plattformaufrufs aufrufen.
Zeilennummer und Beschreibung |
Protokolleintrag |
|---|---|
Typ des Funktionsaufrufs 1 |
[pinvokeimpl][preservesig] |
2-Verwaltete Signatur |
bool PlatformDetector::SystemParametersInfo(uint , uint , System.Text.StringBuilder , uint ); |
3-Systemeigene Signatur |
BOOLEAN (I1_WINBOOL_VAL) SystemParametersInfo(unsigned int (U4_VAL) , unsigned int (U4_VAL) , WCHAR * (STRINGBUILDER_LPWSTR) , unsigned int (U4_VAL) ); |
Die folgende Tabelle zeigt einen Rückruf für Delegaten Interop-Protokollierung.
Zeilennummer und Beschreibung |
Protokolleintrag |
|---|---|
Typ des Funktionsaufrufs 1 |
[preservesig][delegate] |
2-Verwaltete Signatur |
int WndProc::Invoke(WndProc , IntPtr , uint , uint , int ); |
3-Systemeigene Signatur |
int (I4_VAL) (*)(INT_PTR (I_VAL) , unsigned int (U4_VAL) , unsigned int (U4_VAL) , int (I4_VAL) ) |
Die folgende Tabelle zeigt Interop-Protokollierung eines systemeigenen verwalteten COM-Funktionsaufrufs ', wobei zurückgibt die Common Language Runtime einen Fehler-HRESULT Wenn eine verwaltete Ausnahme auftritt.
Zeilennummer und Beschreibung |
Protokolleintrag |
|---|---|
Typ des Funktionsaufrufs 1 |
(keine Flags) |
2-Verwaltete Signatur |
int N2MDualComponentImp.IN2MDualInterface::GetInt(N2MDualComponentImp.IN2MDualInterface This); |
3-Systemeigene Signatur |
HRESULT GetInt(IN2MDualInterface *(INTF_VAL) this, [retval] int (I4_VAL) retval); |
Tief Marshalling
Der .NET Compact Framework Version 3.5 unterstützt auch Tiefe Marshalling für Interop-Protokollierung. In deep Marshalling werden Informationen über gemarshallte Objekte protokolliert, die in Strukturen oder Verweistypen enthalten sind.
Das folgende Protokoll Ausgabe zeigt ein Beispiel einer Plattform Plattformaufrufs, die gemarshallte Objekte in einer Struktur verwendet. Die erste Zeile der Tiefe Marshalling Abschnitt legt fest, warum der Tiefe Marshaller aufgerufen wurde. In diesem Beispiel hieß es berechnet die Größe der Struktur. Das Protokoll zeigt den Datentyp und die Größe in Bytes des jeweiligen Objekts an. Der Indexwerte (z. B. 0004) stellen die Byte-Offsets für die angegebenen Variablen dar.
DEEP MARSHAL: Get size
struct interoplogging.MyStruct
{
0000: Int32 myVar as Int32 (4 bytes)
0004: Int32 myVar2 as Int32 (4 bytes)
0008: String myString as WCHAR[10] (20 bytes)
}
DEEP MARSHAL: Total size = 28 bytes
[pinvokeimpl][preservesig]
void interoplogging.Form1::MyAPI(interoplogging.MyStruct );
void MyAPI(MyStruct (NONBLIT_VALUETYPE_VAL) );
DEEP MARSHAL: Managed -> Native
struct interoplogging.MyStruct
{
0000: Int32 myVar as Int32 (4 bytes)
0004: Int32 myVar2 as Int32 (4 bytes)
0008: String myString as WCHAR[10] (20 bytes)
}
DEEP MARSHAL: Total size = 28 bytes
Fehlermeldungen
Einige Situationen und Ausnahmen können Fehlermeldungen in der Protokolldatei aufgezeichnet werden führen. Diese Nachrichten können insbesondere hilfreich sein, wenn Sie Probleme untersuchen, die betreffen Interoperation mit systemeigenen Komponenten und DLLs für die der systemeigene Quellcode nicht verfügbar ist. Fehlermeldungen können Sie Hilfe bei folgenden Problemen:
Systemeigene verwaltete Funktionsaufrufe.
Runtime COM-Schnittstelle aufrufen. Ein HRESULT-Fehler kann an systemeigenen Code zurückgegeben werden, beim Aufruf einer COM-Schnittstelle-Funktion, die von der Common Language Runtime implementiert wird. Es gibt verschiedene Laufzeit-implementierte Schnittstellen (einschließlich IUnknown, IDispatch, IConnectionPointContainer, IEnumConnectionPointsund IConnectionPoint), die systemeigener Code aufrufen können, indem Sie ein verwaltetes Objekt gemarshallt als eine COM-Schnittstelle. Wenn ein Funktionsaufruf einen Fehler in systemeigenen Code in eine dieser Schnittstellen zurückgibt, druckt die Common Language Runtime eine entsprechende Fehlermeldung, das das HRESULT und zusätzliche relevante Informationen enthält.
Systemeigenen Code, der erwartet, Funktionalität zu verwenden, nicht unterstützt, z. B. IDispatch::GetTypeInfo ist.
Nicht implementierte Schnittstellen. Systemeigener Code erhalten Fehler E_NOINTERFACE von IUnknown::QueryInterface, wo es das verwaltete COM-Objekt eine zusätzliche Schnittstelle implementiert haben erwartet. In diesem Fall wird die GUID der nicht implementierten Schnittstelle ebenfalls bereitgestellt.
Verwaltete Ausnahmen. Diese können den verwalteten Funktionsaufruf auftreten und diese dadurch so vorzeitig zurückgegeben. Bei COM-Aufruf konvertiert die Laufzeit die Ausnahme in einen Fehler HRESULT-Wert, der in systemeigenen Code zurückgegeben. Jedoch, wenn eine Delegaten-Callback oder COM-Aufruf kein HRESULT-Rückgabewert erwartet, können nicht Sie sicherstellen, wird der Fehler bewusst sein, und unerwartetes Verhalten möglicherweise als Ergebnis angezeigt. Das Interop-Protokoll wird eine Fehlermeldung enthalten, tritt eine Ausnahme während eines Funktionsaufrufs systemeigene verwaltete Interop. Diese Meldung hilft Ihnen, verwaltete Funktionen zu identifizieren, zusätzlichen Fehlerbehandlung Logik gut mit systemeigenen Code arbeiten müssen. Die folgenden Faktoren können eine verwaltete Ausnahme verursachen:
Mithilfe von Typen in Ihrer Definition oder DllImportAttribute Signatur COM-Schnittstelle, die von .NET Compact Framework nicht unterstützt werden verursacht eine Ausnahme während der JIT-Kompilierung durchgeführt. Häufig sind alternative Optionen, die zulässig, z. B. mithilfe einer IntPtr sind.
Wenn das eigentliche Objekt kann nicht mit der Signatur angegebenen Typ vereinbart werden oder die Objektdaten nicht in dem angeforderten Typ konvertiert werden kann, wird eine Ausnahme zur Laufzeit ausgelöst, wenn die Funktion aufgerufen wird. Dies tritt normalerweise auf, wenn ein systemeigenes Objekt in ein verwaltetes Objekt zu konvertieren.
Bestimmt, was beim Erstellen eines Runtime callable Wrapper (RCW) oder ein COM callable Wrapper (CCW) schwierig ist eine Ausnahme verursacht. Die Interop-Protokolldatei helfen, die Ursache dieser Probleme festzustellen, wenn eine detaillierte Fehlermeldung nicht mit der verwalteten Ausnahme bereitgestellt wird.
Unterschiede zu .NET Framework
Es gibt Unterschiede zwischen der .NET Framework-Implementierung von COM-Interoperabilität und der im vollständigen .NET Framework. .NET Compact Framework unterstützt nicht die folgenden:
Erstellen eines CCW, enthält eine Schnittstelle ohne eine angegebene GUID.
Einen RCW für eine Klasse erstellen, erbt von einer Interop-Assembly-Klasse.
Erstellen ein CCW, die nicht generische Schnittstelle mit einer generischen Methode enthält.
RCWs werden normalerweise nach der Finalisierung bereinigt; Sie können aber auch die ReleaseComObject oder FinalReleaseComObject-Methode verwenden, um den RCW freizugeben, die ein Objekt zugeordnet ist. Wenn Sie diese erweiterten Optionen zum Verwalten der Lebensdauer der Objekte verwenden und Sie versuchen, das Objekt zu verwenden, nachdem es für einen systemeigenen COM-Aufruf freigegeben wurde, eine Ausnahme ausgelöst, und die Protokolldatei enthält eine Fehlermeldung über die Ursache der Ausnahme.
Ladeprogramm-Protokolldateien
Ladeprogrammprotokolldateien bestehen aus zwei Abschnitten: eine Kopfzeile und Text. Der Header der Protokolldatei enthält die folgenden Daten:
Name der ausführbaren Hauptdatei der Anwendung ’s.
Prozess-ID, als vom Betriebssystem zugewiesen.
Datum und Uhrzeit die Protokolldatei erstellt wurde.
Version von .NET Compact Framework, die zum Ausführen der Anwendung verwendet wurde.
Informationen über die Plattform, auf der die Anwendung ausgeführt wird.
Der Hauptteil der Protokolldatei enthält Diagnose Informationen über jede Assembly, wie es von der Anwendung geladen wird. Diese Informationen kann helfen Ihnen Fehler durch das Klassenladeprogramm die Anwendung gestartet wird.
Der Hauptteil der Protokolldatei enthält die folgenden Daten:
Umwandlung-Zustand, der angibt, ob die Anwendung im Kompatibilitätsmodus rückwärts ausgeführt wurde.
Ablaufverfolgung für jede Assembly laden, einschließlich aus dem die Assembly geladen wurde und welche Version geladen wurde.
Die Vertrauensebene zugeordnet sind, jedes Modul als es geladen wird.
Ihre Anwendung zugeordneten Konfigurationsdateien.
Fehler bei Methoden, Typen, Assemblys und Module.
Fehler bei der eine systemeigene DLL oder eine Funktion für eine Plattform gefunden Plattformaufrufs.
Die folgende Tabelle zeigt ein Beispiel einer Protokolldatei Ladeprogramm. Zeilennummern sind ungefähre.
Zeilennummer und Beschreibung |
Protokolleintrag |
|---|---|
1-Prozess |
Process [\Program Files\VW\VW.exe] |
2-Prozess-ID |
Process ID [0x4d9585d2] |
3-Datum |
Date [2005/02/25] |
4-Mal |
Time [18:33:14] |
5 .NET compact Framework-version |
NETCF [2.0.5035.00] |
6-Plattform |
Platform [Windows CE v4.20.1081 (PocketPC) WinCE4ARMV4 release Beta2 ARMV4 IJITv2] |
7–14 - Global Assembly Cache-Vorgänge |
GAC: Updating GAC [0x0] GAC: Checking .gac files inside [\Windows\] GAC: Found [Microsoft .NET CF 2.0.GAC] .gac file. GAC: Done with the file system check. Checking the registry. GAC: Found [Microsoft .NET CF 2.0.GAC] registry entry. GAC: Done with the registry check. Let's compare. GAC: Entry [Microsoft .NET CF 2.0.GAC] is up to date. GAC: GAC is up to date. |
15-Kompatibilitätsmodus (0.0.0.0 bedeutet nicht im Kompatibilitätsmodus) |
Compatibility mode [0.0.0.0] |
16-Laden-Modul |
Loading module [\Windows\GAC_mscorlib_v2_0_0_0_cneutral_1.dll] |
17-Geladenes Modul |
Loaded [mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=969DB8053D3322AC] from [\Windows\GAC_mscorlib_v2_0_0_0_cneutral_1.dll] |
Für jedes Modul werden die letzten beiden Einträge (Laden und Laden) protokolliert. Sie identifizieren, die Assemblys und ihre Speicherorte. Alle Fehler Laden eines Moduls sind im Ladeprogramm Protokoll angegeben.
Beispiele für Fehler
Die beiden Beispiele in diesem Abschnitt zeigen die Verwendung der Loader-Protokolldatei ermitteln, wann Fehler aufgetreten sind.
Das folgende Beispiel zeigt die Protokolleinträge, die geschrieben werden, wenn das Ladeprogramm eine Assembly nicht findet.
Loading module [\Program Files\VW\Golf.dll]
Attempt to load [\Program Files\VW\Golf.dll] has failed (err 0x80001000).
Loading module [\Program Files\VW\Golf.exe]
Attempt to load [\Program Files\VW\Golf.exe] has failed (err 0x80001000).
Failed to load [Golf, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null]
Das folgende Beispiel zeigt die Protokolleinträge, die geschrieben werden, wenn das Ladeprogramm einen bestimmten Typ nicht findet.
Missing Type. Type [Cars.Jetta], Assembly [Cars].
Missing Type. Class [Cars.Jetta], Assembly [Cars, Version=5.0.0.0,
Culture=neutral, PublicKeyToken=null].
Siehe auch
Aufgaben
SO WIRD'S GEMACHT: Erstellen von Protokolldateien
SO WIRD'S GEMACHT: Konfigurieren der Laufzeitversion
Konzepte
.NET compact Framework Gewusst-wie-Themen