あなたの記憶を食べるゾンビ

あなた自身がそこに何を考えても、ゾンビが存在します。 そして彼らは本当に脳を食べます。 人間ではなく、本当ですが、コンピューターです。 私はゾンビプロセスとそれらが消費するリソースについて話している。 これは、失われた32 GBのRAMについての悲惨な話です。 おそらく、まったく同じ問題に直面するのはごく少数ですが、これが発生した場合、少なくとも何が起こっているのかを理解する機会があります。



まず、Windowsを実行しているコンピューターは、時間の経過とともにメモリを失う傾向があります。 まあ、少なくとも私にとっては、私の使い方で。 再起動せずに2週間後（または、Chromeを300回再構築した週末など）、タスクマネージャーが非常に少量の空きRAMを表示し始めるのに気付き始めましたが、同時にシステムにはプロセスがありませんこのメモリは積極的に使用されます。 上記の例（Chromeの300のアセンブリ）で、タスクマネージャーは、システムが49.8 GBと4.4 GBの圧縮メモリを使用しているが、同時にいくつかのプロセスのみが開始され、それらすべてがそれほど多くのメモリさえ使用しないと言った：







私のコンピューターには96 GBのRAMがあり（はい、私は幸運です）、実行中のプロセスがまったくない場合-このメモリーの少なくとも半分を解放したいと思います。 本当に期待しています。 しかし、時にはこれが達成できず、OSを再起動する必要があります。 Windowsカーネルは高品質と信頼性 （冗談なし）で作成されているため、メモリはトレースなしで消えてはなりません。 しかし、それでも彼女は姿を消します。



私の最初の推測は、 同僚の誰かが何らかの形でゾンビプロセスについて不平を言ったことを思い出した。 彼は、そのようなプロセスのリスト（名前と番号）を表示する特別なユーティリティを作成しました。 テストでこのユーティリティを実行すると、通常のWindowsマシンで最大数百のゾンビプロセスを受け取りました。 私は彼のツールを見つけ、それをコンピューターで起動し、506,000のゾンビプロセスを取得しました。 はい、506千！



プロセスが「ゾンビ」状態に移行する可能性のある理由の1つは、他のプロセスがそのハンドルを開いたままにしていることかもしれないことを思い出しました。 私の場合、多数のゾンビプロセスが私の手にかかりました。それらを隠すことは困難でした。 タスクマネージャーを開き、各プロセスの開いている記述子の数を示す列を[詳細]タブに追加しました。 次に、この列の値の降順でリストをソートしました。 私はすぐにこの物語のヒーローを見つけました-CcmExec.exeプロセス（ Microsoft System Management Serverの一部）には508,000のオープン記述子がありました。 これは、第一に、多く、そして第二に、506,000のゾンビプロセスで私が見つけた数に疑わしいほど近かった。







CcmExec.exeプロセスを強制終了し、次の結果を得ました。







すべてが私が期待したとおりになりました。 上記で皮肉なく書いたように、Windowsカーネルは非常にうまく書かれており、プロセスが破壊されると、それによって占有されていたすべてのリソースが解放されます。 CcmExec.exeを閉じると、508,000の記述子が解放され、506,000のゾンビプロセスを完全に閉じることができました。 空きRAMの量が即座に32 GB増加しました。 謎が明らかになりました！

ゾンビプロセスとは何ですか？

この時点まで、これらすべてのプロセスが不確実にハングアップし、削除されなかった原因はまだ解明されていません。 アプリケーションの些細なバグを処理しているようです（OSのカーネルではありません）。 一般的なルールは、プロセスを作成すると、そのハンドルとそのメインスレッドのハンドルを取得することです。 これらの記述子を閉じる必要があります。 タスクがプロセスを開始するだけの場合は、すぐに閉じることができます（これにより、実行中のプロセスは強制終了されず、プロセスとの接続が切断されます）。 何かの新しいプロセスが必要な場合（たとえば、作業の終了を待っている場合、またはそれが返すコードが必要な場合）、適切な関数（たとえば、WaitForSingleObject（hProcess、INFINITE）を使用して終了またはGetExitCodeProcess（hProcess、＆exitCode ）戻りコードを取得します）子プロセスから必要なものをすべて取得した後でも、記述子を閉じます。 OpenProcess（）関数を使用して何かのために開いたプロセス記述子でも同じことを行う必要があります。



そうするのを忘れたプロセスがシステムのものに関連している場合、それはあなたがあなたのアカウントからログアウトして再度ログインするのを助けさえしないかもしれません、完全なリブートだけ。

