vazamento de memória do Windows 8.1 que é invisível no monitor de processo e poolmon

2

Depois de tentar por dias, pesquisando sobre tudo e tentando muito, fiquei sem noção.

Eu tenho um Razer 2013 Blade Pro com 8 GB de RAM. Eu tenho 30 GB alocados para o RAM virtual adicional.

Meu sistema come ram, depois de um dia eu tenho que reiniciar. Gerenciador de tarefas sempre mostra 7,6-7.8GB de 8GB usado (depois de um tempo) Mostra 10 GB comprometidos após meio dia. O conjunto paginado e não paginado é menor que um GB. em cache é menor que um GB Processos combinados são inferiores a GB.

Normalmente o 'poolmon' mostra que algo como um driver está usando a memória. No entanto, no meu caso, o poolmon não mostra nenhum uso extra de nada. Agora 12GB de espaço em disco e 8GB de memória real estão em uso e nada está sendo usado.

Então, essencialmente, minha pergunta é esta:
Se nem o gerenciador de tarefas nem o poolmon mostrarem perdas ou utilizações de memória, o que mais posso tentar descobrir O QUE está usando 20 GB de memória?

Poolmon -b:

     Memory: 8304828K Avail:  357404K  PageFlts:749759184   InRam Krnl:31464K P:248372K
 Commit:12798116K Limit:32880828K Peak:12958348K            Pool N:168816K P:303892K
 System pool information
 Tag  Type     Allocs            Frees            Diff       Bytes                  Per Alloc

 CM31 Paged     76680 (   0)     49859 (   0)    26821   122609664 (          0)        4571
 wcdl Nonp         43 (   0)         0 (   0)       43    32427744 (          0)      754133
 MmSt Paged    997690 (   0)    989424 (   0)     8266    28019248 (          0)        3389
 rzud Nonp     109134 (   0)     46163 (   0)    62971    15651296 (          0)         248
 CM25 Paged      3295 (   0)         0 (   0)     3295    14479360 (          0)        4394
 MmRe Paged     21218 (   0)     19623 (   0)     1595    14009152 (          0)        8783
 Toke Paged  12315343 (   0)  12310825 (   0)     4518     8803808 (          0)        1948
 ConT Nonp       1585 (   0)      1212 (   0)      373     6365184 (          0)       17064
 BGIK Paged         1 (   0)         0 (   0)        1     6221824 (          0)     6221824
 Thre Nonp     449909 (   0)    447365 (   0)     2544     5244384 (          0)        2061
 Ntff Paged    582079 (   0)    578052 (   0)     4027     5218992 (          0)        1296
 CM16 Paged      9083 (   0)      8010 (   0)     1073     4685824 (          0)        4367
 Irp  Nonp   75321006 (   0)  75307341 (   0)    13665     4645936 (          0)         339
 XENO Nonp        594 (   0)       399 (   0)      195     4317616 (          0)       22141
 ViMm Paged   1873388 (   0)   1862026 (   0)    11362     4057360 (          0)         357
 File Nonp   59994297 (   0)  59983847 (   0)    10450     3492864 (          0)         334

A única coisa incomum que vejo aqui é "pageflts", que é alta, depois do primeiro segundo de poolmon cai para 50k por atualização. Eu acho que isso indica algo, talvez apenas que algo está tentando obter memória em uma taxa insana.

Atualização: Eu não joguei, não alterei a resolução.

Atualização:imagensRammapcomphotoshopcarregado(5GBnamemóriadeprocesso): ImagensRammapcomphotoshopparado(amemóriaaindamostraestarcheia):

Também é estranho, além de 18 GB de memória confirmada que não são mostrados, o rammap mostra 5 GB em processos, o que também não é o caso.

P.S. Eu fiz uma varredura de rootkit malwarebytes sem nada. Essa é a única coisa que posso pensar, um grande bug no sistema operacional Windows sobre o uso de memória ou um rootkit de kernel.

    
por John 13.07.2014 / 00:05

2 respostas

1

Este é um problema de memória virtual DirectX no Windows 8, que é causado quando você executa aplicativos / jogos em uma resolução diferente em comparação à resolução da área de trabalho e em tela cheia.

Você deve ver um gráfico semelhante ao dente de serra no Process Explorer:

A Microsoft lançará uma correção para esse bug no Update Rollup de agosto de 2014. Então você tem que esperar mais 1 mês até que isso seja corrigido ou reproduzir / executar aplicativos sempre com a resolução nativa.

    
por 13.07.2014 / 09:20
0

Não vejo por que você está dizendo "5 GB em procs, o que não é o caso". Apenas a partir do procs que você mostrou (segundo snap na tela) eu vejo 3,1 GB. E o conjunto de trabalho privado de um processo não é seu único uso de RAM (o resto é para páginas compartilháveis). Parece-me que você está simplesmente executando um grande número de coisas famintas por memória ao mesmo tempo; A cura é executar menos deles, ou fazer menos com eles para que eles não precisem de muita memória RAM, ou então adicionar mais memória RAM.

Sua taxa de falhas de página alta também aponta nessa direção.

Comprometido não é mostrado nessa tabela porque não é "RAM", e o RAMmap tem tudo a ver com a contabilização do uso de RAM. A memória comprometida é um tipo de espaço de endereço virtual (os outros tipos, no espaço do usuário, são "mapeados" e "livres"). Algumas delas para cada proc estão na coluna "Private", o restante no arquivo de paginação.

Uma coisa que parece estranha é que você relata 8 GB de RAM + "30 GB alocados para memória RAM adicional virtual", pelo que eu acho que você quer dizer arquivo de paginação (caso contrário eu não sei o que você quer dizer). Isso deve resultar em um limite de confirmação de 38 GB, mas você está exibindo apenas 31,4 GB. Consertar isso não resolverá seu problema, já que você não está nem perto de ficar sem commit.

    
por 16.09.2014 / 00:17