Utilizzo di Pageheap.exe in Windows XP e in Windows 2000

Traduzione articoli Traduzione articoli
Identificativo articolo: 286470 - Visualizza i prodotti a cui si riferisce l?articolo.
Espandi tutto | Chiudi tutto

In questa pagina

Sommario

In questo articolo viene descritto come utilizzare lo strumento Pageheap.exe in Microsoft Windows XP e in Microsoft Windows 2000.

Informazioni

Pageheap.exe consente di impostare flag degli heap di pagina per agevolare l'individuazione di danni correlati agli heap. Può inoltre consentire il rilevamento di perdite nei programmi eseguiti in sistemi con Windows 2000 Professional Service Pack 2 (SP2) e Windows XP Professional.

Pageheap.exe introduce il livello di convalida software Page Heap Manager (gestore di heap di pagina) tra l'applicazione e il sistema per la verifica di tutte le operazioni dinamiche relative alla memoria, quali allocazioni, liberazioni e altre operazioni heap. Quando Page Heap Manager è attivato, l'applicazione sottoposta a verifica viene avviata con un debugger. Se viene rilevato un problema, il debugger viene interrotto.

Importante Con Pageheap.exe non viene specificato il tipo di bug ma il sistema si blocca se viene rilevato un problema. Con questo strumento viene attivato un livello di verifica già esistente nelle librerie di sistema Ntdll.dll in Windows 2000 Professional SP2 e Windows XP Professional. Pageheap.exe non funziona nelle versioni precedenti di Microsoft Windows.

Se l'applicazione sottoposta a verifica non viene avviata con un debugger e viene rilevato un errore, il sistema si blocca senza alcuna segnalazione.

Concetti

Uno dei problemi comuni nello sviluppo di applicazioni è il danneggiamento della memoria heap. Questo problema si verifica generalmente quando in un'applicazione viene allocato un blocco di memoria heap di una determinata dimensione e in seguito nella memoria vengono scritti indirizzi che superano la dimensione richiesta del blocco di heap. Il danneggiamento della memoria heap può verificarsi anche quando in un'applicazione viene effettuata una scrittura in un blocco di memoria che è già stato liberato.

Per comprendere i comandi correlati a Pageheap.exe e il relativo utilizzo, sono fondamentali due concetti:
  • I danni nei blocchi di heap vengono individuati inserendo una pagina non accessibile alla fine dell'allocazione oppure verificando i criteri di riempimento quando il blocco viene liberato.
  • Per ogni heap creato all'interno di un processo in cui è abilitato l'heap di pagina, esistono due heap: heap di pagina intera e heap di pagina normale.
    • L'heap di pagina intera consente di individuare i danni nei blocchi di heap inserendo una pagina non accessibile alla fine dell'allocazione. Il vantaggio di questo approccio consiste nella possibilità di ottenere un "blocco immediato". In altre parole, il processo determinerà una violazione di accesso nel punto esatto dell'errore. Questo comportamento agevola il debug degli errori. Lo svantaggio è dato dal fatto che per ogni allocazione viene utilizzata almeno una pagina di memoria vincolata. Nel caso di un processo che prevede un utilizzo intensivo della memoria, è possibile che le risorse si esauriscano rapidamente.
    • L'heap di pagina normale può essere utilizzato nei casi in cui le limitazioni di memoria impediscano l'utilizzo di heap di pagina intera. Al momento della liberazione di un blocco di heap vengono verificati i criteri di riempimento. Il vantaggio di questo metodo è dato dalla drastica riduzione del consumo di memoria. Lo svantaggio consiste nel fatto che i danni vengono rilevati solo quando il blocco viene liberato. In questo modo, il debug degli errori risulta più difficile.

Percorso di download per lo strumento Pageheap.exe

Per scaricare il pacchetto di strumenti di debug più aggiornato, fare clic sul collegamento seguente (informazioni in lingua inglese):
http://www.microsoft.com/whdc/devtools/debugging/default.mspx


