検索

WindowsOSのBSOD発生後、あるいはアプリクラッシュ後のメモリダンプから障害発生の原因を調べるための手引書です。
主に使うツールはおなじみのWinDBG。"Advanced Windows Debugging"のChapter13, "Postmortem Debugging" を抜き出して、必要最低限度のデバッガやCPUアーキテクチャの解説を付け足し、メモリダンプの解析の流れをメインに据えた一冊ともいえます。

• アスキーメディアワークス：Windowsダンプの極意
  • http://ascii.asciimw.jp/books/books/detail/978-4-04-867509-3.shtml

内容的にAWD本とかぶる部分も多いですが、こちらはメモリダンプ、それもOS全体のメモリダンプ解析をメインに据えています。
著者が実際に使用したサンプルプログラムやサンプルのデバイスドライバが公開されていないので、「手を動かして学べる」タイプの書籍ではありません。とはいえ、読んでいるだけでもトラブルシューティングの現場の臨場感を感じることが出来て、面白かったです。

他関連記事：

• 技術/Windows/WinDbgメモ
• 読書メモ/"Advanced Windows Debugging"
• 技術/Windows/メモリダンプ取得方法メモ

読書メモ/"Advanced Windows Debugging" の続編。
.NETアプリケーションのデバッグにおける、"Debugging Tools for Windows"やMS謹製のフリーツールの使用方法や問題分析の流れを詳しく解説している。

• Advanced .NET Debugging
  • http://www.advanceddotnetdebugging.com/

内容の詳細はアマゾンなどを参照して欲しい。
個人的なお薦めポイントとしては、CLRと.NET Frameworkの関係、「アセンブリ」の概念とロード機構、CLRのヒープ管理とGC、ファイナライズキューなどなどの、.NETで今ひとつ分かりづらいけど重要な「裏舞台」を分かりやすく紹介してくれている点。.NET入門者にとっては呪文めいた「アセンブリ」や「マニフェスト」といった用語がきちんと解説されている。

注意点としては、実際のデバッグの流れが掲載されているが、若干の省略が見られる点。特に

.loadby sos mscorwks

は省略されがちに思えた。デバッグコマンドが一つ一つ書かれているからと言って、その通りに最初から打ち込んでもうまくいかない原因は大抵、こうした前提となるイロハのコマンドが省略されているから。そこだけ注意が必要。

他にも何気にtypoミスがあったり、酷いところでは公式HPからDLできるサンプルコードに抜けがあったりする。下記HPを参照のこと。

• Advanced .NET Debugging book - If broken it is, fix it you should - Site Home - MSDN Blogs
  • http://blogs.msdn.com/b/tess/archive/2009/12/15/advanced-net-debugging-book.aspx
• Advanced .NET Debugging – The Book by Mario Hewardt » Advanced .NET Debugging
  • http://dotnetdebug.net/2009/11/30/advanced-net-debugging-the-book-by-mario-hewardt/

いくつか「編集者真面目に仕事したのか・・・？」と首を傾げる点はあるものの、本書の価値を損なうほどのものではない。.NETアプリの開発に携わる人達であれば一読しておいて損はない一冊となっている。

• [ Prev ]
• [ Next ]
• [ C言語系 ]

"Debugging Tools for Windows"のwindbgなどを使い始めると、_NT_SYMBOL_PATH環境変数をシステムに設定したりすると思います。
この環境変数ですが、Visual C++ もちゃっかり使ってたりします。
で、値の書き方によってはVC++側でシンボルサーバーまで読みに行ったりローカルキャッシュからの検索などが思うようにスムーズに動かず、デバッグ実行時に数分以上の遅延が発生する場合があります。
書き方によってはVC++側でも素早くローカルキャッシュを見に行ってくれます。

というわけで、もし _NT_SYMBOL_PATH 環境変数を設定したらやたらVC++側のデバッグ実行が遅くなった、という人は書き方を工夫してみてください。

自分の場合、windbgの勉強中にこういうふうに設定したのですが・・・

cache*C:\in_vitro\tmp\symcache;srv*C:\in_vitro\tmp\awd_symstore\symstore.pri; \
  srv*http://msdl.microsoft.com/download/symbols

VC++側ではやたらと遅延が発生してしまいました。"cache"を明示したり、";"で区切ったりしたのがいけなかったのでしょうか？→ 誤解してました。cacheが効かない＋ローカルキャッシュとシンボルサーバの区切り文字を混同してました。 技術/Windows/WinDbgメモ 参照。

