Come ispezionare gli oggetti COM dal file di dump di Visual Basic?

Question

Sfondo

Abbiamo un NET WinForms applicazione scritta in C# che si interfaccia con uno scanner negozio palmare tramite un'applicazione console. L'applicazione della console è scritta in un buon vecchio VB6, nessun codice gestito lì. L'applicazione VB6 è composta da diversi oggetti COM.

L'applicazione .NET WinForms aggiorna i dati nello scanner richiamando l'applicazione della console con i parametri corretti. All'avvio dell'applicazione console, viene visualizzato un modulo modale che ricorda all'utente di collocare il dispositivo palmare nella base.

Problema

un cliente ha una bizzarra situazione in cui la chiamata per avviare l'applicazione di console sembra bloccarsi prima di visualizzare il modulo di promemoria. Se l'utente preme un tasto qualsiasi, anche qualcosa di innocente come Shift o Alt, l'applicazione si sblocca e viene visualizzato il modulo di sollecito. Mentre è sospeso, l'utilizzo della CPU dell'applicazione console è molto alto.

Abbiamo ottenuto un dump della memoria dall'applicazione della riga di comando utilizzando ProcDump. Ho qualche esperienza nel debug di file di dump gestiti, ma questo dump di VB 6 è strano per me.

Abbiamo catturato diversi dump di memoria completi in fila. In alcuni di questi, sembra che ci siano pile di colla COM. Ad esempio, diversi file di dump mostrano uno stack di chiamate in questo modo:

msvbm60!BASIC_DISPINTERFACE_GetTICount 
msvbm60!_vbaStrToAnsi 
msvbm60!IIDIVbaHost 
msvbm60!rtcDoEvents 
msvbm60!IIDIVbaHost 
msvbm60!BASICCLASS_QueryInterface 
[our code which I think is trying to create and invoke a COM object] 

Non aiuta che gli unici simboli che ho sono dal nostro codice. Il server dei simboli Microsoft non ha un file PDB per msvbm60.dll (o almeno non dalla loro versione che è 6.0.98.2).

Domande

sto sospettare ci può essere qualche problema di threading COM che sta accadendo solo sul loro sistema.

1) Come posso determinare lo stato di thread di ogni thread in un file di dettagli? Se questo fosse un file di dump gestito, guarderei a !threads e poi a !threadstate per capire gli stati del thread. Non esiste un codice gestito, quindi non posso usare sos.dll. Non ho visto alcun suggerimento utilizzando ~ e !teb.

2) C'è un modo per vedere quali oggetti COM sono stati creati in un file di dump? Ancora una volta, in un dump gestito, posso fare un !dumpheap per ottenere un elenco di oggetti gestiti. C'è qualcosa di simile che posso trovare per gli oggetti COM?

3) È possibile determinare il modello di thread degli oggetti COM nel file di dettagli?

Answer 1

Posso solo rispondere alla domanda 1. Utilizzare !runaway per trovare il thread o i thread che consumano la CPU. Per ottenere tutti gli stack di thread utilizzare ~*kb1000.

Answer 2

È possibile scaricare stato di thread utilizzando il comando:

~* 

questo non visualizzerà 'background' come uno stato, si vedrà soltanto correre, congelati o sospesa.

Non sono sicuro di come sia possibile ottenere informazioni dagli oggetti COM, non l'ho mai provato ma indagherò e tornerò da voi, per quanto riguarda il modello di threading sarà difficile da dedurre che senza il doloroso monitoraggio dello stato dell'applicazione dopo l'avanzamento attraverso e anche con quello, quando si passa attraverso tutti gli altri thread verrà eseguito a meno che non si usi .bpsync 1 che sincronizza tutti i thread a quello corrente, ma che potrebbe causare un blocco (ad esempio, il thread della GUI ora è stato detto di bloccare) quindi penso che sarà essere difficile a meno che non si abbia accesso al codice sorgente.