Selezionare la versione più recente degli strumenti di debug. Al momento dell'installazione degli strumenti scegliere l'installazione personalizzata ed eseguirla in una directory con un nome appropriato, ad esempio C:\Debug o C:\Strumentididebug.

Scelta di un metodo per ottenere informazioni sui danni relativi ai blocchi di heap

La maggior parte dei danni nei blocchi di heap può essere individuata in uno dei due modi seguenti:
  • Heap di pagina intera: inserire una pagina non accessibile alla fine dell'allocazione.
  • Heap di pagina normale: verificare i criteri di riempimento quando il blocco viene liberato.

Heap di pagina intera

Dati gli elevati requisiti di memoria, l'heap di pagina intera deve essere attivato per singoli processi oppure con parametri limitati per i processi estesi. Non può essere attivato a livello di sistema poiché è difficile valutare la dimensione del file di paging richiesto. Utilizzando un file di paging troppo piccolo con heap di pagina intera a livello di sistema, viene impedito l'avvio del sistema.

Il vantaggio dell'heap di pagina intera è dato dal fatto che genera una violazione di accesso di un processo nel punto esatto dell'errore, rendendo più facile il debug dell'errore stesso. Per riuscire a individuare gli errori, utilizzare prima di tutto un heap di pagina normale per determinare l'intervallo in cui si verifica l'errore di un processo, quindi utilizzare l'heap di pagina intera su singoli processi su larga scala per tale classe limitata di allocazioni, vale a dire un determinato intervallo di dimensioni o una particolare libreria.

Heap di pagina normale

L'heap di pagina normale può essere utilizzato per verificare processi su vasta scala senza l'elevato consumo di memoria associato all'heap di pagina intera. Con questo tipo di heap, tuttavia, il rilevamento viene rinviato fino alla liberazione dei blocchi, rendendo così più difficoltose le operazioni di debug degli errori.

In genere, è consigliabile utilizzare l'heap di pagina normale per la verifica iniziale dei processi su vasta scala. In seguito, se vengono rilevati problemi, sarà possibile attivare l'heap di pagina intera per una classe limitata di allocazioni in tali processi.

L'heap di pagina normale può essere attivato a livello di sistema per tutti i processi. Si rivela molto utile nelle prove comparative in cui viene effettuata una convalida di sistema generale piuttosto che una verifica mirata su singoli componenti. Questo heap può essere attivato anche per un unico processo.

Utilizzo di GFlags con heap di pagina a livello di sistema

Lo strumento GFlags consente di attivare l'heap di pagina a livello di sistema. Affinché un comando GFlags abbia effetto, è necessario riavviare il computer dopo averlo eseguito.

Per attivare un heap di pagina normale a livello di sistema:
  1. Sulla riga di comando digitare: gflags -r +hpa

  2. Riavviare il computer.
Per disattivare l'heap di pagina normale a livello di sistema:
  1. Sulla riga di comando digitare: gflags -r -hpa

  2. Riavviare il computer.
Nota Quando si attiva l'heap di pagina non servono altre impostazioni GFlags. Se vengono attivate altre impostazioni apparentemente correlate all'heap, è possibile che vengano introdotti errori di heap di pagina a causa di conflitti tra Page Heap Manager e questi flag di heap "innocui".

Utilizzo di GFlags con heap di pagina per un singolo processo

È possibile attivare l'heap di pagina per verificare un processo specifico. Per effettuare questa operazione, attenersi alla seguente procedura:
  1. Al prompt dei comandi modificare la directory in cui sono stati installati gli strumenti di debug.
  2. Al prompt dei comandi digitare quanto segue, quindi premere INVIO:
    Gflags.exe ?p /enable lsass.exe
    Nota lsass.exe rappresenta il nome del processo che si desidera verificare mediante lo strumento Pageheap.exe.
  3. Quando non è più necessario il controllo dell'heap di pagina, disattivare tale funzionalità. Per effettuare questa operazione, digitare quanto riportato di seguito al prompt dei comandi e premere INVIO:
    Gflags.exe -p /disable lsass.exe
    Nota lsass.exe rappresenta il nome del processo che si desidera verificare mediante lo strumento Pageheap.exe.
  4. Per elencare tutti i programmi in cui è correntemente attiva la verifica mediante lo strumento Pageheap.exe, digitare quanto riportato di seguito al prompt dei comandi e premere INVIO:
    Gflags.exe -p

