Condividi tramite

Debug di filtri DirectShow

  • Articolo

[La funzionalità associata a questa pagina, DirectShow, è una funzionalità legacy. È stata sostituita da MediaPlayer, IMFMediaEnginee Acquisizione audio/video in Media Foundation. Queste funzionalità sono state ottimizzate per Windows 10 e Windows 11. Microsoft raccomanda vivamente che il nuovo codice sfrutti MediaPlayer, IMFMediaEngine e Acquisizione audio/video in Media Foundation anziché DirectShow, quando possibile. Microsoft suggerisce che il codice esistente che usa le API legacy venga riscritto per usare le nuove API, se possibile.

Molte delle funzionalità di debug descritte in questo argomento vengono implementate nella libreria di classi di base DirectShow. Per altre informazioni, vedere DirectShow Base Classes.

Verifica delle asserzioni

Usare il controllo delle asserzioni liberamente. Le asserzioni possono verificare i presupposti che si fanno nel codice sulle precondizioni e sulle postcondizioni. DirectShow fornisce diverse macro di asserzione. Per altre informazioni, vedere Macro assert e breakpoint.

Nomi degli oggetti

Nelle compilazioni di debug è presente un elenco globale di oggetti che derivano dalla classeCBaseObject. Man mano che vengono creati, gli oggetti vengono aggiunti all'elenco. Quando vengono distrutti, vengono rimossi dall'elenco. Per visualizzare un elenco di tali oggetti, chiamare la funzionedbgDumpObjectRegister.

Il metodo del costruttore per la CBaseObject classe base e la maggior parte delle classi derivate da esso include un parametro per il nome dell'oggetto. Assegnare nomi univoci agli oggetti per identificarli. Utilizzare la macro NAME quando si dichiara il nome, in modo che il nome venga allocato solo nelle compilazioni di debug. Nelle build di vendita al dettaglio, il nome diventa NULL.

Registrazione debug

La funzioneDbgLogvisualizza i messaggi di debug durante l'esecuzione del programma. Usare questa funzione per tracciare l'esecuzione dell'applicazione o del filtro. È possibile registrare i codici restituiti, i valori delle variabili e qualsiasi altra informazione pertinente.

Ogni messaggio di debug ha un tipo, ad esempio LOG_TRACE o LOG_ERROR, e un livello di debug, che indica l'importanza del messaggio. I messaggi con livelli di debug inferiori sono più importanti di quelli con livelli più elevati.

Nell'esempio seguente un filtro ipotetico disconnette un pin da una matrice di pin. Se il tentativo di disconnessione ha esito positivo, il filtro visualizza un messaggio di LOG_TRACE. Se il tentativo non riesce, viene visualizzato un messaggio di LOG_ERROR:

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));

Quando si esegue il debug, è possibile impostare il livello di debug per ogni tipo di messaggio. Inoltre, ogni modulo (DLL o eseguibile) gestisce i propri livelli di debug. Se si esegue il test di un filtro, aumentare i livelli di debug per la DLL che contiene il filtro.

Per altre informazioni, vedere Eseguire il debug di funzioni di output.

Sezioni critiche

Per semplificare la traccia dei deadlock, includere asserzioni che determinano se il codice chiamante è proprietario di una determinata sezione critica. Le funzioni CritCheckIn e CritCheckOut indicano se il thread chiamante è proprietario di una sezione critica. In genere, queste funzioni vengono chiamate dall'interno di una macro assert.

È anche possibile usare la funzioneDbgLockTraceper tracciare quando vengono mantenute o rilasciate sezioni critiche.

il debug in DirectShow