Clever Geek Handbook

断続的なWindowsフリーズのケース



もちろん、私は人々が前の投稿を好きになることを期待していましたが、 どれほど想像することさえできませんでした。 私の意見では、この投稿は以前の投稿よりも興味深いものです。 前回はエキサイティングなカジュアルゲームでしたが、完全に無意味で時間がかかりますが、その珍しいゲームプレイと、最も重要なのは誰にとってもインタラクティブでアクセスしやすいことです。プロットのさらなる発展を推測しますが、双方向性のための場所を残していません。 一方、「探偵小説」は「実際の出来事に基づいている」ため、特別な魅力が生まれます。





それはすべてQ＆Aの質問から始まりました。

リンクをたどるのが面倒な人のために、質問そのものを引用させてください。



実際には、ディスクのリストで「マイコンピュータ」を開いたり、USBフラッシュドライブ/コンピュータを挿入すると、コンピュータがフリーズする（マウスが動かず、キーボードがNumLockに応答しない）場合があります。 外部刺激に対する反応の完全な欠如。 10〜30秒後、コンピューター自体は、何も起こらなかったかのように死にます。 質問自体は、そのようなシステムのフリーズの原因を特定する方法とその対処方法です。


さて、追加情報：ハードウェアRAID 4x640（en望）、fireの更新は役に立たず、SMARTはサイレントテストです。



ある非常に良い人が書いたように ： 「地元の人は 、3つの理由で夏に砂漠に旅行することを避けます。 ガラガラヘビ、ダニ、サソリ。 アイデア！ 思った。 テントがあります。」



最初のアイデア：誰かが中断を受け入れ、ISRで「休む」ことを決定します。 また、この誰かが単にIRQLを下品なレベルに引き上げているだけで、まだ「休憩」することを決定している可能性もあります。 同じxperfを使用してキャッチします。



xperf -on latency -stackwalk profile -maxfile 128 -filemode circular



説明：

遅延を含める-遅延をキャッチするために他に何を含める必要があります。 xperf -providers Kが私たちに言うように：

レイテンシー：PROC_THREAD + LOADER + DISK_IO + HARD_FAULTS + DPC + INTERRUPT + CSWITCH + PROFILE



つまり、DISK_IO + HARD_FAULTSは、必要なPROC_THREAD + LOADERに追加されます。これは、バイナリ自体に起きていることをリンクするために必要です。問題はまれですが、それらが配信される場合は、「ソウルで」、CSWITCH-コンテキストスイッチ-デッドロックと不正な優先順位を追跡します。PROFILE-プロファイル割り込みイベント（デフォルトでは、ミリ秒ごと）

システム内の他のすべてが生命の兆候を示さない場合でも、割り込みプロファイルはまだ配信されると信じるあらゆる理由があります。 Windowsの定義済みIRQLのリストは次のとおりです。 

#define PASSIVE_LEVEL 0 #define LOW_LEVEL 0 #define APC_LEVEL 1 #define DISPATCH_LEVEL 2 #define PROFILE_LEVEL 27 #define CLOCK1_LEVEL 28 #define CLOCK2_LEVEL 28 #define IPI_LEVEL 29 #define POWER_LEVEL 30 #define HIGH_LEVEL 31




上記のプロファイルは、数時間、プロセッサ間の中断、電源の中断のみです。 これらの割り込みはいずれもサードパーティのドライバーに委ねられていません。プロファイル割り込みがマスクされていることが判明した場合、検索スペースも大幅に狭まります。



「-stackwalkプロファイル」は、各PROFILEイベントについて、完全なスタックトレースも削除されることを意味します。 サンプリングされたプロファイルをすぐに使用した人は誰でもこの機会に感謝します。したがって、90％の時間を何らかの種類のスピンロックに費やしたことは、WHOがこのスピンロックを引いたことを知ることが重要です。



「-maxfile 128 -filemode circular」は、プログラマーに馴染みのある循環バッファーの概念です。 フリーズは1日に1回または2回発生し、1秒ごとに1メガバイトの情報が生成されるため、この時間の完全なログを収集することで十分なスペース（4x640、cho）になる可能性がありますが、分析のために開く（または転送する）のはより困難です。



シルクはばらばらです-私たちは待っています。 最初の犠牲者は4日間で捕まりました。





そして、それはこのように見えました：





さらに、奇妙な偶然によって









彼は走った、私は思って、検索に登りました



想像力は、何らかの目的で割り込みがシリアル化され、処理のためにユーザープロセスに配信される図を鮮明に描きました（これは、原則として、マルチプロセッサシステムで実装できます。 Mearの功績として、彼はすぐにNISを破壊しなかったため、最初のスクリーンショットから1つの詳細に気付きました。120万件のイベントが失われました。 グラフのギャップはアクティビティの不足ではなく、バッファをディスクにフラッシュする機能がないためにバッファがオーバーフローして新しいデータで上書きされることです（ディスクからの割り込みが遅延したか、何らかの理由でI / Oマネージャがブロックされた可能性があります）。



さて、システムが最終的に「死ぬ」ので、私たちのタスクは、すべてをディスクにフラッシュする機会があるまで、すべてをメモリに入れることです。

xperf -on latency -stackwalk profile -maxfile 256 -filemode circular -buffersize 1024 -minbuffers 256

バッファーのサイズとバッファーの最小数を追加します。 待っています。 1日後、美しいロスレスログを取得します。





残念ながら、反対側の「私の目と手」はコースの停止にためらい、停止することなく見始め、実際の問題の瞬間そのものをほとんど失いました。 しかし、幸いなことに、十分な情報がありました（グラフは、DPCプロセッサの急増が徐々にバッファを超えていることを示しています）





さて、問題の領域を拡大して調査を開始します。

まず、ISRが表示されます。これには12秒かかりました





そして、10かかったDPC





残念ながら、問題のアドレスでモジュールを見つけることはできませんが、最初にスタックウォークの魅力を描いたのは無駄ではありませんでした。





スタックの一番下には、spcl.sysを呼び出す「未知の」スタブアドレスがあり、それがscsiportを直接呼び出しています。 スタックをさらに展開します。





もう一度spcl.sysに入り、そこからKeStallExecutionProcessor（SRSLY？IN THE INTERRUPTION PROCESSOR？）を呼び出すmv61xx.sysに入ります。 別の方法では、mv61xxでさらに1回の呼び出しを行い、それでもリラックスし始めます。



DPCを処理するときにも同様の状況が現れます（ただし、これはマルチプロセッサシステムにとってそれほど重要ではありません）。





数分の検索で、spclとmv61xxの作成者が表示されます。これはSPTD（デーモンツールとアルコールxxx％で使用）とMarvellハードウェアドライバーです。 これらは次のとおりです。





開始するには、ハードウェアドライバーを更新し、sptdをオフにします-問題は停止しました。 sptdを慎重にオンにします。2週間-フライトは正常です。



PS：この投稿はMearなしでは不可能だったでしょう。 彼は非人道的な実験のために問題のあるシステムを提供し、この問題を見つけるためにあらゆる方法で私を助けてくれました。


More articles:


All Articles