「なんで~(;゚▽゚)」と思って、いつものChatGPT先生&Gemini先生&Claude Sonnet先生に相談します。
その結果をまとめると、
1)Werfault.exe(アプリがクラッシュしたとき、自動的にMSに報告するための情報を集めるツール)が取るダンプ(=メモリダンプ(memory dump):当該プロセスのメモリ領域を取ってくる)は最小のものなので、まずはクラッシュしたときのちゃんとしたダンプを取れ。
2)Windbg(Microsoft Storeで無料)で解析しろ。
とのこと。
まず、1)については、
(1) Sysinternal謹製の「procdump」を取ってくる。
(2) Microsoft StoreからWinDbgをインストール
(3) 管理者権限で「procdump -accepteula -e 1 -e -h -ma -w TMIDI.EXE d:\Dumpフォルダ」で、TMIDIがクラッシュしたときにダンプ取るように仕込む。
(4) TMIDI実行→即クラッシュ
続いて2)については、
(1) 取られたダンプ(d:\Dumpフォルダの中に入る)をWindbgに読み込ませる(File → Open Crash Dump)
(2) WinDbgのコンソールで、「.symfix」→「.reload」→「!analyze -v」を順に実行
※ Microsoftのシンボルサーバ設定>シンボル読み込み>解析開始 という流れ。
この結果はこんな感じ。
(前略)
*** WARNING: Unable to verify checksum for TMIDI.EXE
eax=0048d554 ebx=000d1222 ecx=1d370000 edx=0048d554 esi=024c927c edi=00000024
eip=024c927c esp=001aefc8 ebp=001aefe8 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246
024c927c e808000000 call 024c9289
0:000> .symfix
*** WARNING: Unable to verify checksum for TMIDI.EXE
0:000> .reload
.....................................................
*** WARNING: Unable to verify checksum for TMIDI.EXE
************* Symbol Loading Error Summary **************
(中略)
0:000> !analyze -v
......................................................
*** WARNING: Unable to verify checksum for TMIDI.EXE
*******************************************************************************
* * * Exception Analysis * * *
*******************************************************************************
(中略)
EXCEPTION_RECORD: (.exr -1)
ExceptionAddress: 024c927c
ExceptionCode: c000041d
ExceptionFlags: 00000001
NumberParameters: 0
PROCESS_NAME: TMIDI.EXE
ERROR_CODE: (NTSTATUS) 0xc000041d - ユーザー コールバック中に未処理の例外が発生しました。
EXCEPTION_CODE_STR: c000041d
IP_ON_HEAP: 024c927c
(以下略)
…もちろんチンプンカンプンなので、ChatGPT先生に見ていただきましたよ?
上のWinDbgの結果で、一番最後に「IP_ON_HEAP~」とありますよね。
IP = Instruction Pointer(命令ポインタ)のこと。
なので実はこれ、
『(ほんとはやっちゃいけない)ヒープ領域でコードを実行しちゃった。」
という意味なんだそうです。
ヒープはmalloc()で、動的にメモリ領域を確保すると作られるメモリ空間なのですが、現代のOSでの管理上、基本的にはデータ用ということで、権限が読み書きOK・実行不可、となっているんだそうです。
と、ここまで来たらピンときますよね?
要はDEP(データ実行阻止)先生が、ちょっとメモリ管理がアレなTMIDIのオイタを見逃してくれなかったのです。
※おそらくTMIDI側のバグなのでしょうね。
結局のところ、「システム>バージョン情報>システムの詳細設定>データ実行防止(タブ)」で、TMIDI.exeを例外に入れてあげないと、DEPでメモリの扱いが甘いところを叩き落されてしまうのでした。
まあ、いつから引っかかるようになっちゃったかは分からない(以前は動いてたし)のですが、OSにセキュリティパッチが当たっていく中で、厳格化したタイミングがあったのかも知れません。
ともあれ、TMIDIをDEPの例外に入れたら、ちゃんと動くようになりました。
Procdumpすごい、WinDbgすごい、ChatGPTすごい、というところで、このお話は締めさせていただきます。
おあとがよろしいようで。
ちんぷんかんぷんですが、一つ言えるのは、
返信削除『まだTMIDI動くんかい!』
それが一番驚いたわい
そいやlzh系の圧縮ファイルとか全然見ないなと思ってたら、
脆弱性で随分前に無くなってしまってたんやね・・・
使う機会が圧倒的に減ったとはいえ、特に新たに乗り換える必要もないせいか、
terapadとかIrfanViewとかFFFTPとか午後のこ~だとかはまだ現役で使ってるなぁw
少なくとも20年近く使っているもの、といえば以下のような感じです。
返信削除1)エディタ
・Vim
・サクラエディタ
2)ターミナルソフト
・Teraterm
3)音楽
・TMIDI
・午後のこ~だ
4)MUA
・Becky!(ライセンス購入済み)
5)リモート接続
・Ultra VNC
6)FTPソフト
・FFFTP
7)楽譜作成
・musescore
8)画像加工
・GIMP
>lzh系の圧縮ファイルとか全然見ないな
返信削除奥村先生が元のアルゴリズムLZARIを考案し、それを元に医師の吉崎先生が改良したのがlzhだったわけですけど、2010年代に吉崎先生がホームページを閉鎖して、事実上開発終了になっていたみたいですね。
最早lzhに代わって、多種多様なアーカイバが出てきているので、lzhの役割も終わったのかもしれないです。
私も最近はもっぱらWindows環境では7z、Linux環境ではxzばっかり使ってます…。