1は、イベントの反応：「現場に持ち込まエンジニアは、それが簡単に問題を特定することができますので。」
これは私が最も一般的な誤解を聞いたものです。私に説明してみましょう：ほとんどの複雑な問題は、セッションのデバッグに深い必要があります。
収集に必要な情報は、それがリモートまたは顧客によって行うことができ、簡単です。しかし、デバッグダンプファイルには、数時間または数日かかる場合があります。私たちは、民間のシンボルへのアクセス権を持っていない可能性があり、特定の技術的な知識を持つ同僚とアクセスコラボレーションすることはできませんので、フィールドでの作業は、実際のプロセスが遅くなりますので。
多くの場合、現場での作業の重要な値は、リモート・エンジニア、あるいは我々がよく、電子メールまたは電話で理解することができない複雑な問題をより良く理解の目と耳として機能することです。
2.「我々のアプリケーションのパフォーマンスの問題ので、私たちは、コードをチェックする必要があります。」
時々私は、コードレビュー要求を取得し、実際には、顧客のニーズは、分離の問題があります。だから、違いはどのように私は私が必要なものを知って、何ですか？
オブジェクトコードの検査は、ソースコードをチェックすることで、コードがベストプラクティスの尖った部分、または部分的なセキュリティ侵害に従わない、あるいはまた、スピード部分に合わせて最適化することができます。
目標は、特定のアプリケーションの問題の切り分け症状につながった問題を分離することです。例えば、クラッシュ、ハング、メモリリークとパフォーマンスのボトルネック。
私に説明してみましょう：貧しいASP.NETアプリケーションのパフォーマンスのシーンを想像してみてください。自分のアプリケーションのコードレビューした場合、私はおそらく最適化のスピードへの道を見つけるだろう。しかし、パフォーマンスの向上を確認するために、コードによって得られたデータベース側またはネットワーク上のボトルネックがあるため、アプリケーションのパフォーマンスは、非常に遅い場合は答えではありません。最悪のケースでは、それも明らかにすることがあります。
あなたがしたい場合は必ず、アプリケーションが潜在的な問題ではないことをベストプラクティスを実装することで回避することができ、またはあなたが考える場合、我々は非常によく、より高い速度を達成するために、コードのチェックを最適化アプリケーションを促進することができます。しかし、速度ゲインを測定するために、問題を持っていないアプリケーションの時にのみ、ベースラインがあります。とても重要なボトルネックを解消するために、一般的に劣るのパフォーマンスを向上させることが重要です。
3.「そこで、この問題を修復した後、パフォーマンス/メモリの問題は、右の正規化されるのですか？」
事実は異なる、このようなパフォーマンスの低下と同じ症状が原因の問題、中断またはメモリに問題がある可能性があり、です。
これは何を意味するのでしょうか？他のマイナーな問題は、同じ症状を引き起こす可能性があるので、この手段があることが最も重要で最も明白な問題を解決した後、我々はアプリケーションを監視する必要があります。また、主なボトルネックの修理後、これらの他のマイナーな問題は、分離株に見えると簡単になるはずです。特定し、解決のアプリケーションの問題は、反復的なプロセスです。
4は、「私はメモリ管理について心配する必要はありませんので、我々は、.NETを使用しています。」
あなたは純粋な.NETアプリケーションを持っている場合は、私は同意する傾向があります。しかし、ほとんどの商用アプリケーションは、C DLLの、COMオブジェクトまたはAPI呼び出しとして、ネイティブの世界との相互作用のいくつかの種類があります。
ピュア.NET CLRは、メモリ内のアプリケーションを管理するための理想的です。アプリケーションがネイティブコードと相互作用している場合、開発者は、リソースのオン/オフを解放することを確実にする責任があります。
5、私はどのような情報を収集する必要がありますか？私が収集するためにどのくらいの情報が必要ですか？
情報が不十分とあまりにも多くの情報の間に細い線があります。私たちにとって最も重要なことは、正しい情報を得ることです。この現象に直面した場合、問題のアプリケーションから収集ダンプファイルは非常に貴重です。問題のアプリケーションから五個のダンプファイルが正常に収集され、おそらくあまりないの助けを実行しています。
アプリケーションがクラッシュした場合、アプリケーションがクラッシュしたとき、あなたは収集ダンプファイルにしたいです。あなたが他の時点でダンプファイルを収集する場合、それは珍しいからの情報ではありません。あなたがコアダンプファイルの膨大なコレクションを強制する場合は、プロセス内のすべてのコンピュータからの巨大なダンプファイルで終わるが、再び、ダンプファイルは、クラッシュへの応用、原因の異常に関する情報は含まれません。
6、「我々はので、パフォーマンスの問題、当社のアプリケーションのアーキテクチャを確認する必要があります。」
これは、上記の項目2と同様です。現在の問題を解決する最良の方法は、アーキテクチャのレビューではありません。
これらのアプリケーションは、多くの場合、あまりにもきめ細かな問題であるため、また、アーキテクチャのレビューでも、ほとんどのアプリケーションのための問題を解決する正しい方法ではないかもしれません。これは、アーキテクチャの観点正しい設計が、道アーキテクチャ設計上の問題とは何の関係から、クライアントアプリケーションという。
私はいくつかの例を挙げてみましょう。あなたは.NETフレームワークのためのアプリケーションへのアップデート重要な影響をインストールしていないと仮定します。それとも、あなたのアプリケーションは、それが使用されていることを内部のSharePointのSharePointオブジェクトを解放しない場合。これらの例では、アーキテクチャのレビューは、これらの問題を明らかにしないだろう。
7は、時々、右の出発点を見つけることが最も困難です。
このシナリオを想像：
。ユーザー、管理者および開発者はどのようにこの問題が発生します「私のW3WP.EXEがあまりにも多くのメモリを占有することは、これは、間違いかもしれIISので、我々は、IISのエンジニアが必要」？
- エンドユーザー：私はあなたのブラウザで問題を考えて、アプリケーションが非常に遅いです。
- IIS管理者：私は、ASP.NETアプリケーションでの問題の嘘だと思います。
- 開発者：うまく実行するASP.NETアプリケーション、問題がデータベースにあってもよいです。
- DBA：SQL Serverが実行されているだけでなく、私は、ネットワーク関連のボトルネックを考えます。
- ネットワーク管理者：なしネットワークの問題。
私たちは、開発者のPFEの目標は、異なる技術間で、お客様が問題を特定、およびオンサイトまたはリモートで異なるチーム間のクロスグループのコラボレーションを提供することであると。
8.どのようなスキルを、私は私がアプリケーションのデバッグを支援する必要がありますか？
アプリケーションをデバッグする必要がある場合は、製品またはインストールエンジニアを管理する方法を知っている必要はありません。何が必要内部アプリケーションとどのようにそれらの技術をデバッグすることを理解することです。良いニュースは、この知識は、アプリケーションに依存しないということです。
でも、マイクロソフトのエンジニアは、アプリケーションで前に見たことがなかった、彼/彼女はまた、あなたのアプリケーションをデバッグすることができます。同じことは、私たち自身の製品に適用されます。
いくつかの点で私たちは私たちの製品のいずれかに問題を特定する場合は、その後、我々は彼/彼女が問題や欠陥における製品のサポートの深い理解を持っているので、製品チームを設計する必要があります。
図9は、「私は長い時間のために！Clrstack実行を行い、スレッドのほとんどは、データベースからデータを取得しようとしている。ボトルネックはデータベースで発生することがあります。」
私はあなたに一つのことを教えてみましょう：私たちの新しいエンジニア回または.NETデバッガの人々がこれも、あなたは.NETデバッガでExcelにしたい場合、あなたはネイティブコードのデバッグを学ばなければならない、と言うの詳細学びたい方にこれは、C / C ++プログラミングの知識を意味します。
私を信じてはいけませんか？ほとんどのブロガーは、.NETデバッガを知っているようにあなたがしている場合は、その状況.NETのデバッグをお願いします。
そう言って！.NETデバッガの人々のお気に入りのコマンドを学習clrstack。クール、あなたが管理し、エンドレベルのマシン側よりも通常高いコールスタックを、見ることができます。時には、しかし、あなたはまだあなたが間違った結論を導く可能性がある、唯一のホスティング側に関係している場合、ネイティブ側は、本当に、スレッドが何をしているかを理解することができます参照してくださいする必要があります。
一番下の行は次のとおりです。あなたは、.NETデバッグスキルを向上させたい場合は、ネイティブのデバッグについてもっと学びます。
10は、「私の2台のサーバが同じですが、問題は、サーバーXYZで発生します。」
このシーンは、トラブルシューティングを行う場合には、サーバーが同じであることを前提としていません。これとは対照的に、データの収集は、それを証明します。
良いスタートはMPSReport / SPSReportツールを実行することです。このツールは、各サーバーからすべての情報を収集し、比較しました。サーバーの場合、少なくともまったく同じ根本的な問題は、それが過負荷になっているように、アプリケーションは、サーバーのいずれかにアクセスしていることです。
11、「イベント・ログからは、私は、Windowsの例外にクラッシュするアプリケーションとコールスタックポイント引き起こす見ることができます。私は、これは、Windowsのエラーだと思います。」
これはよくある誤解とする前項7に関連しています。時には、コールスタックから二度目のチャンス
の異常（アプリケーション未処理の例外、クラッシュにアプリケーションを引き起こしては）フレームのトップとしてWindowsからdllをします。これは正常であり、Windowsがクラッシュするという意味ではありません。
例：
ChildEBP RetAddr
0013bcd0 7c90de7a NTDLL！KiFastSystemCall + 0x2の
0013bdd0 7c81cdfe KERNEL32！_ExitProcess + 0x62
0013bde4 79f944b0 KERNEL32！のExitProcess + 0x14の
0013c00c 79f2c09a mscorwks！SafeExitProcess + 0x11b
0013c018 79eff585 mscorwks！DisableRuntime + 0xd1
0013c0a8 79011628 mscorwks！CorExitProcess + 0x242
0013c0b8 77c39d3c mscoree！CorExitProcess + 0x46の
0013c0c4 77c39e78 MSVCRT！__ crtExitProcess + 0x29
0013c0d4 77c39e90 MSVCRT！_cinit + 0xee
0013c0e8 0e68d21e MSVCRT！退出+ 0x12を
0013c580 0e256834 testappl！FuTestInterface ::のinit + 0x34のあなたがすべきところ<<<これは、 調査を開始します。
0013c5a4 0e1d8c01 testappと！WBNARiskReportInterface :: getResults + 0x442a
したがって、それはこの問題原因NTDLLまたはkernel32のではないと思います。オペレーティングシステムDLL APIは、アプリケーションの異常に起因するとコールをもたらすことができます。初期調査のポイントとして識別最新のアプリケーションのメソッド呼び出しを試してみてください。上記の例では、これはあるtestappl！:: FuTestInterfaceのinit。必要であれば、事前分析などを、それを分析します。
12は、「我々はC ++アプリケーションのクラッシュダンプファイルから収集したコールスタックは、右、犯人を示す必要がありますので。私たちは、これはヒープ破損であると思いますか？」
ヒープの破損ではないとして、多くの場合、前に、.NETアプリケーションは、より一般的になっているので。しかし、COMオブジェクトとC DLLの時代に、ヒープ破損が典型的な問題です。
それがセットに新しいヒープマネージャを使用してダンプファイルを収集できるように、ページヒープを有効にするには、コールスタックを取得するためのメソッドスタックから実際の被害は、アプリケーションを再起動してください。この方法を使用すると、ヒープ破損の問題を簡単に分離することができます。
あなたは、ページの検証ヒープなどを可能にするために（例えばページHeap.exe、GFlags.exe、アプリケーションなど）さまざまなツールを使用することができます。各メモリ割り当ての後（例えば、全ページヒープのような）いくつかのページヒープの設定は、読み取り専用のページを作成するためのアプリケーションがバッファをカバーしようとするたびので、それは、アクセス違反を生じる、読み取り専用ページをヒットします。