2009-05-06 13 views
5

Ho riscontrato un alto grado di sfarfallio e ritardo dell'interfaccia utente in una piccola applicazione che ho sviluppato per testare un componente che ho scritto per una delle nostre applicazioni. Dato che lo sfarfallio e il rallentamento si stavano verificando durante il tempo di inattività (quando non si doveva seriamente fare nulla), decisi di fare qualche indagine. Ho notato alcuni thread nella finestra Thread di cui non ero a conoscenza (non del tutto inaspettato), ma quello che ha attirato la mia attenzione era che uno dei thread era impostato sulla priorità Highest. Questo thread esiste al momento in cui viene chiamato Main(), anche prima dell'esecuzione del mio codice. Ho scoperto che questo thread sembra essere presente in ogni applicazione .NET che scrivo, anche nelle applicazioni della console.Determinazione dell'origine di una discussione

Essendo l'anima audace che sono, ho deciso di congelare il filo e vedere cosa è successo. Lo sfarfallio si è effettivamente fermato, ma ho sperimentato un po 'di stranezza quando si trattava di fare interazione con il database (sto usando SQL CE 3.5 SP1). Pensavo che questo potesse essere il thread su cui il database è effettivamente in esecuzione, ma considerando che è iniziato nel momento in cui l'applicazione carica (prima di ogni riferimento al DB) ed è presente in altre applicazioni non di database, sono incline credere che questo non sia il caso.

Poiché questo thread (come pochi altri) si presenta senza dati nella colonna Posizione e nessun elenco chiamate elencato se si passa ad esso nel debugger mentre si è in pausa, ho provato ad associare la proprietà StartAddress tramite GetCurrentProcess(). per il thread corrispondente, ma non rientra in tutti gli intervalli di indirizzi dei moduli attualmente caricati.

Qualcuno ha idea di cosa sia questo thread o di come potrei scoprirlo?

Modifica

Dopo aver fatto qualche scavo, sembra che la StartAddress è in kernel32.dll (in base al contenuto della memoria vicini). Questo mi porta a pensare che questa sia solo la funzione di sistema standard utilizzata per avviare il thread, in base allo this page, che in pratica mi riporta al punto di partenza per determinare da dove proviene effettivamente questo thread. Ciò è ulteriormente confermato dal fatto che TUTTI i thread in questa lista hanno lo stesso valore per StartAddress, che mi porta a chiedere esattamente quale sia lo scopo ...?

Edit 2

Process Explorer mi ha lasciato a un indirizzo di partenza in realtà significativa. Sembra che sia mscorwks.dll!CreateApplicationContext+0xbbef. Questa DLL è in% WINDOWS% \ Microsoft.NET \ Framework \ v2.0.50, quindi sembra che sia chiaramente un assembly di runtime. Io non sono ancora sicuro perché

  • suo massimo priorità
  • sembra essere la causa singhiozzo nella mia applicazione
+0

Il thread di Finalizer è impostato per l'esecuzione sulla priorità più alta. –

risposta

6

Si potrebbe provare a utilizzare Sysinternals. Process Explorer scendiamo piuttosto in profondità. Fare clic con il tasto destro del mouse sul processo per accedere alle proprietà. Quindi la scheda "Discussioni". Qui puoi vedere lo stack e il modulo del thread.

EDIT:

Dopo asking attorno ad alcuni, sembra che il "più alto" thread con priorità è il filo Finalizer che corre a causa di una garbage collection.Non ho ancora una buona ragione per cui continuerebbe a funzionare costantemente. Forse hai qualche comportamento funky dell'oggetto durante il processo?

2

non sono sicuro di cosa si tratta, ma se attivare il debug non gestito e imposta Visual Studio con lo Windows symbol server, potresti ottenere qualche indizio in più.

+0

Il GC era qualcosa a cui avevo pensato, ma non riuscivo davvero a pensare al motivo per cui sarebbe stato impostato su Massima (non vigilia AboveNormal, ma ALTA). –

+0

Pensavo che il GC funzionasse con un thread con priorità bassa. Dove hai visto che viene eseguito su un thread ad alta priorità? –

+0

Oops, hai ragione. Lo rimuoverò. –

0

Potrebbe essere il thread Garbage Collector. L'ho notato anche quando stavo studiando un bug relativo al finalizzatore. Forse la memoria del tuo sistema è bassa e il GC sta cercando di raccogliere tutto il tempo? Questo era anche il caso del bug precedentemente citato. Non riuscivo a riprodurlo sulla mia macchina, ma un mio collega aveva una macchina con meno RAM in cui sarebbe riapparso come un orologio.

Problemi correlati