Windows 10に移行してから、私の環境ではコマンドプロンプトでコンソールアプリを使う度に、高い確率で次のようにエラーメッセージが出力されるようになった。
[0x7FFFB4DF70E3] ANOMALY: use of REX.w is meaningless (default operand size is 64)
ただし上記のメッセージが表示されるだけで、コマンド自体は正しく実行される。
興味深いことに、Windows 10標準の外部コマンド(例えばpingやipconfig)でも発生する。またコマンドプロンプトからGUIアプリ(例えばメモ帳)を起動する場合には発生しない。
C:\tmp>ping -n 4 -w 100 192.0.2.12 [0x7FFD1AEC70E3] ANOMALY: use of REX.w is meaningless (default operand size is 64) 192.0.2.12 に ping を送信しています 32 バイトのデータ: 192.0.2.12 からの応答: バイト数 =32 時間 <1ms TTL=64 192.0.2.12 からの応答: バイト数 =32 時間 <1ms TTL=64 192.0.2.12 からの応答: バイト数 =32 時間 <1ms TTL=64 192.0.2.12 からの応答: バイト数 =32 時間 <1ms TTL=64 192.0.2.12 の ping 統計: パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、 ラウンド トリップの概算時間 (ミリ秒): 最小 = 0ms、最大 = 0ms、平均 = 0ms C:\tmp>notepad.exe C:\tmp>_
エラーメッセージ中の「REX.w」はx86-64絡みのオペコードだ。実際に、この問題は32bit実行ファイルでは発生せず、64bit実行ファイルで発生する。
試しにC言語でhello, worldを書いてみたが、MinGW-w64(gcc 6.1.0)やVisual Studio 2013でビルドした64bit実行ファイルでは同じ症状が見られた。一方で、Visual Studio 2013でビルドした32bit実行ファイルでは起きなかった。
原因は不明だが、とりあえずWindows 10移行時に人柱としてインストールしたウイルスバスタークラウド11を終了させると、上記の症状は発生しなくなる。設定でリアルタイムスキャンを停止しただけでは駄目だったので、起動したプロセスに対するヒューリスティック(ふるまい)検知あたりで問題が起きているのではないかと妄想している。
複合的な要因によるものかもしれないので断言はできないが、少なくともウイルスバスタークラウド11が(結果的に)片棒を担ぐ感じになっているようだ。
悩ましいことに、これが原因でGit for Windows 2.10.0 64bitのGit GUIの起動に失敗しまう。一方でgitkの起動は大丈夫なようだ。gitコマンドも、リポジトリ操作系のコマンドでは上記エラーメッセージが発生して煩わしいのだが、「git --version
」などでは発生しない。どういうことだろう?
さて、どうしようか? 試しにウイルスバスタークラウド10に入れ替えてみるか、ウイルスバスターをこまめにON/OFFするという運用に徹するか、他の逃げ道を探るか。
追記:2016-09-12
コメントをいただいたとおり、ウイルスバスタークラウド11の例外設定に追加することにした。
本来は安全のためにも個々の実行ファイルごとに例外設定を追加すべきだが、対象となる実行ファイルが分からなかったため、「<Git for Windowsのインストール先>\mingw64\libexec\git-core
」というフォルダを丸ごと除外した。これでGit GUIの問題は回避できるようだ。
追記:2016-09-24
Cygwin付属のirbも動作しなくなっていた。irbのREPLに入らずに終了してしまう。
この問題は、Cygwin付属のruby.exeだけウイルスバスタークラウド11の例外設定に追加することで回避できるようだ。
追記:2016-09-27
Mhookのソースコードにそのものズバリの行があった*1。
MhookはWindows API用のフックライブラリで、MITライセンスで公開されているので、ウイルスバスタークラウドに組み込まれていてもおかしくはないだろう。ヒューリスティック(ふるまい)検知が組み込まれたアンチウイルスソフトでは、(少なくともWindows向けのものでは)十中八九APIフックを使っているはずだ。
ウイルスバスタークラウド11がMhookを使っていると仮定すると、問題点は:
- Mhook内部の下位層にはエラーメッセージを抑制する仕組みが存在するのだが、上位層でそれを使っていない。
- デバッグ機能がほしいのは分かるが、しかし他のモジュール・アプリに組み込まれる前提のライブラリが勝手にエラーメッセージを出力したら駄目じゃなかろうか?
- エラーメッセージをprintf(3)で出力している。
- なぜ、fprintf(3)で標準エラーに出力するとか、Windows APIのOutputDebugString()を使うとか、その辺を配慮してくれなかったのだろう?
- Git for WindowsのGit GUIが起動できないのは、printf(3)で標準出力にエラーメッセージを出してしまっているからだろう。Git GUIはTcl/Tkで実装されていて、内部で「git(1)コマンド実行→コマンドの出力をパースして解析」するという、伝統的な「フロントエンド(Tcl/Tk)/バックエンド(コンソールアプリ)」という構成になっている。解析対象のメッセージに意図せぬ「Mhookのエラーメッセージ」が混ざってしまうため、解析に失敗するのだろう。
――と、まあ、Mhookの実装自体に何点か突っ込みどころはあるのだが、しかし悪いのはMhookの作者ではなく、トレンドマイクロの品証部門*2と開発部門*3だろう……本当にMhookを組み込んでいればの話だが。
追記:2016-10-07
続きを id:eel3:20161007:1475843229 に書いた。PowerShellスクリプトの実行形態によって問題が発生しうる模様。