Yoichi's diary


2012-11-03

_ [comp/Windows] クラッシュ時のダンプ収集

regedit で次のキーを生成すればいい。(デフォルトの動作でいいならキーさえ作ればいい)
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps
参考: Collecting User-Mode Dumps

2012-11-04

_ [comp/Windows] 32bit ダンプで 64bit シンボルが読み込まれる?

heap command とか使えないので何でかと思ったらシンボルに騙されていた(_LIST_ENTRY::Flink が Ptr64 型なので64bit用?)。シンボルが読み込まれているので関係ないシンボルファイルというわけではなさそうだけど、 どういう状況なのだろう?
Microsoft (R) Windows Debugger Version 6.2.9200.16384 X86
Copyright (c) Microsoft Corporation. All rights reserved.
 
Loading Dump File [C:\work\sample\sample.DMP]
User Mini Dump File with Full Memory: Only application data is available
 
Symbol search path is: SRV*C:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 8 Version 9200 UP Free x86 compatible
Product: WinNt, suite: SingleUserTS
Built by: 6.2.9200.16384 (win8_rtm.120725-1247)
Machine Name:
Debug session time: Sun Nov  4 10:48:32.000 2012 (UTC + 9:00)
System Uptime: 0 days 15:19:06.406
Process Uptime: 0 days 0:00:19.000
.....
eax=00000000 ebx=00cdf450 ecx=00000001 edx=00000000 esi=00cdf3c0 edi=00000000
eip=77671318 esp=00cdf298 ebp=00cdf418 iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202
ntdll!NtWaitForMultipleObjects+0xc:
77671318 c21400          ret     14h
0:000> lm
start    end        module name
01210000 01230000   sample     (deferred)             
74ac0000 74b67000   apphelp    (deferred)             
74d40000 74de6000   KERNELBASE   (pdb symbols)          c:\symbols\wkernelbase.pdb\CAE0056433064B78937D9022B20FA1102\wkernelbase.pdb
75590000 756c0000   kernel32   (deferred)             
77630000 77787000   ntdll      (pdb symbols)          c:\symbols\wntdll.pdb\2806B41638B04D8989F13322DD34573A2\wntdll.pdb
0:000> dt ntdll!_LIST_ENTRY
   +0x000 Flink            : Ptr64 _LIST_ENTRY
   +0x008 Blink            : Ptr64 _LIST_ENTRY
MS forum にポストしようとしたが Internal Server Error になったので後ほど。

2012-11-10

_ [comp/windows] !heapstat.bysize

同僚が再現性が微妙なメモリリークの調査をしているので、援護ができないか検討してみた。
  • ヒープサイズが異常に増大した状態のダンプがとれている
  • ただし ust 無効で試行した際のものなのでスタックトレースの情報が入ってない
  • ust有効で再現試験しているが再現できていない
という状況にて、何かできることはないか考えた。
  1. もりもり増えた所でとったダンプから要求サイズ毎の確保数の統計を取る
    (スタックトレースの情報は取れない)
  2. ust 有効にしてアプリを動作させてダンプを取り、要求サイズ毎の確保数の統計を取る
    (サイズ毎に、そのサイズを確保したスタックトレースの集合が取得できる)
  3. 統計を比較してとび抜けているものに目を付ける
  4. 2のダンプでそのサイズのメモリを確保したスタックトレース達を見る
  5. スタックトレースを元にソースコードを調査
という流れ(1と2とでと同じ箇所で同じサイズのメモリ確保がされた共通部分が存在することを仮定しているので、2で問題をさせる必要はないが、どういう状態でダンプを取るべきかは工夫する必要がある)を想定して、コマンド bysize を heapstat 2.5.0.0 で追加した。週明けに試してもらうつもり。