FIX: Perdita di memoria durante la generazione di eccezioni da blocchi di eccezioni nidificati

Il presente articolo è stato tradotto tramite il software di traduzione automatica di Microsoft e non da una persona. Microsoft offre sia articoli tradotti da persone fisiche sia articoli tradotti automaticamente da un software, in modo da rendere disponibili tutti gli articoli presenti nella nostra Knowledge Base nella lingua madre dell’utente. Tuttavia, un articolo tradotto in modo automatico non è sempre perfetto. Potrebbe contenere errori di sintassi, di grammatica o di utilizzo dei vocaboli, più o meno allo stesso modo di come una persona straniera potrebbe commettere degli errori parlando una lingua che non è la sua. Microsoft non è responsabile di alcuna imprecisione, errore o danno cagionato da qualsiasi traduzione non corretta dei contenuti o dell’utilizzo degli stessi fatto dai propri clienti. Microsoft, inoltre, aggiorna frequentemente il software di traduzione automatica.

810178
Questo articolo è stato archiviato. L’articolo, quindi, viene offerto “così come è” e non verrà più aggiornato.
Sintomi
Quando un errore di eccezione viene generato da una clausola catch, il primo oggetto eccezione verrà una perdita.

Ad esempio, quando si verifica un errore durante l'esecuzione del programma si desideri utilizzare un'istruzione try catch per gestire l'eccezione. Tuttavia, se il codice che gestisce l'eccezione nella clausola catch genera un'altra eccezione, il primo oggetto eccezione non verrà eliminato dal garbage collector .NET Framework. Causando una perdita di memoria nel processo di chiamata.
Risoluzione
È disponibile una correzione supportata da Microsoft, che è tuttavia destinata esclusivamente alla correzione del problema descritto in questo articolo. Utilizzarla solo nei computer in cui si verifica questo problema specifico. È possibile che su questa correzione vengano eseguiti ulteriori test. Se non si è notevolmente interessati da questo problema, si consiglia pertanto di attendere il rilascio del prossimo service pack di .NET Framework che contiene questa correzione.

Per risolvere immediatamente il problema, contattare il Servizio Supporto Tecnico Clienti Microsoft per ottenere la correzione. Per un elenco completo di numeri di telefono del servizio supporto tecnico clienti Microsoft e per informazioni sui costi dell'assistenza, visitare il seguente sito Web Microsoft: Nota : in casi particolari, le spese normalmente addebitate per le chiamate al supporto tecnico potrebbero essere annullate qualora un addetto del supporto Microsoft determinare che uno specifico aggiornamento risolverà il problema. I costi di supporto tipica verranno applicati per eventuali ulteriori domande e problemi che non dovessero rientrare nello specifico aggiornamento in questione.

La versione in lingua inglese di questa correzione presenta gli attributi di file elencati nella tabella seguente (o successivi). Date e ore per questi file sono indicati nella coordinated universal time (UTC). Quando si visualizzano le informazioni sul file, viene convertito in ora locale. Per calcolare la differenza tra ora UTC e l'ora locale, utilizzare la scheda fuso orario dello strumento Data e ora del Pannello di controllo.
   Date         Time   Version       Size       File name   --------------------------------------------------------------   16-Nov-2002  04:05  1.0.3705.378     69,632  Corperfmonext.dll   16-Nov-2002  14:28  1.0.3705.378  1,953,792  Mscorlib.dll   16-Nov-2002  03:56                   10,272  Mscorlib.ldo   16-Nov-2002  04:04  1.0.3705.378  2,269,184  Mscorsvr.dll   16-Nov-2002  04:04  1.0.3705.378  2,269,184  Mscorwks.dll

Informazioni

Procedura per riprodurre il problema.

Nota Di seguito è riportato informazioni minime relative a illustrare il problema descritto in questo articolo.

Per riprodurre il problema, includere il seguente codice in un progetto di Visual C#. NET, e quindi eseguirla direttamente (non nell'IDE o in qualsiasi altro debugger):
for (;;){	try	{		throw new System.Exception("I leak.");	}	catch	{		try		{			throw new System.Exception("I do not leak.");		}		catch		{		}	}	Console.Write("Press ENTER to iterate.");	Console.ReadLine();}
Si noterà che il codice delle perdite di handle di insieme garbage 2 per ogni iterazione.

È possibile controllare questo comportamento esaminando i seguenti contatori PerfMon:
  • Memoria CLR .NET / byte in tutti gli heap aumentano per ogni iterazione
  • CLR Memoria - handle GC # incrementati di 2 per ogni iterazione
Per ulteriori informazioni sull'utilizzo di PerfMon, fare clic sul numero dell'articolo della Microsoft Knowledge Base riportato di seguito riportato:
248345Creazione di un registro utilizzando Monitor di sistema in Windows 2000
Status
Microsoft ha confermato che questo problema riguarda i prodotti Microsoft elencati all'inizio di questo articolo.

Avviso: questo articolo è stato tradotto automaticamente

Proprietà

ID articolo: 810178 - Ultima revisione: 01/29/2014 19:41:04 - Revisione: 2.4

  • Microsoft .NET Framework 1.0 Service Pack 2
  • kbnosurvey kbarchive kbmt kbhotfixserver kbqfe kbnetframe100presp3fix kbfix kbbug KB810178 KbMtit
Feedback