Mi dispiace, so che sembra una risposta irriverente ... ma la risposta alla domanda nel tuo titolo è "perché non dovrebbero".
O per dirla in modo più educato: c'è molto uso della RAM che non si trova nei set di lavoro privati dei processi. Alcuni di questi sono nei set di lavoro condivisi dei processi, ma non è possibile avere un'idea affidabile dell'uso effettivo lì, a causa della condivisione; sommare i numeri dei processi ti darà un risultato fin troppo grande.
Altre cose che occupano la RAM, come il pool non di paging, la porzione residente del pool di paging e le parti residenti di altri usi dello spazio del kernel, non vengono affatto visualizzate nella schermata dei "processi" di Task Manager.
Per quanto riguarda il problema specifico:
Sul display del Task manager, vedi la sezione "memoria del kernel"? Hai 6 GB di "memoria non di paging" (ovvero pool non di paging). Fa parte della sezione "In uso" nel secondo grafico. Il pool non di paging non viene addebitato a nessun processo, motivo per cui l'aggiunta dei numeri per processo nel Task Manager non si avvicina al totale in uso. È probabile che alcuni driver lo stiano utilizzando. Questa è una quantità totalmente eccessiva; dovrebbe essere ben al di sotto di 1 GB. qualunque driver sia responsabile della parte eccessiva dell'utilizzo del pool non di paging è senza dubbio un bug.
RAMmap può confermarlo (nella scheda "Usa conteggi", guarda il totale di "Pool non di paging") ma non può aiutarti a trovare quale driver lo sta causando.
Ecco come trovarlo: ottenere una copia dello strumento Microsoft "poolmon". È uno strumento in modalità personaggio (ragazzo, mai) distribuito con Windows Driver Kit. Per Windows 7 il WDK è un download gratuito . Devi scaricare il tutto (è un ISO) e installarlo da quello, ma puoi scegliere di installare solo gli strumenti, se è tutto ciò che vuoi.
Trova poolmon nelle directory WDK - assicurati di scegliere quello giusto, a 32 o 64 bit - ed eseguilo dal prompt dei comandi dell'amministratore. Otterrai un display come questo:
Ora, premi il tasto "p" (no, non sto scherzando. Nessun menu qui!) Fino a quando la colonna "Tipo" mostra solo "Nonp". Quindi premere "b" (due volte se necessario) per ordinare la visualizzazione in ordine decrescente dalla colonna Byte (che era già stato fatto nell'esempio qui).
Quindi osserva la colonna "Tag" per la riga più in alto. Nel caso (ovviamente artificiale) mostrato qui è "Perdita". (Questo sistema esegue un driver che è stato deliberatamente corretto per causare questo problema: si tratta di un pool non di paging "con perdite").
tra l'altro, le linee evidenziate sono quelle modificate dal precedente aggiornamento a questa schermata arcaica.
Ora cerca c: \ Windows \ System32 \ Drivers per un file .sys contenente quella stringa. In questo caso dovresti cercare "Perdita", in questo modo:
c:\windows\system32> findstr /s Leak *.sys
Quindi cerca nel web i riferimenti a quella stringa e / o al nome del driver.
Tornare qui e riportare il nome completo, il nome del produttore, ecc. Dal file .sys sarebbe utile.
(La mia scommessa è che il tag che troverai sarà ECMC, il driver è intmsd.sys ed è associato a un prodotto chiamato ExpressCache o IntelliMemory. Vorrei "disinstallare" quel prodotto. C'è un aggiornamento per risolvere il problema, ma anche con la versione fissa non ho mai visto le prestazioni di un sistema migliorate da questo prodotto; essenzialmente duplica la funzionalità che è già in Windows.)
Se non riesci a trovarlo in questo modo, il passaggio successivo consiste nell'utilizzare "Windows Performance Toolkit". Cerca in questo forum quella stringa, con le risposte di magicandre1981, per un tutorial. Ignora le risposte che menzionano xperf: è una versione precedente dello strumento.
AGGIORNAMENTO: Secondo i commenti, l'OP ha fatto quanto sopra e ha scoperto che sebbene il poolmon riferisse che la dimensione totale del pool non di paging era davvero enorme, tutti i pezzi assegnati erano apparentemente minuscoli. La mia congettura (anche nei commenti) è che ciò è dovuto a quello che chiamerò pool "gonfio": il pool è stato allocato, quindi liberato, ma per qualche ragione quella quantità di RAM allocata al pool non è stata ridotta per riflettere il "liberazione" . Seguendo la procedura descritta in questa risposta da magicandre può identificare il colpevole.
