令和8年度熊本地震

2016年から10年、熊本は再び大きな地震に被災してしまいました。

熊本は、学生時代の6年間暮らした第二の故郷ともいうべき愛着のある場所で、私も大変ショックを受けております。

熊本の皆様、近隣の皆様のご無事を心よりお祈り申し上げますとともに、被災された皆様に心よりお見舞い申し上げます。

TMIDIがクラッシュするようになったときの対策

最近、久々にTMIDIで昔のMIDI聞こう♪と思ってダブルクリックしたら、何故か起動時にクラッシュして起動しなくなっていました。 

 「なんで～（;ﾟ▽ﾟ）」と思って、いつものChatGPT先生＆Gemini先生&Claude Sonnet先生に相談します。 

その結果をまとめると、 

１）Werfault.exe^※1が取るダンプ^※2は最小のものなので、まずはクラッシュしたときのちゃんとしたダンプを取れ。 

※1 アプリがクラッシュしたとき、自動的にMSに報告するための情報を集めるツールのこと。
※2 メモリダンプ(memory dump)：当該プロセスのメモリ領域を取ってくること。

２）Windbg(Microsoft Storeで無料)で解析しろ。 

とのこと。 

まず、１）については、 

(1) Sysinternal謹製の「procdump」を取ってくる。 

(2) Microsoft StoreからWinDbgをインストール 

(3) 管理者権限で「procdump -accepteula -e 1 -e -h -ma -w TMIDI.EXE d:\Dumpフォルダ」で、TMIDIがクラッシュしたときにダンプ取るように仕込む。 

(4) TMIDI実行→即クラッシュ 

続いて２）については、 

(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すごい、というところで、このお話は締めさせていただきます。 

おあとがよろしいようで。

ちょっと面白い（？）FAQ

 たまたまITMediaの記事を見ていて、おもしろいな～と思ったのが、

「iPhoneの調子が悪いです」の文言、なぜアイホンのFAQに？　実はAppleと深く関係

でした。

まあ、日本においてはiPhone(アイフォーン)の商標権が、インターホンメーカーのアイホンにあるというのは、有名な話ですよね。

で、この話題のFAQがこれ。

IT業界に暮らしていたら（いや、そうでなくとも）、「iPhone＝Apple社」の製品という図式は理解できていると思うのです。
しかしながら、このFAQがあるということは、ひょっとして過去に問い合わせが少なからず届いたことがある、ということなのかな？と思った次第です。

先ほどのITMediaより記事を引用すると、末尾のほうに

『アイホンが自社のFAQで他社製品について言及することは、権利者としての立場を明確にするとともに、ライセンス料を得ていることの責務とも解釈できる。』

とあります。

ただ、ここの解釈には少し違和感があり…。

そもそも、権利を持っているのはアイホン社であり、その権利をライセンス料を払って利用しているのがApple社なのだから、アイホン社は適正なライセンス料を支払われている間は、その商標の利用権を認め続ける義務がある、というのは理解できるのですよね。

ただ、貸し出す権利者側に、それ以上の義務があるのかと言われると、どうなのかなぁと。

商標法には、権利者側が商標を許諾できる旨は書いてあるものの、権利者側の義務を具体的に定めるものはないような気もしますし、結局はApple社とアイホン社の契約に基づくものなのでしょうかね。

両社の契約内容が開示される機会はないでしょうが、その中で義務が定義されていたら別なのでしょうけど。

詳しい人がいたら、後学のために伺ってみたいですね。