Processeur 24 cœurs, mais je ne peux pas taper un e-mail

Je n'ai pas cherché d'ennuis. Je n'ai pas commencé mille fois le processus de création de Chrome au cours du week-end , mais je n'ai effectué que les tâches les plus courantes du 21e siècle - je viens d'écrire un e-mail à 10h30 du matin. Et soudain, Gmail s'est accroché. J'ai continué à imprimer pendant quelques secondes, mais aucun caractère n'est apparu à l'écran. Puis soudainement, Gmail s'est affaissé et je suis retourné à mon e-mail très important . Mais plus tard, tout s'est répété, mais cette fois, Gmail n'a plus répondu aux demandes. C'est étrange ...

Il est difficile de résister à l'opportunité de mener une bonne enquête, mais dans ce cas, le défi est particulièrement important. Après tout, je travaille chez Google pour améliorer les performances de Chrome pour Windows. Découvrir la cause du gel est mon travail . Et après beaucoup de faux départs et de dur labeur, j'ai quand même réussi à découvrir comment Chrome, Gmail, Windows et notre service informatique m'ont empêché ensemble de taper un e-mail. En cours de route, il y avait un moyen d'économiser une quantité importante de mémoire pour certaines pages Web dans Chrome.

Il y avait tellement de nuances dans l'enquête que je vais en laisser un autre pour un article , et maintenant je vais expliquer en détail les raisons des suspensions.

Comme d'habitude, UIforETW fonctionne en arrière-plan et surveille les tampons circulaires, j'ai donc juste eu à taper Ctrl + Win + R - et les tampons ont été enregistrés sur le disque pendant environ les trente dernières secondes d'activité du système. Je les ai téléchargés dans Windows Performance Analyzer (WPA), mais je n'ai pas pu installer définitivement le gel.

Lorsque le programme Windows cesse d'envoyer des messages, des événements ETW sont lancés indiquant exactement où cela s'est produit , il est donc trivial de trouver ces types de blocages. Mais apparemment, Chrome a continué d'envoyer des messages. J'ai cherché un moment où l'un des principaux flux Chrome est entré dans le cycle actif ou était complètement inactif, mais n'a rien trouvé d'explicite. Il y avait des endroits où Chrome restait essentiellement inactif, mais même alors, tous les threads clés continuaient de fonctionner, vous ne pouviez donc pas être sûr où le blocage s'était produit - Chrome pouvait simplement rester inactif en l'absence d'événements:



UIforETW a un enregistreur de frappe intégré, qui est souvent utile pour identifier les points clés dans une trace. Cependant, pour des raisons de sécurité évidentes, il rend par défaut les frappes anonymes, traitant chaque numéro entré comme «1» et chaque lettre comme «A». Cela rend difficile de trouver le moment exact du gel, j'ai donc changé le type de trace de «privé» à «complet» et je m'attendais à un gel. Vers 10h30 le lendemain matin, le raccrochage s'est répété. J'ai enregistré les tampons de trace et enregistré cette marque dans le champ d'informations de trace UIforETW:

Il a tapé «reporter pour ceux qui ont plus d'expérience avec la plongée sous-marine» - et Gmail a fait une pause à la fin du mot «ceux», puis a repris le travail dans le domaine du mot «expérience». Onglet Gmail avec PID 27368.