試行錯誤してこんなふうに直してみたら、windbgもVC++側も双方、すんなり動いてくれました。

srv*C:\in_vitro\tmp\symcache*C:\in_vitro\tmp\awd_symstore\symstore.pri; \
  http://msdl.microsoft.com/download/symbols

実験環境：

Win7 (x86,32bit) 日本語版
Visual C++ 2008 Express Edition SP1
Windows SDK v7.0

参考：

• シンボル サーバーを Visual Studio .NET デバッガで使用する方法
  • http://support.microsoft.com/kb/319037/ja
• VS 2008 Environment Variables
  • http://social.msdn.microsoft.com/Forums/en/vsdebug/thread/2c5455c2-90d3-4e65-9eb4-56598fa8d3bb
• Debugger is slow when _NT_SYMBOL_PATH is pointing at http://msdl.microsoft.com/download/symbols and Windows Live is installed
  • http://social.msdn.microsoft.com/Forums/en-US/vsdebug/thread/2a434a6e-d5e5-4c56-85a9-1ea4db6fac6c
• Lazy load symbols while _NT_SYMBOL_PATH is set
  • http://social.msdn.microsoft.com/Forums/en/vs2008sp1beta/thread/509ed7e1-56e5-453a-89ea-8d15bbc8e1cb

• [ Prev ]
• [ Next ]
• [ Up ]
• [ C言語系 ]

• [ Prev ]
• [ Next ]
• [ 技術 ]

WinDBG参考図書：

• "AWD"公式HP : Welcome to Advanced Windows Debugging, windows debugging portal, ...
  • http://advancedwindowsdebugging.com/
• Windowsデバッグの極意
  • http://ascii.asciimw.jp/books/books/detail/978-4-04-867608-3.shtml

※"AWD"サンプルコードのシンボルパスについて
本書中で紹介されているURLは2011年1月の時点でアクセス不能になっている。

http://www.advancedwindowsdebugging.com/symbols/symstore.pri

このため、"AWD"公式HPからダウンロードしたプライベートシンボルファイルをローカルPC上に展開し、そちらへのパスをシンボルパスに設定する必要がある。

WinDBGやWindowsデバッグ関連参考サイト：

• Driver Developer Resources: Debugging Tools for Windows
  • http://www.microsoft.com/whdc/devtools/debugging/default.mspx
• Ntdebugging Blog - Site Home - MSDN Blogs
  • http://blogs.msdn.com/b/ntdebugging/
• Welcome to WinDbg.info
  • http://windbg.info/
    • 日本語訳された"WinDbg From A to Z!"は分かりやすいし、"Common WinDbg Commands"は使い始めの頃は印刷して手元で確認出来ると便利。"CrashMe"はWinDbgに入門する時のサンプルアプリに使う。

• [ Prev ]
• [ Next ]
• [ Python ]

"Debugging Tools for Windows"の提供する拡張機能をPythonから呼び出せるPyDbgEngを使って、Pythonで簡単なデバッガを作ってみました。

2011/03/11の地震は津田沼で迎えた。千葉県香取市粉名口の実家は兄とジジババの３人暮らしで基本無事だが、周囲に泥が吹き出して液状化が云々とのこと。
03/13に成田～銚子間が動き出したので様子を見に行ったところ、周囲の道路が波打っていたりところどころ陥没したり、さらには電柱も大きく傾いたりとそれなりの被害をうけていた。
03/13の時点では泥も乾き、重機で寄せて掬い上げる事が出来る程度にはなっていた。近所の工事業者がボランティアでブルドーザーやシャベルを持ってきて片付けに追われていた。

自宅前の泥の状況：

付近の塀と電柱の被害：

兄は市内の介護施設で働いており、その間はジジババだけになる。上水道が止まっているため給水所との往復でどうしても人手が必要となる。ジジババは二人とも高齢で耳が遠かったり脳卒中の後遺症で言葉がうまく出てこない。大きめの余震も続くし、緊急時ということで電話のやりとりや近所の連絡、お見舞いに来た人とのやりとりをする留守番も必要だ。
ということで、兄が二日連続の休みをとれる今日まで実家で過ごし、今日ようやく津田沼のアパートに一旦戻ってきた次第。また明日には実家に戻り、留守番を続けることになる。

