Avvia RAMMap come amministratore, annota Total, Active, Standby, Modified, Free e le righe principali di Use Counts, quindi salva uno snapshot. Ripeti una sola azione a intervalli fissi e aggiorna con F5. Una probabile perdita cresce in modo ripetibile, non si stabilizza a riposo e riduce la memoria disponibile o aumenta il commit. RAMMap identifica la classe; Process Explorer, VMMap, PoolMon o WPR identificano il proprietario.
Separare una perdita dalla normale pressione di memoria
Windows usa la RAM libera come cache e standby. Un utilizzo elevato può essere sano se le pagine sono recuperabili. Una perdita continua a crescere a checkpoint comparabili, resta allocata dopo il lavoro e aumenta commit, paging o latenza.
Non leggere solo Total. Confronta Active, Standby e Modified. Molto Standby è spesso cache recuperabile; Process Private o pool attivi in crescita sono indizi più forti. Controlla anche la memoria committed in Gestione attività.
| Osservazione | Spesso normale | Segnale più forte |
|---|---|---|
| Avvio del carico | Sale e si stabilizza | Sale a ogni ripetizione identica |
| Fine del carico | Si libera o passa a cache | Resta allocata e continua a crescere |
| Memoria disponibile | Resta sufficiente | Scende mentre cresce il commit |
| Proprietario | App o cache prevista | Processo, tag pool o file cresce senza lavoro utile |
| Dopo riavvio | Il warm-up si stabilizza | Gli stessi passi riproducono crescita illimitata |
Salvare una baseline RAMMap pulita
Chiudi applicazioni estranee e sospendi aggiornamenti, backup, download e VM. Avvia RAMMap come amministratore, attendi la quiete, premi F5 e registra Use Counts, Active, memoria disponibile, commit e ora. Salva uno snapshot prima del carico sospetto.
Mantieni uguali versione, file, profilo e attesa. Più variabili cambiate insieme rendono il delta inutile. Non svuotare la cache tra checkpoint.
Seguire la categoria RAMMap che continua a crescere
Process Private porta di solito a un’app o servizio; Mapped File a File Summary e percorsi; i pool ai driver. Driver Locked, page table e large page hanno proprietari diversi.
Se due categorie salgono insieme, confronta il momento. Un’app può allocare memoria privata e scaldare la cache. Consulta i tipi di memoria RAMMap e la guida Process Private elevato.
- Process Private: ordina Processes, annota PID e variazione, verifica Private Bytes con Process Explorer o VMMap.
- Mapped File: ordina File Summary e conferma il percorso in File Details.
- Pool: registra la tendenza, trova il tag con PoolMon o WPR e associalo al driver firmato.
- Standby: trattalo come cache recuperabile salvo prova controllata contraria.
Confrontare checkpoint ripetibili e snapshot
Un buon test include baseline, almeno tre checkpoint uguali e un punto idle. Usa nomi descrittivi e registra azione e ora.
Fermati prima che il paging alteri il test. Se il pattern si ripete, riavvia solo l’app o servizio sospetto e ripeti. Il rilascio temporaneo indica proprietà, non una correzione definitiva.
- Salvare la baseline
Aggiornare, annotare memoria disponibile e commit e salvare.
- Ripetere un’azione
Eseguire una sola operazione definita.
- Catturare punti fissi
Salvare dopo prima, terza e quinta ripetizione.
- Aggiungere idle
Fermare il carico e vedere se il valore si stabilizza.
- Confermare il proprietario
Usare Process Explorer, VMMap, PoolMon o WPR.
Scegliere lo strumento giusto dopo RAMMap
RAMMap descrive la composizione fisica, non ogni stack di allocazione. Process Explorer conferma il processo, VMMap lo scompone, PoolMon segue i tag e WPR fornisce una timeline.
Conserva snapshot, PID, tag, percorso, passi e orari. Dump e trace possono contenere dati sensibili.
| Indizio | Strumento | Domanda |
|---|---|---|
| Process Private | Process Explorer | Quale processo o servizio possiede il commit? |
| Processo confermato | VMMap/profiler | Quale regione cresce? |
| Pool | PoolMon | Quale tag usa memoria kernel? |
| Driver/tempo | WPR | Quando inizia la crescita? |
| Mapped File | File Summary/Details | Quale file spiega le pagine? |
Evitare false soluzioni svuotando la cache
Empty Standby List elimina cache recuperabile, non commit privato o pool perso. Empty Working Sets può ridurre temporaneamente le pagine residenti senza rimuovere l’allocazione.
Usa Empty solo per esperimenti controllati. Aggiorna o riavvia il proprietario confermato e ripeti il test. RAMMap v1.63 del 26 marzo 2026 risultava ancora corrente nella verifica Microsoft del 30 luglio 2026.
Un grafico più basso dopo la pulizia non prova la correzione. Conserva prima la tendenza.
FAQ sulle perdite di memoria con RAMMap
RAMMap prova una perdita di un’app?
Mostra categoria e tendenza; per la fonte esatta serve spesso uno strumento di processo o driver.
Quale valore osservare?
La categoria Active che cresce con commit e calo della memoria disponibile.
Quanti snapshot servono?
Una baseline, più punti uguali e un punto idle.
Empty Standby List corregge una perdita?
No, elimina solo cache recuperabile.
Quale strumento dopo?
Process Explorer, VMMap, PoolMon o WPR secondo la categoria.
Scarica RAMMap v1.63 da Microsoft
Usa lo ZIP ufficiale corrente e salva una baseline prima di cambiare lo stato memoria.