唐突にVBAがクラッシュする現象と原因特定までの流れ

おはこんばんにちは。ことりちゅんです。

今回は先日発生したExcel・VBAがクラッシュする問題と、要因特定に至るまでの経緯を紹介します。

正直レアケースすぎて参考になる人はいないかもしれませんが、読み物として楽しんでいただけると幸いです。

なお、これは「Excel-Fun.xls* for VBA Advent Calendar 2025」の19日目の記事です。

悲劇の始まり

事の起こりは2025年11月上旬。和風スパゲティのブログ筆者：通称スパさんや、Excel-Fun.xls*コミュニティのボイスチャットで行った【Windows 10からアップグレードした人におけるWindows 11のおすすめ設定を探す会】の中でのこと。

スパさんの【VBEを開くとExcelが落ちる】という出来事からすべては始まりました……

これを聞いて私もExcel＆VBEを起動したら、同じようにクラッシュするようになっていることに気がつきました。

スパさんはWindows 11へアップグレードした直後ですから「OSが原因か？」と思いきや、発生していない様子。

Officeのアップデートバグなのでは？と考え、トラブルシューティング御用達のTwitterの海を彷徨うも同じような呟きをしている人は観測できず。

通話メンバーの皆さんのバージョンを確認し、同じバージョンでも発生しない環境もあるということを確認しました。

アドインが原因？

二人が共通して他の方と違う部分と言えば、VBEに「踊るVBEアドインを入れている」という点。

障害切り分けの王道に沿って、「普通ではない環境」を取り除くべく、アドインを無効化したらあっさり解決。

でも、「アドインを入れているだけでクラッシュするなら、大勢のユーザーから報告が上がってもおかしくないのでは……？」という疑問が。

しかし、作者からは「他の人から報告は上がっておらず再現もできなかった」という旨の回答を頂きました。わざわざ中古のパソコンを買ってきて検証してくださったそう。申し訳なさすぎる。

それなら「他に原因があるはず……！」と疑問に思い、必死に模索を続けました。

64bit版なら発生しない？……するかも……した。

「踊るVBEアドイン」はVBAでコーディングするにあたってはバチクソ便利なので、私は絶対に無効化したくありませんでした。そして、その後の調査で「64bit版なら発生しない」ということが分かりました。

私が VBAでWin32APIの64bit対応自動変換プログラムを作ってみた - えくせるちゅんちゅんや VBAでWin32APIの64bit対応自動変換プログラムを作ってみた - えくせるちゅんちゅんや VBAで最速の整数型を調べてみた - えくせるちゅんちゅんなど、Officeのbit数変更に対抗するための技法を上げているように、自分はどちらのバージョンにも対処できるのでこだわりはありません。速攻で64bit常用に変えました。

一方でスパさんは、既存の資産の置き換えコストも考慮すると32bit版は譲れない。踊るアドインを諦めるという選択をしました。

仲良く障害に取り組むはずの二人は、ついに互いの道を違えたのでした……。

……

……しかし数日後。

64bit版に変えて平穏を取り戻したはずの私の元に、あの悪夢が再来しました。

YouTube - 開発ツール別コード比較の登壇を目前に控えたタイミングで始まってしまったのです。

障害の詳細

ここで障害の詳細について整理します。

ブックには依存しない（新しいブックでも落ちる）
常駐ソフトが原因ではない（再起動して色々なプロセスを止めても落ちる）
イベントログにクラッシュ時に GoogleIMEJaTIP64.dll が大量にエラーを起こしていることが分かったのでIMEを変えてみたが落ちる
Excelを開くだけなら落ちない。VBEを開いているときに落ちる
落ちるときは、VBEの上でマウスポインタを動かしたり、わずかに操作した瞬間にフリーズして数秒後に落ちる
アドインを無効化すると落ちない
32bit版ではインストール後すぐに発生し、64bit版ではすぐに発生しないときもある（？）
先日の検証会の直後から、二人が揃って発生している

突然の解決へ

いつもの雑談通話中、64bit版でも再発したことを伝えると、スパさんから「32bit版でアドイン入れたままだよ。なんか、いつの間にか直ったわ」という衝撃の回答が。裏切り者！！！（笑）

「登壇準備が間に合わない、もうだめだ……」と絶望する中、ふと思い出しました。「Windows 11の設定を網羅する会」の中で、「テキストカーソルインジケーター」という珍しい機能をオンにしたことを！！！

画面が大きくなればなるほどカーソルは迷子になりやすいので、「こんな面白いものが標準にあるなら使ってみよう」と軽い気持ちでオンにしてみたのでした。

そして、スパさんも試しにオンにして、後日オフにしたと発言していたことを思い出しました。

「もしかして、コイツが原因なのでは……？」という疑いが強まり設定をオフにすると、今までの不具合が嘘のようにピタリと止まりました。

原因は、OSの標準機能の中にあったのです。

不具合の再現方法

以上を踏まえて関係者へ報告するため、確実な再現手順を検証しました。

その結果、以下の条件を満たしたときに確実にクラッシュすることがわかっています。

アクセシビリティ設定「テキストカーソルインジケーターのプレビュー」がオンであること
「踊るアドイン」が動いていること
（64bit版では）「VBEのプロパティウィンドウ」のコンボボックス（プルダウン）にカーソルが入ったとき

自然に再現させるには、中々に難しい条件なのではないかと思います。

その後、雑談通話メンバーに確認したり、踊るVBEアドイン作者に報告したりして、誰もが再現できることを確認して決着したのでした。

※なお、アドイン作者には「こんな超々マイナー現象に対処する暇があったら、もっと便利な機能追加に集中して欲しい！代わりに症例と回避策の周知の方は任せといて！」と言ってこの記事を書いています。バチクソ便利なので恐れず使ってみてくれるとうれしいな！踊るVBEアドイン

テキストカーソルインジケーターの不具合について

今回の問題を受けて「Windowsのテキストカーソルインジケーターが起因する不具合」について調べた結果を報告します。

Accessのaccdbのオブジェクト数が40とか多めの場合Access終了時にプロセスが残る

https://x.com/ine_ossan_1956/status/1581553313707085824?s=20

Access（Microsoft 365）のaccdb（accde含む）のオブジェクト数が40とか多めの場合、下記設定を〝オン〟にするとAccess終了時にプロセスが残る現象あるのでご注意下さい。（Windows11 22H2の複数PCで確認）

Accessのバージョンが古いと問題ない（2208）