03/18時点、近所の十間川：湧きでてきた泥については半分ほど片付けられたらしい。

03/18時点、近所の電柱遠景：とりあえず電気が通ったので助かっているが、いずれは土台から工事して電柱を取り替える必要があるだろう。

香取市HPより、その他の写真：

• 香取市ウェブサイト： 東北地方太平洋沖地震における香取市内の被災状況写真
  • http://www.city.katori.lg.jp/saigai/saigai_photo.html

3/22より八千代市の支援で応急措置として上水道の工事が始まるようだ。とりあえず上水道が復旧し、ジジババが地震前の生活リズムを取り戻せるまでは実家を手伝うことになるだろう。

3/13に津田沼を発ったときはまさか何日も留守番することになるとは予想していなかったため、ノートPCも持ってこなかった。
今度はノートPCやネット環境を準備し、手持ち無沙汰になることが無いようにしたい。

3/12日よりこちら、ずっと実家でジジババの留守番やご飯の支度などで、合間合間にNHKとかで原発ニュースを見ていて、「まぁ今のところ千葉県や東京都周りは放射能の心配は要らないか。」と安心したのもつかの間、ようやく津田沼に戻ってきてWebを見てみたらまぁあっちこっちで「内部被曝がどーのこーど」とか2ch系のまとめサイトでは「日本もう＼(^o^)／ｵﾜﾀ」系のコメントで人様の不安とか恐怖心をカリカリ掻きむしったりとか、なんだこりゃ、Web見てても一向に安心できねぇやと暫く眺めてたら。

ふと、「あ、そーいえば高校の物理で半減期とか習った記憶があるな」と、試しにほうれん草や原乳で基準値超えて話題になっている放射性同位体のヨウ素131の半減期を調べてみたら8.02日だったよ。半減期は指数関数的に作用するので、数日経ってしまえば放射性は非常に弱くなってしまい、影響ないということか。

個人的には政府の公式報道を第一として信じるほかない、と思っているので2011/03/21現時点ではそれほど心配はしていない。
千葉県・東京都の範囲で風に乗ってくる放射性物質による被爆を心配するくらいなら、まずは日常の病気や交通事故に注意すべきだと思う。

参考：

• 「退避すべきかとどまるべきか」放射線被ばくを深く心配されている方々へ（2011年3月17日午後時点の情報を踏まえて) - ガジェット通信
  • http://getnews.jp/archives/105218
• 「最悪のシナリオ」という脅しに騙されないために - ガジェット通信
  • http://getnews.jp/archives/105518
• 「茨城・福島の牛乳　ほうれん草は無害だ」ヨウ素131の半減期は既に過ぎている - ガジェット通信
  • http://getnews.jp/archives/105673

ソースが偏ってしまったけど、ほうれん草の話題では半減期に言及していたり、空気中の放射性物質濃度の推移を1960年代からのデータを見せつつ解説してくれているということでとりあえず参考。

• [ Prev ]
• [ Next ]
• [ Python ]

かなりニッチなモデルについて実験。

1. スレッド１：対話形式処理モードと監視処理モードの二つのモードの間を遷移する。
2. スレッド２：コンソールでCtrl-Cによる割り込みを受け付け、スレッド１を対話形式処理モードに切り替える。

スレッド１の監視処理はbusyループではなく、TimeOut付きの短期間のwait()を無限ループ中で呼び出すイメージ。
スレッド１の初期状態は監視処理モード。スレッド２による切り替えで対話形式処理モードに遷移する。
対話形式処理モードにおいて監視処理への切り替えコマンドを受け取ると、再び監視処理モードに遷移する。

スレッド間の連携については threading.Event を使ってみる。

予備実験として threading.Event を使ったスレッド間連携を試してみる。
thread_and_event1.py:

import threading
import time
 
def mythread(myevent):
  count = 1
  while True:
    myevent.wait(1)
    print "wakeup(%d)" % (count)
    count += 1
    if myevent.isSet():
      print "break"
      break
 
event = threading.Event()
t = threading.Thread(target=mythread, args=(event,))
t.start()
 
# 5秒後にevent発生
time.sleep(5)
print "(main):event set"
event.set()
 
t.join()

実行例(Python2.5)

> python thread_and_event1.py
wakeup(1)
wakeup(2)
wakeup(3)
wakeup(4)
(main):event set
wakeup(5)
break
>

予備実験で threading.Event によるスレッド間連携を確認できた。