記憶はどこに行きますか？

私の研究で使用したもう1つのツールは、 RamMapユーティリティです。 メモリの各ページの使用状況を示しています。 [プロセスメモリ]タブには、それぞれが32 KBのRAMを占有する数十万のプロセスが表示されます。これは明らかにゾンビです。 しかし、それぞれ32 KBで約500,000回は約16 GBになります。残りのメモリはどこに行きましたか？ ゾンビプロセスを閉じる前後のメモリの状態を比較すると、この質問に対する答えが得られます。







〜16 GBがプロセスプライベートメモリに使用されることが明確にわかります。 また、別の16 GBがページテーブルメモリに収まっていることもわかります。 明らかに、各ゾンビプロセスはメモリページのテーブルで32 KBを使用し、個人メモリとして別の32 KBを使用します。 ゾンビプロセスにそれほど多くのメモリがある理由はわかりませんが、おそらく、そのようなプロセスの数を数十万単位で測定できるとは考えていません。



CcmExec.exeプロセスを閉じた後、主にマップされたファイルとメタファイルを使用した後に、使用されるメモリの種類が増加しました。 なぜそれが起こったのか正確にはわかりません。 私の推測の1つは、OSが十分な空きメモリがあると判断し、それ自体に何かをキャッシュしたことです。 これは、一般的には悪くありません。 私はOSのニーズのためにメモリを後悔していない、私はただそれが完全に目的なしに消えてほしくありません。



重要な注意：RamMapはすべてのプロセスの記述子も開きます。そのため、ゾンビプロセスを閉じたい場合は、このユーティリティを閉じる必要があります。



私は自分の発見についてツイートし、このバグを再現してマイクロソフトの開発者に情報を渡すことができる別のプログラマーが研究を続けました。



この問題がすぐに修正されることを願っています。

コンピューターでこのような奇妙な問題が発生するのはなぜですか？

私はChromeのWindowsバージョンのコードに取り組んでおり、私のタスクの1つはこのOS上でアセンブリを最適化することであり、これにはこのアセンブリの複数の起動が必要です。 Chromeの各アセンブリは、選択した設定に応じて28,000〜37,000の非常に多様なプロセスを開始します。 分散アセンブリシステム（ goma ）を使用して、これらのプロセスは非常に迅速に作成および終了されます。 私の最高のChromeビルド結果は200秒です。 しかし、このような積極的なプロセス開始ポリシーは、Windowsカーネルとそのコンポーネントの問題を明らかにします。

• プロセスをすばやく削除すると、ユーザー入力がフリーズする
• タッチパッドドライバーは、プロセスが作成されるたびにメモリを割り当てますが、 解放しません
• App VerifierはO（n ^ 2）個のログファイルを作成します （それについては別の投稿を書く必要があります！）
• Windowsカーネルにはファイルバッファリングを扱うバグがあり、このバグはServer 2008 R2からWindows 10までのすべてのWindowsで発生します。
• Windows Defenderは各ゴマプロセスの開始を250ミリ秒遅らせます

次は？

会社のポリシーによって制御されているコンピューターで作業していない場合、CmmExec.exeプロセスは実行されず、この特定のバグは発生しません。 また、Chromeを収集するか、同様のことを行う場合にのみ影響し、数万のプロセスを短時間で作成および終了します。



しかし！



CcmExecは、世界で唯一のバグプログラムではありません。 私は、ゾンビプロセスの作成につながるまったく同じタイプのエラーを含む他の多くのものを見つけました。 そして、私が見つけていないものがもっとたくさんあります。



すべての経験豊富なプログラマーが知っているように、明示的に修正または警告されていないエラーは必ず発生します。 「このハンドルを閉じてください」というドキュメントを書くだけでは十分ではありません。 そこで、この種のエラーを見つけやすくするための私の貢献を以下に示します。修正はより現実的です。 FindZombieHandlesは、 NtApiDotNetと@tiraniddoのコードに基づいたツールで、ゾンビプロセスのリストと、誰がゾンビになったかに関する情報を表示します。 コンピューターで実行されているこのユーティリティの出力の例を次に示します。