Allocazioni non allineate

Con i gestori di heap di Windows (tutte le versioni) le allocazioni di heap avevano sempre un indirizzo iniziale allineato a 8 byte (sulle piattaforme a 64 bit l'allineamento è a 16 byte). La stessa garanzia è offerta dal gestore di heap di pagina. Ciò risulta tuttavia impossibile se si desidera che la fine dell'allocazione si trovi esattamente alla fine di una pagina. L'allocazione esatta a fine pagina è necessaria affinché un errore di scostamento di un byte determini una lettura o scrittura nella pagina non accessibile e generi un errore immediato.

Se la dimensione richiesta dall'utente per il blocco non è allineata a 8 byte, l'heap di pagina non è in grado di soddisfare i vincoli "indirizzo iniziale allineato a 8 byte" e "indirizzo finale allineato alla pagina". La soluzione consiste nel soddisfare il primo vincolo e fare in modo che l'inizio del blocco sia allineato a 8 byte, quindi utilizzare un piccolo criterio di riempimento tra la fine del blocco e l'inizio della pagina non accessibile. Questo criterio di riempimento può essere di lunghezza compresa tra 0 e 7 byte in architetture a 32 bit. Il criterio di riempimento viene verificato al momento della liberazione.

Se è necessario un rilevamento errori immediato per queste allocazioni, che altrimenti avrebbero un criterio di riempimento alla fine, fare in modo che il gestore di heap di pagina ignori la regola dell'allineamento a 8 byte e allinei sempre la fine dell'allocazione a un limite di pagina utilizzando i parametri /unaligned e /full. Per ulteriori informazioni, vedere il parametro /unaligned.

NOTA: alcuni programmi prevedono l'allineamento a 8 byte e smettono di funzionare correttamente con il parametro /unaligned. Microsoft Internet Explorer è uno di tali programmi.

Pagine non vincolate per le allocazioni di heap di pagina intera

Per ogni allocazione inferiore a una pagina, l'implementazione principale di heap di pagina intera prevede due pagine: una utilizzata per l'allocazione utente, l'altra resa non accessibile alla fine del buffer.

I sovraccarichi di fine buffer possono essere rilevati utilizzando un'area di spazio virtuale riservato anziché una pagina vincolata non accessibile. Quando il processo giunge a tale spazio virtuale riservato, si verifica un'eccezione di violazione di accesso. Questo metodo consente di ridurre fino al 50% il consumo di memoria. Per ulteriori informazioni, vedere il parametro /decommit.

Inserimento di errori

È possibile controllare Page Heap Manager in modo che in alcune allocazioni vengano inseriti deliberatamente degli errori. Questo si rivela utile durante la simulazione di condizioni di memoria insufficiente senza utilizzare effettivamente tutte le risorse di sistema.

Specificare un numero da 1 a 10.000 che indichi la probabilità che un'allocazione abbia esito negativo. Utilizzando una probabilità di 10.000, il 100% delle allocazioni avrà esito negativo. Una probabilità di 2.000 indica che circa il 20% delle allocazioni avrà esito negativo.

Con il gestore di heap di pagina si evita che vengano inseriti errori nei primi 5 secondi del processo e nei percorsi di codice del caricatore di Windows NT, ad esempio LoadLibrary e FreeLibrary. Se 5 secondi non sono sufficienti per l'avvio completo del processo, è possibile specificare un timeout più lungo all'inizio del processo. Per ulteriori informazioni, vedere il parametro /fault.

Quando si utilizza il parametro /fault e nel processo sottoposto a verifica è presente un bug, viene generata un'eccezione. In genere questo si verifica perché l'operazione di allocazione ha restituito un valore NULL e in seguito l'applicazione tenta di accedere alla memoria allocata. Dato che l'allocazione ha avuto esito negativo, è tuttavia impossibile accedere alla memoria e pertanto si verifica una violazione di accesso.

L'eccezione viene generata anche se l'applicazione tenta di gestire l'errore di allocazione senza rilasciare alcune risorse. Questo problema si manifesta sotto forma di perdita di memoria ed è più difficile da sottoporre a debug.

Per agevolare la diagnosi di questi errori, nel gestore di heap di pagina viene mantenuta una registrazione cronologica delle tracce nello stack dal momento dell'inserimento dell'errore. Queste tracce possono essere visualizzate con il seguente comando del debugger:

!heap -p -f [NUMBER-OF-TRACES]

Per impostazione predefinita, nell'estensione vengono visualizzate solo le ultime quattro tracce.

Collegamento automatico di un debugger all'avvio dell'applicazione

Alcune applicazioni sono difficili da avviare da un prompt dei comandi oppure vengono generate da altri processi. Per queste applicazioni, specificare il collegamento automatico di un debugger all'avvio. Questo risulta utile se l'heap di pagina è attivato per tale processo e si verificano errori di heap. Per ulteriori informazioni, vedere il parametro /debug.

Pageheap.exe è efficace quando viene utilizzato per verificare un processo di allocazione di memoria, comprese le allocazioni di tipo C++ new e delete, purché dalle funzioni di allocazione/liberazione personalizzate vengano effettuate chiamate alle interfacce di gestione degli heap di NT, ossia RtlAllocateHeap e RtlFreeHeap. Le funzioni indicate di seguito garantiscono questo risultato:
  • Funzioni come HeapAlloc, HeapFree, HeapReAlloc: vengono esportate da kernel32.dll ed effettuano chiamate direttamente alle interfacce heap di NT. Funzioni come GlobalAlloc, GlobalFree, GlobalReAlloc: vengono esportate da kernel32.dll ed effettuano chiamate direttamente o indirettamente alle interfacce degli heap di NT.
  • Funzioni come LocalAlloc, LocalFree, LocalReAlloc: vengono esportate da kernel32.dll ed effettuano chiamate direttamente o indirettamente alle interfacce degli heap di NT.
  • Le funzioni malloc, free, realloc, msize, expand: queste funzioni vengono esportate da msvcrt.dll ed effettuano chiamate direttamente o indirettamente all'heap di NT. La situazione non è sempre stata questa. Nell'ambiente runtime C era presente una diversa implementazione di heap, mentre nell'attuale ambiente runtime C vengono effettuate chiamate direttamente all'heap di NT.
  • Operatori new, delete, new[ ], delete[ ]: queste funzioni vengono esportate da msvcrt.dll ed effettuano chiamate direttamente o indirettamente all'heap di NT.
Qualunque altro insieme di allocazioni/liberazioni costituisce probabilmente uno schema personalizzato ed effettuerà necessariamente chiamate direttamente o indirettamente all'heap di NT. L'effettiva implementazione può essere rivelata solo attraverso l'ispezione del codice sorgente o l'esecuzione con un debugger.

Evitare l'utilizzo di collegamenti statici. Alcune applicazioni sono state collegate staticamente a versioni precedenti dell'ambiente runtime C. Queste versioni precedenti non richiamano le API dell'heap di Windows NT e non è possibile utilizzare Pageheap.exe per verificare tali allocazioni. Il collegamento dinamico consente di ottenere la libreria di runtime C più aggiornata (msvcrt.dll).

Classi di errori rilevati da Pageheap.exe

Con Pageheap.exe viene rilevata la maggior parte degli errori relativi agli heap, ma con particolare attenzione ai problemi di danneggiamento della memoria heap piuttosto che alle perdite. Sebbene disponga di funzionalità a questo scopo, Pageheap.exe è limitato nell'individuazione di perdite di heap.

Uno dei vantaggi di Pageheap.exe è dato dal fatto che molti errori vengono rilevati nel momento in cui si verificano. Ad esempio, un errore di scostamento di un byte alla fine di un buffer allocato dinamicamente può causare una violazione di accesso immediata. Esistono pochi tipi di errore che non possono essere rilevati nel momento in cui si verificano. In questi casi, la segnalazione degli errori viene rimandata fino alla liberazione del blocco.
  • Puntatore di heap non valido: tutte le interfacce di heap a livello di Win32 e Windows NT assumono come primo parametro un puntatore all'heap in cui dovrebbe avvenire l'operazione. Tramite il gestore di heap di pagina viene rilevato un puntatore di heap non valido nel momento in cui viene effettuata la chiamata.
  • Puntatore di blocco di heap non valido: una volta allocato, un blocco può essere utilizzato come parametro per diverse interfacce di heap, in particolare la classe di interfacce free(). Il gestore di heap di pagina rileva immediatamente un puntatore di blocco di heap non valido. Per informazioni su come determinare se l'indirizzo non valido è scostato di alcuni byte o è completamente errato, fare riferimento alla sezione Debug di errori relativi agli heap di pagina.
  • Accesso multithread non sincronizzato all'heap: alcune applicazioni effettuano chiamate verso un heap da più thread. Questo tipo di scenario richiede l'impostazione di un indicatore da parte dell'utente, che determinerà l'acquisizione di un blocco di heap. Il gestore di heap di pagina rileva questo tipo di violazione quando due thread contemporaneamente tentano di effettuare una chiamata all'heap.
  • Ipotesi relative alla riallocazione di un blocco allo stesso indirizzo: in seguito a un'operazione di riallocazione non viene restituito necessariamente lo stesso indirizzo, soprattutto quando la riallocazione riduce la dimensione del blocco. Per alcune applicazioni si presume che la riallocazione restituisca lo stesso indirizzo. Il gestore di heap di pagina alloca sempre un nuovo blocco durante una riallocazione, liberando il blocco precedente. Il blocco libero viene protetto dall'accesso in lettura/scrittura e pertanto qualsiasi accesso genererà una violazione di accesso.
  • Doppia liberazione: si tratta di un bug comune in molte applicazioni, che si verifica quando gli stessi blocchi di heap vengono liberati più volte. Questo errore viene rilevato immediatamente dal gestore di heap di pagina poiché, al momento della seconda liberazione, il blocco risulterà privo dell'intestazione di prefisso appropriata e quindi irreperibile tra i blocchi allocati. Per informazioni sui metodi per analizzare le tracce nello stack della prima operazione di liberazione, fare riferimento alla sezione Debug di errori relativi agli heap di pagina. Questo errore può essere una variante del problema della riallocazione dato che, quando nell'applicazione viene liberato ciò che è ritenuto l'indirizzo del blocco, tale blocco era già stato liberato nel contesto della riallocazione.
  • Accesso al blocco dopo la liberazione: i blocchi di memoria liberati vengono mantenuti per un breve periodo dal gestore di heap di pagina in un pool di memoria protetta. Qualsiasi accesso a tali blocchi genererà una violazione di accesso. In base al principio di "località", se il pool protetto libero è sufficientemente ampio, dovrebbe essere possibile individuare la maggior parte dei problemi. Se il blocco liberato si trova ancora nel pool protetto, il bug viene rilevato immediatamente. Tuttavia, se la memoria è stata riutilizzata, è meno probabile che venga individuato il bug o che venga identificato il codice che lo ha causato.
  • Accesso dopo la fine del blocco allocato: il gestore di heap di pagina inserisce una pagina inaccessibile immediatamente dopo il blocco allocato. Qualsiasi accesso dopo la fine del blocco genererà una violazione di accesso. In alcune applicazioni è previsto che le allocazioni siano allineate a 8 byte. Questa caratteristica è supportata a partire dai gestori di heap di Windows NT 3.5. Una dimensione di richiesta non allineata a 8 byte otterrà comunque un indirizzo allineato a 8 byte, ma lasciando alcuni byte non accessibili dopo la fine del blocco. Se l'applicazione danneggia solo questi pochi byte, l'errore verrà rilevato solo verificando il criterio del suffisso del blocco quando il blocco viene liberato.
  • Accesso prima dell'inizio del blocco allocato: mediante un flag impostabile è possibile impostare il gestore di heap di pagina in modo che venga inserita la pagina non accessibile all'inizio del blocco anziché alla fine. Qualsiasi accesso prima dell'inizio del blocco genererà una violazione di accesso.
Riduci questa tabellaEspandi questa tabella
ErroreHeap di pagina normaleHeap di pagina intera
Puntatore di heap non validoRilevamento immediatoRilevamento immediato
Puntatore di blocco di heap non validoRilevamento immediatoRilevamento immediato
Accesso non sincronizzatoRilevamento immediatoRilevamento immediato
Ipotesi sull'indirizzo di riallocazione90% fino a effettiva liberazione90% rilevamento immediato
Doppia liberazione90% rilevamento immediato90% rilevamento immediato
Riutilizzo dopo liberazione90% fino a effettiva liberazione90% rilevamento immediato
Accesso dopo la fine del bloccoRilevamento alla liberazioneRilevamento immediato
Accesso prima dell'inizio del bloccoRilevamento alla liberazioneRilevamento immediato (flag speciale)

Debug degli errori relativi agli heap di pagina

Per ulteriori informazioni sul debug di errori relativi agli heap di pagina, fare riferimento a Application Compatibility Tookit Reference disponibile in Application Compatibility Toolkit.

Per la Sintassi di Pageheap.exe ed esempi di utilizzo di Pageheap.exe, fare riferimento a Application Compatibility Tookit Reference disponibile in Application Compatibility Toolkit.

Per ulteriori informazioni, vedere il seguente articolo della Microsoft Knowledge Base:
294895 Descrizione di Application Compatibility Toolkit 2.0 per Windows XP

Proprietà

Identificativo articolo: 286470 - Ultima modifica: martedì 23 gennaio 2007 - Revisione: 4.1
Le informazioni in questo articolo si applicano a
  • Microsoft Windows Server 2003, Standard Edition (32-bit x86)
  • Microsoft Windows Server 2003, Enterprise Edition (32-bit x86)
  • Microsoft Windows Server 2003, Datacenter Edition (32-bit x86)
  • Microsoft Windows XP Professional
  • Microsoft Windows XP Home Edition
  • Microsoft Windows 2000 Professional Edition
  • Microsoft Windows 2000 Server
  • Microsoft Windows 2000 Advanced Server
  • Microsoft Windows 2000 Datacenter Server
Chiavi: 
kbinfo kbenv KB286470
LE INFORMAZIONI CONTENUTE NELLA MICROSOFT KNOWLEDGE BASE SONO FORNITE SENZA GARANZIA DI ALCUN TIPO, IMPLICITA OD ESPLICITA, COMPRESA QUELLA RIGUARDO ALLA COMMERCIALIZZAZIONE E/O COMPATIBILITA' IN IMPIEGHI PARTICOLARI. L'UTENTE SI ASSUME L'INTERA RESPONSABILITA' PER L'UTILIZZO DI QUESTE INFORMAZIONI. IN NESSUN CASO MICROSOFT CORPORATION E I SUOI FORNITORI SI RENDONO RESPONSABILI PER DANNI DIRETTI, INDIRETTI O ACCIDENTALI CHE POSSANO PROVOCARE PERDITA DI DENARO O DI DATI, ANCHE SE MICROSOFT O I SUOI FORNITORI FOSSERO STATI AVVISATI. IL DOCUMENTO PUO' ESSERE COPIATO E DISTRIBUITO ALLE SEGUENTI CONDIZIONI: 1) IL TESTO DEVE ESSERE COPIATO INTEGRALMENTE E TUTTE LE PAGINE DEVONO ESSERE INCLUSE. 2) I PROGRAMMI SE PRESENTI, DEVONO ESSERE COPIATI SENZA MODIFICHE, 3) IL DOCUMENTO DEVE ESSERE DISTRIBUITO INTERAMENTE IN OGNI SUA PARTE. 4) IL DOCUMENTO NON PUO' ESSERE DISTRIBUITO A SCOPO DI LUCRO.

Invia suggerimenti

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com