本題となるモード切り替えやCtrl-Cによるスレッド連携の実装サンプル：
thread_and_event2.py:

import threading
import time
import signal
 
def mythread(myevent):
  busy_work = threading.Event() # 小刻みな監視処理用のダミーEvent
  continue_flag = True
  count = 1
  while continue_flag:
    # 小刻みな監視処理
    if busy_work.wait(1):
      print "Never happen"
    else:
      print "mythread(%d)" % (count)
      count += 1
      # 連携イベントをチェック
      myevent.wait(1)
      if myevent.isSet():
        print "Interrupted"
        # 対話形式スタート
        while True:
          command = raw_input(">>")
          if command == "q":
            continue_flag = False
            break # 監視処理に戻る＋フラグにより終了へ
          elif command == "g":
            break # 監視処理に戻る
          else:
            print "You type: " + command
        myevent.clear()
  print "end"
 
event = threading.Event()
t = threading.Thread(target=mythread, args=(event,))
t.start()
 
while True:
  try:
    # 1秒間ずつスレッドの終了チェック
    t.join(1)
    if not t.isAlive():
      break
  except KeyboardInterrupt:
    # Ctrl-C による割り込み発生
    print "interruption set"
    event.set()

実行例(Python2.5)

> python thread_and_event2.py
mythread(1)
mythread(2)
mythread(3)
(Ctrl-C)
interruption set
Interrupted
>>foo
You type: foo
>>bar
You type: bar
>>g
mythread(4)
mythread(5)
(Ctrl-C)
interruption set
mythread(6)
Interrupted
>>abc
You type: abc
>>q
end
>

Ctrl-Cによる監視→対話へ切り替え、対話形式でのコマンド入力による監視モードへの復帰やスレッドの終了を実現できた。

なお raw_input() 中に Ctrl-C を受信するとEOFErrorが発生する点に注意が必要。
EOF発生時には空文字列入力として続行する例：

       # 対話形式スタート
       while True:
         command = raw_input(">>")

→

       # 対話形式スタート
       while True:
         command = ""
         try:
           command = raw_input(">")
         except EOFError:
           pass

• [ Prev ]
• [ Next ]
• [ Python ]

以前 日記/2010/11/13/Win7でcheap2elのサンプルが一部動かない・・・ で挙げた、cheap2el添付のサンプルの一つ、DLLインジェクションするサンプルがWindows7で動作しない問題ですが、SP1に上げた後試してみたら治っている模様。
インジェクションされたDLLコードがちゃんと動作してました。デバッガ有無も関係なし。

SP1でのHotfixなど細かい変更点を追おうと思ったのですが・・・

• Windows 7 Service Pack 1 (SP1)
  • http://technet.microsoft.com/ja-jp/library/ff817622%28v=ws.10%29.aspx

ここ経由でHotfixの一覧Excelシートを入手できたものの、796もの変更点が登録されています。
ということで細かい変更点を追うことは諦め、readmeなど適当なファイルに注意書きとして「Win7で使うときはSP1にUPしてね」を追加するにとどめておきます。

• [ Prev ]
• [ Next ]
• [ 技術 ]

Microsoft UI Automation のメモ。

XP, Svr2003, Vista, 7, Svr2008 以降でサポートしてる、UIの自動化機構。

参考：

• Microsoft UI Automation - Wikipedia, the free encyclopedia
  • http://en.wikipedia.org/wiki/Microsoft_UI_Automation
• Bugslayer: GUI Control to Major Tom
  • http://msdn.microsoft.com/ja-jp/magazine/cc163465.aspx
• 【UIA】UI Automation を用いたユーザーインターフェイスのテスト - 序 - 長沢智治のライフサイクルブログ - Site Home - MSDN Blogs
  • http://blogs.msdn.com/b/tomohn/archive/2008/03/18/uia-ui-automation.aspx
• Windows Automation API: UI Automation
  • http://msdn.microsoft.com/en-us/library/ms726294%28VS.85%29.aspx
    • "MSDN Library" > (階層不明)
• UI Automation Overview
  • http://msdn.microsoft.com/en-us/library/ms747327.aspx
    • "MSDN Library" > ".NET Development" > ".NET Framework 4" > ".NET Framework Core Development" > "Accessibility" > "UI Automation Fundamentals" > "UI Automation Overview"

• [ Prev ]
• [ Next ]
• [ Up ]
• [ 技術 ]