Debuggen von DirectShow-Filtern

  • Artikel

[Das dieser Seite zugeordnete Feature DirectShow ist ein Legacyfeature. Es wurde durch MediaPlayer, IMFMediaEngine und Audio/Video Capture in Media Foundation ersetzt. Diese Features wurden für Windows 10 und Windows 11 optimiert. Microsoft empfiehlt dringend, dass neuer Code nach Möglichkeit MediaPlayer, IMFMediaEngine und Audio/Video Capture in Media Foundation anstelle von DirectShow verwendet. Microsoft schlägt vor, vorhandenen Code, der die Legacy-APIs verwendet, um nach Möglichkeit die neuen APIs zu verwenden.]

Viele der in diesem Thema beschriebenen Debugfunktionen werden in der DirectShow-Basisklassenbibliothek implementiert. Weitere Informationen finden Sie unter DirectShow-Basisklassen.

Assertionsprüfung

Verwenden Sie die Assertionsprüfung liberal. Assertionen können Annahmen überprüfen, die Sie im Code zu Vorbedingungen und Nachbedingungen stellen. DirectShow stellt mehrere Assertionsmakros bereit. Weitere Informationen finden Sie unter Assert- und Breakpointmakros.

Objektnamen

In Debugbuilds gibt es eine globale Liste von Objekten, die von der CBaseObject-Klasse abgeleitet sind. Wenn Objekte erstellt werden, werden sie der Liste hinzugefügt. Wenn sie zerstört werden, werden sie aus der Liste entfernt. Um eine Liste dieser Objekte anzuzeigen, rufen Sie die Funktion DbgDumpObjectRegister auf.

Die Konstruktormethode für die CBaseObject-Basisklasse – und die meisten davon abgeleiteten Klassen – enthält einen Parameter für den Namen des Objekts. Geben Sie Ihren Objekten eindeutige Namen, um sie zu identifizieren. Verwenden Sie das NAME-Makro , wenn Sie den Namen deklarieren, sodass der Name nur in Debugbuilds zugewiesen wird. In Einzelhandelsbuilds wird der Name zu NULL.

Debugprotokollierung

Die DbgLog-Funktion zeigt Debugmeldungen an, während Ihr Programm ausgeführt wird. Verwenden Sie diese Funktion, um die Ausführung Ihrer Anwendung oder Ihres Filters nachzuverfolgen. Sie können Rückgabecodes, die Werte von Variablen und alle anderen relevanten Informationen protokollieren.

Jede Debugnachricht hat einen Typ, z. B. LOG_TRACE oder LOG_ERROR, und eine Debugebene, die die Wichtigkeit der Nachricht angibt. Nachrichten mit niedrigeren Debugebenen sind wichtiger als Nachrichten mit höheren Ebenen.

Im folgenden Beispiel trennt ein hypothetischer Filter einen Pin von einem Array von Pins. Wenn der Verbindungsversuch erfolgreich ist, zeigt der Filter eine LOG_TRACE Meldung an. Wenn der Versuch fehlschlägt, wird eine LOG_ERROR Meldung angezeigt:

hr = m_PinArray[iPin]->Disconnect();
if (FAILED(hr))
{
    DbgLog((
        LOG_ERROR, 
        1, 
        TEXT("Could not disconnect pin %d. HRESULT = %#x", 
        iPin, 
        hr
        ));
 
   // Error handling code (not shown).
}
DbgLog((LOG_TRACE, 3, TEXT("Disconnected pin %d"), iPin));

Beim Debuggen können Sie die Debugebene für jeden Nachrichtentyp festlegen. Außerdem verfügt jedes Modul (DLL oder ausführbare Datei) über eigene Debugebenen. Wenn Sie einen Filter testen, erhöhen Sie die Debugebenen für die DLL, die den Filter enthält.

Weitere Informationen finden Sie unter Debuggen von Ausgabefunktionen.

Kritische Abschnitte

Um deadlocks einfacher nachzuverfolgen, schließen Sie Assertionen ein, die bestimmen, ob der aufrufende Code einen bestimmten kritischen Abschnitt besitzt. Die Funktionen CritCheckIn und CritCheckOut geben an, ob der aufrufende Thread einen kritischen Abschnitt besitzt. In der Regel rufen Sie diese Funktionen in einem Assert-Makro auf.

Sie können auch die DbgLockTrace-Funktion verwenden, um nachzuverfolgen, wann kritische Abschnitte gehalten oder freigegeben werden.

Debuggen in DirectShow