記念すべきまともな vargin article.
Lotus Notes クライアントや Domino Server がこけた時に出力される NSD。
この NSD は何者なのか、何がわかるのかをざっくり調べてみます。
この article では、
・NSD とはどういうものか。
・NSD で分かること
・何が悪さをして NSD を出力したのか
をざっくり、あくまでざっくり解説したいと思います。
(詳しく調べるの Lotus Customer Support の方たちなので。)
・NSD とはどういうものか
NSD はクラッシュ時の Lotus Notes/Domino の障害診断情報のログです。
この情報を利用してどのような処理で落ちたかがざっと分かります。 ( クラッシュの原因によっては別途 SEMDEBUG.TXT, htthr (req.log), Statrep.nsf などの資料が必要になります)
・NSD でわかること
クラッシュ時のシステムプロセスや Notes/Domino が掴んでいたプロセス、プロセスのコールスタック、 Listen していたネットワークポートの状態、メモリの使用状況などがわかります。
・何が悪さをして NSD を出力したのか
実際に NSD の中を覗いて見ます。
NSD は以下のようなダイアログを表示して Lotus Notes/Domino が異常終了したことを通知します。
(click すると拡大します)
<追記 (9/1)>
書き忘れてました。
このダイアログ。
[OK] ボタンがありますが、 [OK] を押さないでください。
押してもすぐ終了するものでもないのですが、押してしまうと正確な情報 (本来取れるはずの NSD data) が一部欠落する可能性があります。
Lotus Customer Support の方に解析をお願いするときに、この NSD は殆どの場面で必要になります。
で、万が一情報が取れないと、解析に必要なデータが取れない→次回問題再発時まで手をこまねいて待つ、という事態になりかねません。
くれぐれも [OK] ボタンは押さないようにしてください。
(必要なデータが取れたら勝手に終了します。長いのですが辛抱してください)
</追記 (9/1)>
ダイアログ内のメッセージに NSD が出力されたパスとファイル名が記載されています。
次のファイル名で生成されます。
nsd_<option>_<platform>_<host name>_<month>_<day>@<hour>_<minutes>.logoption - NSD 採取方法。異常終了時は all です。 (手動採取時の引数によって変わります)
platform - プラットフォーム名。 Windows 環境では W16, または W32
host name - 端末のホスト名。 Windows 環境ではコンピューター名
month - NSD 生成月
day - NSD 生成日
hour - NSD 生成時刻 (時間)
minutes - NSD 生成時刻 (分)
で、このファイルをテキストエディタで開きます。
NSD Version, Notes Version などいろいろ出てきます。
一つ一つは説明できないので (項目が多すぎますし、私にはわからないことだらけですから) どのプロセスがエラーを引き起こしたのか確認してみます。
確認手順は次のようになります。
・Fatal thread を見つける
・thread にマッピングされたプロセス ID を調べる
・プロセス ID から異常終了時にアタッチしていたデータを割り出す
・Fatal thread を見つける
出力された NSD には異常終了時に稼動していた thread と thread が行っていた処理が一覧で表示されます。この中でクラッシュしたプロセスに関しては、 "FATAL THREAD" という見出しがつけられているので、 "FATAL THREAD" でテキストを検索してみます。
実際にクラッシュした thread が存在する場合、次のようなコールスタックを見つけることができます。
############################################################
### FATAL THREAD 1/9 [ NLNOTES:05bc:03ec]
### FP=0012defc, PC=779deaaf, SP=0012dec0, stksize=60
Exception code: c0000005 (ACCESS_VIOLATION)
############################################################
[ 1] 0x779deaaf OLEAUT32.UnRegisterTypeLib+15150 (17e9c0,22eb70,12df1c,62fca74)
@[ 2] 0x618ea3b1 nnotesws.CEditorOLEObjProps::CheckForColorProperty+65 (62fca74,22f068,62ff9f4,62ff6f4)
@[ 3] 0x618e9d32 nnotesws.CEditorOLEObjProps::CEditorOLEObjProps+898 (3,62f7eb4,12df80,6187842c)
@[ 4] 0x618e91d4 nnotesws.CEditorOLEContainedObj::SetProperties+36 (62ff6f4,0,62f7e34,12df9c)
@[ 5] 0x6187842c nnotesws.COLEPaletteBridge::SetContext+92 (62ff9f4,20e2c,12e0a4,62f2aca)
…以下略
色づけした情報について…。
FATAL THREAD - 異常終了が発生した thread です。
1/9 - thread 数/thread 総数です。 9thread のうちの 1thread 目、というあらわし方になります。
[ NLNOTES:05bc:03ec]
NLNOTES - 異常終了が発生したタスク名です。
05bc:03ec - タスクに割り当てられた processID と virtualID です。 (だったと思います)
コールスタックについてですが、ここは Lotus Notes/Domino や third-party の dll のどの関数を呼び出したかを表しています。 (詳細については内部仕様なのでこれ以上追及できません)
名前から大体を推測してどのような処理が行われたかが分かります。 (大体です。いつも分かるとは限りません。あしからず)
[ 1] 0x779deaaf OLEAUT32.UnRegisterTypeLib+15150 (17e9c0,22eb70,12df1c,62fca74)
@[ 2] 0x618ea3b1 nnotesws.CEditorOLEObjProps::CheckForColorProperty+65 (62fca74,22f068,62ff9f4,62ff6f4)
@[ 3] 0x618e9d32 nnotesws.CEditorOLEObjProps::CEditorOLEObjProps+898 (3,62f7eb4,12df80,6187842c)
@[ 4] 0x618e91d4 nnotesws.CEditorOLEContainedObj::SetProperties+36 (62ff6f4,0,62f7e34,12df9c)
@[ 5] 0x6187842c nnotesws.COLEPaletteBridge::SetContext+92 (62ff9f4,20e2c,12e0a4,62f2aca)
上にあるものからクラッシュ直前のスタックになります。
なので、 COLEPaletteBridge -> CEditorOLEContainedObj -> CEditorOLEObjProps -> CEditorOLEObjProps -> OLEAUT32.UnRegisterTypeLib の各関数を呼び出して最後の OLEAUT32.UnRegisterTypeLib をコールしてクラッシュしています。
で、各プロセスエントリの見方なのですが、@ がついているものは Lotus Notes/Domino の dll です。
ついていないのは OS, third-party の dll です。
[dll 名].[クラス名]::[関数名] で記載されています。
今回のクラッシュは名前からして OLE オートメーションコントロールの登録時にクラッシュしているな、という大体のことが分かります。
<いつかきっと続く>
<ようやく続いた>
で、ですね。
この NSD ファイルから場合によってはどのタスクがどのデータベースで何を触ってたときに落ちたかを調べることができます。
一番手っ取り早いのはサポート契約を結んで NSD とクラッシュ直前の操作を報告すること。
…。
なんですけど、ミもフタもないのですがファイルから "Open Databases" で検索すると NSD 生成時に Domino の各プロセスがアタッチしていたデータベースを参照することができます。
ここから怪しいデータベースを特定してさまざまな視点や方法でデータを分析して原因となった問題を調査していくようです。
TIPS - (Lotus Notes/Domino を触っている) 一般人が障害かどうか確認する方法 -
NSD 内の Fatal thread 内の各コールスタックを IBM の Web site で検索するとまれにぴったりなコールスタックが出てきたりします。
前述させていただいたとおり、コールスタックは下から上へと最新の情報が記されている ( = 上のコールスタックがクラッシュ直前です) ので、適当にクラッシュ直前のコールスタックを見繕って検索してみましょう。
たとえば、今回だと
CEditorOLEObjProps
CEditorOLEContainedObj
COLEPaletteBridge
で検索します。
え？なんでこれなんだって？少ないんじゃないか？
えっとですね、私なりの経験則でしかないのですが、障害であるかどうか、という観点でこの NSD を利用することが暗黙の前提ですので、ポイントが一緒であれば問題ないと考えます。
つまり、コールスタックがすべて一致している方が良いのですが、完全に一致していなくてもクラッシュした "処理" がなんであるのか、が分かればどこまでスタックトレースをリストするか、というのがだんだん分かってきます。
あくまで NSD は "どのような処理をしていたか"、というのに重点がおかれているので、 NSD から見てみれば、クラッシュ自体はそれほど大きな意味を持たないのだと考えます。
で、幸い (?) にもある特定の操作で何回か NSD が出力されました。
Fatal thread のコールスタックがまったく同一 (関数レベルで、です。渡している引数の実データは見ません) だったので、このくらいで検索をかけてみました。
すると、 worldwide で１件だけ見つかりました。
【Adding or Executing OCX Control that Determines if OLE Property Is a Color Property Causes Crash】
http://www-1.ibm.com/support/docview.wss?uid=swg21117095
なになに？ OCX コントロールを追加/実行時に Color プロパティが原因でクラッシュする？ (適当訳です)
リンクを開くと、この問題が原因でクラッシュしたコールスタックが載っています。
内容をよく確認すると殆ど合致しています。
つまり、今回のクラッシュはこの問題である、と結論付けられるわけです。
で、いつ直るのかなーと思い見てみると、
This issue was reported to Lotus software Quality Engineering; however, currently there are no plans to address it in the 6.x code stream.
残念なから 6.x の code stream では修正されないようです。 ( Lotus Notes/Domino 7 に期待ですね)
と、言うのが NSD によって分かる、調べられる事柄です。
初回の割には相当偏った内容になってしまいました。
#反省
これにめげずにみんなついてきてください。
(worldwide で検索したほうが情報量も多いのでお勧めです)