Il s'agit d'une discussion courante sur les moyens de se rendre au bureau , mais il est important qu'il existe maintenant un moyen de trouver un blocage dans la trace ETW. Je charge la trace, regarde les données de l'enregistreur de frappe dans le champ Événements génériques (les événements sont émis par UIforETW eux-mêmes, et chacun est un losange violet dans la capture d'écran ci-dessous) - et je vois immédiatement où le blocage s'est produit, avec lequel la défaillance de l'utilisation du processeur est clairement corrélée:



D'accord, mais pourquoi Chrome s'est-il arrêté? Voici quelques conseils: les captures d'écran ne montrent pas que chaque fois que WmiPrvSE.exe utilise pleinement l'hyperthread du processeur. Mais cela ne devrait pas avoir d'importance. Ma machine a 24 cœurs / 48 threads, donc la consommation d'un hyper-thread signifie que le système est toujours gratuit à 98%.

Puis j'ai approché une période clairement importante où Chrome était inactif - et j'ai regardé, en particulier, le processus CrRendererMain dans chrome.exe (27368), correspondant à l'onglet Gmail.

Remarque: Je tiens à me remercier de 2015 pour avoir demandé à Microsoft d'améliorer les mécanismes de dénomination des flux, et merci à Microsoft d'avoir mis en œuvre toutes les suggestions - les noms de threads dans WPA sont tout simplement géniaux!

Le problème s'est éclairci. Lors d'un blocage de 2,81 secondes, ce thread a été démarré 440 fois. En règle générale, le démarrage toutes les 6 ms est suffisant pour rendre le programme réactif, mais pour une raison quelconque, cela ne s'est pas produit. J'ai remarqué que chaque fois qu'il se réveillait, il était sur la même pile. Pour simplifier:

chrome_child.dll (stack base)
KernelBase.dll!VirtualAlloc
ntoskrnl.exe!MiCommitVadCfgBits
ntoskrnl.exe!MiPopulateCfgBitMap
ntoskrnl.exe!ExAcquirePushLockExclusiveEx
ntoskrnl.exe!KeWaitForSingleObject (stack leaf)

Chrome VirtualAlloc, “CfgBits” . , Chrome VirtualAlloc 440 , . . Chrome VirtualAlloc — . Chrome ,  — 439  — Chrome , . , .

Windows — , , . . .

, Chrome , WmiPrvSE., :

ntoskrnl.exe!KiSystemServiceCopyEnd (stack base)
ntoskrnl.exe!NtQueryVirtualMemory
ntoskrnl.exe!MmQueryVirtualMemory
ntoskrnl.exe!MiUnlockAndDereferenceVad
ntoskrnl.exe!ExfTryToWakePushLock (stack leaf)

WMI ( ), WMI. CPU, , WmiPrvSE.exe ( ):

WmiPerfClass.dll!EnumSelectCounterObjects (stack base)
WmiPerfClass.dll!ConvertCounterPath
pdh.dll!PdhiTranslateCounter
pdh.dll!GetSystemPerfData
KernelBase.dll!blah-blah-blah
advapi32.dll!blah-blah-blah
perfproc.dll!blah-blah-blah
perfproc.dll!GetProcessVaData
ntdll.dll!NtQueryVirtualMemory
ntoskrnl.exe!NtQueryVirtualMemory
ntoskrnl.exe!MmQueryVirtualMemory
ntoskrnl.exe!MiQueryAddressSpan
ntoskrnl.exe!MiQueryAddressState
ntoskrnl.exe!MiGetNextPageTable (stack leaf)

. NtQueryVirtualMemory, GetProcessVaData, Va, , . VirtualScan NtQueryVirtualMemory , Gmail (10-15 ) — . ?

, . NtQueryVirtualMemory . « », « » .. Gmail 26 000 , ( , WPA) 16 000 , .

- Gmail vmmap , Gmail (361 836 ) (49 719), — 2 147 483 648 , 2 . ?



, 2 Control Flow Guard (CFG), , “CFG” , Gmail Chrome — MiCommitVadCfgBits. , CFG !

Control Flow Guard (CFG) . , 128- . , CFG ( 2 ), . CFG , CFG . 98 24 866 CFG-. :

      Scan time,  Committed, page tables, committed blocks
Total: 41.763s, 1457.7 MiB,    67.7 MiB,  32112, 98 code blocks
CFG: 41.759s,  353.3 MiB,    59.2 MiB,  24866

vmmap ,  — vmmap 49 684 , 24 866

, CFG ? CFG , ? .

— VAllocStress, . 64- CFG, , , , . , / , , . VAllocStress:

1. :
   
   • VirtualAlloc .
   • .
2. :
   
   • 500 ( ).
   • VirtualAlloc .
   • , VirtualAlloc ~500 
   • .

. . , . , VirtualScan VAllocStress. , CFG , . VAllocStress !

CFG, . !

, JavaScript- v8 CodeRange , CodeRange 128 . , , CFG, .

, CodeRange, , ? CodeRange, Gmail — . ( ) CodeRange. , WorkerThread::Start . :

1. Gmail -, , .
2. , -.
3. CodeRange, JITted- JavaScript 47- .
4. CFG 2 .
5. CFG .
6. NtQueryVirtualMemory CFG ( 1  ) , .

CFG Windows 10 RS4 ( 2018 ), , . , .

CFG  — . CFG , . . , CFG ! , . CFG . , 2 !

, — Gmail 353,3  CFG 59,2  , 400 . - , .

v8 ( JavaScript Chrome) , CodeRange, . Microsoft CFG. , - Microsoft CFG , , , . vmmap .

. :

• Gmail.
• Windows 10.
• IT- WMI- .
• .
• .

, , , . , , , , .

, 10:30 , IT- . , Control Panel → Configuration Manager → Actions, Hardware Inventory Cycle Run Now.

, VAllocStress VirtualScan Github.

. ( ), (), ( WMI). vmmap. — — crbug.com/870054.

UPD.