274 total zombie processes. 249 zombies held by IntelCpHeciSvc.exe(9428) 249 zombies of Video.UI.exe 14 zombies held by RuntimeBroker.exe(10784) 11 zombies of MicrosoftEdgeCP.exe 3 zombies of MicrosoftEdge.exe 8 zombies held by svchost.exe(8012) 4 zombies of ServiceHub.IdentityHost.exe 2 zombies of cmd.exe 2 zombies of vs_installerservice.exe 3 zombies held by explorer.exe(7908) 3 zombies of MicrosoftEdge.exe 1 zombie held by devenv.exe(24284) 1 zombie of MSBuild.exe 1 zombie held by SynTPEnh.exe(10220) 1 zombie of SynTPEnh.exe 1 zombie held by tphkload.exe(5068) 1 zombie of tpnumlkd.exe 1 zombie held by svchost.exe(1872) 1 zombie of userinit.exe
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

274人のゾンビはそれほど悪くはありません。 しかし、これでも、特定の問題を発見して修正することができます。 このリストのIntelCpHeciSvc.exeプロセスには最大の問題があります-Windowsエクスプローラーでビデオを開くたびにプロセスハンドルを開くように見えます（閉じ忘れているようです）。



Visual Studioは、少なくとも2つのプロセスの記述子を閉じることを忘れており、ある場合には常に再生します。 プロジェクトのビルドを開始し、MSBuild.exeプロセスが終了するまで15分ほど待ちます。 また、「set MSBUILDDISABLENODEREUSE = 1」オプションを設定すると、アセンブリが完了するとMSBuild.exeがすぐに閉じられ、失われたハンドルがすぐに表示されます。 残念ながら、Microsoftの一部のラスカルはこの問題を修正したため、VS 15.6アップデートで修正をリリースする必要があります。 ）



下に示すように下部パネルを設定することにより、 Process Explorerプログラムを使用して忘れられたプロセスを表示することもできます（この場合、忘れられた記述子がプロセスとスレッドの両方に表示されることに注意してください）：







見つかったバグの例をいくつか示します（一部は開発者に報告されていますが、すべてではありません）。

• CcmExec.exeのリーク（上記の500,000のゾンビの場合）-開発者は修正に取り組んでいます
• プログラム互換性アシスタントサービスのリーク-問題は調査中です
• devenv.exe + MSBuild.exeのリーク（問題は既に修正されています）
• devenv.exe + ServiceHub.Host.Node.x86.exeのリーク（バグレポートが送信されました ）
• 開いているビデオファイルごとにIntelCpHeciSvc.exe + Video.UI.exeのリーク（Intelはバグレポートを受け入れ、Lenovoに転送しました）
• RuntimeBroker.exe + MicrosoftEdgeおよびVideo.UI.exeのリーク（RuntimeBroker.exeの他のバグに関連している可能性があります）
• AudioSrv + Video.UI.exeのリーク
• 古いバージョンのpsutilの使用による1つの内部Googleツールのリーク
• Lenovoユーティリティリーク：tphkload.exeは1つの記述子を失い、SUService.exeは3つの記述子を失います
• SynapticのSynTPEnh.exeのリーク

この方法でリークする可能性があるのは、プロセス記述子だけではありません。 たとえば、「Intel®Online Connect Accessサービス」（IntelTechnologyAccessService.exe）は4 MBのRAMしか使用しませんが、30日間実行した後、27,504個の記述子を作成します。 この問題は、タスクマネージャーを使用して検出できます。開発者にバグレポートを送信しました。







プロセスエクスプローラーを使用して、NVDisplay.Container.exeが\ BaseNamedObjects \ NvXDSyncStop-61F8EBFF-D414-46A7-90AE-98DD58E4BC99イベントに対して〜5000個の記述子を開き、2分ごとに新しい記述子を作成することに気付きました。 私はそれを理解しているように、彼らは彼らがNvXDSyncを停止できることを非常に自信を持ちたいですか？ Nvidiaバグレポートが送信されました 。







Corsair Link Serviceは1秒あたり約15個の記述子を作成しますが、それらはまったく解放されません。 Bagreportが送信されました 。



AdobeのCreative Cloudは数千の記述子を失っています （1日あたり約6,500、私は推定）。 Bagreportが送信されました 。



Razer Chroma SDKサービスは、非常に多くの記述子を失います（ 1時間あたり150,000ですか？ ）。 Bagreportが送信されました 。



驚くべきことに、そのようなバグにこれまであまり注意を払った人はいませんでした。 ねえ、マイクロソフト、おそらくそのような場合の統計を収集し、それについて何かをする価値があるのでしょうか？ ちょっとIntelとNvidia、あなたのコードを少しきれいにしてください。 覚えておいて、私はあなたを見ています。



これで、 FindZombieHandlesユーティリティを使用してマシンで実行し、調査結果について話すことができます。 実験では、タスクマネージャーとプロセスエクスプローラーを使用することもできます。