Windowsのオーディオデバイス出てこない問題。強引に解決！、か？

骨伝導ヘッドフォンで有名なShokzのTitaniumヘッドセットを愛用していたのですが、2023年にノートPCを新調してしばらく経ってから、なぜか動作しなくなっていました。その解決方法を強引に見つけたので、いちおう情報共有しておきます。

「いちおう」と枕詞を付けたのは、原因を完全に解明できていないこととレジストリを強引に変更するという荒業を使ったので、誰にでも推奨できる方法ではないからです。なので、この方法を試す場合は「自己責任」でお願いします。この方法でどんなトラブルが発生しても、いっさい責任は持てません！

で、その方法とは、

• レジストリエディタでHKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\MMDevices\Audio\Renderの直下にある各キー（各デバイス）を開いて、DeviceState値を変更する

という方法です。

私のケースでは、ShokzのTitaniumというBluetoothヘッドセットでの問題だったので、"Titanium"というキーワードで該当しそうなレジストリキーを推定した上で、上記のDeviceState値が怪しい値だったので、これを適当と思われる値に書き換えました。「怪しい値」と勝手に決めつけて、「適当と思われる値」を書くという、本当に「適当過ぎる」方法なので怖い方法であることは間違いないです。

問題が出ていた状態では、レジストリ中のDeviceState値に0x8000004のような値が入っていました。DeviceState値の正しい意味は調べがつかなかったのですが、ネット情報として見たのは、

• 0x00000001のとき、そのオーディオデバイスは許可されている（使用可能）
• 0x10000001のとき、そのオーディオデバイスは許可されていない（使用不可）

という情報です。上位の0x10000000部分が使用可／不可のフラグであるっぽいですし、この部分の数値が0x8000xxxxになっているのは問題を起こしていたTitaniumだけだったので、この値が怪しいと推測し使用可能な状態として0x00000001のような値を書いて直ったらラッキー！というくらいの浅い考えで進めています（要は、ダメもと）。

で、具体的にやったことは、このレジストリキーRenderの下の各キーについて、DeviceStateがこの怪しいそうな0x8000xxxxになっているものをすべて、0x1000xxxxに書き換えました。その後、念のためWindowsを再起動してから、おもむろにTitaniumをBluetoothで接続すると、オーディオデバイスとしてちゃんと認識するようになりました。

レジストリエディタで下のようにキーワードで当たりをつけておいてから、

下記のようにレジストリ値を変更しました（下記の例では、元の値が0x80000004だったので、これを0x00000004に変更）。

今回は、Bluetoothヘッドセットで起きた問題でしたが、おそらくBluetoothかどうは関係がないと推測しています。理由は、

• Bluetoothデバイスとしてはちゃんとペアリングも認識もできていた
• デバイスマネージャのBluetoothカテゴリでも、ちゃんと動作しているように見えた（もちろんBluetooth側ドライバもちゃんとインストール済）
• 同じくデバイスマネージャの「サウンド、ビデオ、およびゲームコントローラ」カテゴリにもTitaniumがちゃんと入っていて、ドライバも動作しているように見えていた
• PC内蔵のBluetoothホストを止めて、USB-Bluetoothドングルを使っても不具合は解消されなかった（つまり、Bluetooth側のドライバの問題ではなさそうと判断）
• しかし、デバイスマネージャの「オーディオの入力および出力」カテゴリには、どうしても現れなかった（他のオーディオデバイスはちゃんと出ている）
• Windows11のシステム設定→システム→サウンド→すべてのサウンドデバイスを開いてみても、ここに問題だったTitaniumが現れることはなかった（他のオーディオデバイスは問題なかった）
• 別のPC（Windows10やWindows11）とTitaniumを使うのに問題は発生していない
• 問題のPCとTitaniumとの組み合わせの場合でも、Windowsをリカバリ状態まで戻すと正常に動作した
• ネットで検索すると、Bluetoothオーディオ機器に限った話ではなく、オーディオデバイスが見つからなくなるという不具合情報がちらほら散見された

といったことが挙げられます。

これらのことから、どうもWindowsのオーディオデバイスの管理上の問題があり、Windows Updateなどを繰り返すウチに不具合が出るようになった可能性が高いと踏んだわけです。

クドいですが、このような感じでやっていることなので技術的な裏付けがある訳ではありません。レジストリをいじるので、もし同じことをやってWindowsが起動しなくなっても責任は一切持てません。どうしても試したい人は、レジストリのバックアップだけでなく、システムバックアップ＆リカバリの手段を用意したうえで、十分に時間があるときに行うようお願いします。

もしも、この方法で直ったという方がいらっしゃいましたら、何らかのコメントを残していただけませんか？「この方法で直った」という情報がある程度集約できたとすると、同様の問題でお困りの方の参考になるかも知れませんので。

[備忘録] XilinxのISE 14.7 on VMをインストールできないとき

xsetup.exeを実行してインストールを始めてすぐに、"Installation cannot be performed, please fix the issue before installing. Virtualization is not enabled in BIOS. please enable before installing"と表示されてインストールが進められないときは・・・

 

• インストールパッケージのbin/validate_virtualization_enabled.ps1スクリプトの3行目あたりを下記のように書き換えておく
  

  
  # Detect if BIOS is setup to enable virtualization
  #$is_vm_enabled = Get-CimInstance -ClassName win32_processor | select-object -expand VirtualizationFirmwareEnabled
  $is_vm_enabled = $TRUE
  
  if ($is_vm_enabled)
  {
      "Virtualization is enabled"
      $host.SetShouldExit(0)
      exit
  }
  else
  {
      # if hyper-v is enabled windows will report that virtualization is disabled
      # check whether hyper-v is enabled
      $hyperv_enabled = (Get-WindowsOptionalFeature -Online -FeatureName "Microsoft-Hyper-V-Hypervisor").State -eq "Enabled"
      if ($hyperv_enabled)
      {
          "Hyper-V is enabled, please disable before installing."
          $host.SetShouldExit(2)
          exit
      }
      else
      {
          "Virtualization is not enabled in BIOS, please enable before installing."
          $host.SetShouldExit(2)
          exit
      }
  }
  
  

BIOS/UEFI上でvirtualizationはenableにしているし、Windowsのtask managerでも仮想化＝有効となっている。実際、DockerもWSLも使えている。なのに、XilinxのISEインストーラはVirtualization機能が有効になっていないと言って、インストールが進められなかった。

原因は、PCのWin32_ProcessorクラスにあるVirtualizationFirmwareEnabledが何故かFalseを返していたせい。別のPCで確認しても（もちろん、そのPCも仮想化には対応していて、BIOS／タスクマネージャは有効を示しており、Docker&WSLも使えている）、同様にこの値はFalseを返していた。
ネットで調べると、こういう機種は多く、仮想化機能の有効化をチェックする方法としてVirtualizationFirmwareEnableをチェックする方法は不適切＆不確実らしい。このせいで、世界中の多くのISEユーザーは苦しんでいるに違いない。

なので、自己判断で仮想化はちゃんと使えるはず！と思うならば、上記のvalidate_virtualization_enabled.ps1スクリプトファイルを書き換えてしまおう。幸いにも、読めばすぐに理解できるスクリプトファイルで判定しているようなので、書き換えは容易だった。もし、コンパイル済みのバイナリ実行コード中でこのような確認処理が行われていたなら、見つけられなかっただろう。

[備忘録] OpenOCDをLPC18xx(LPC1800系LPC1857)で使う

• OpenOCDに含まれるコンフィグレーションファイルlpc1xxx.cfgは使えそうに見えるが使えない
• コンフィグレーションファイル中のflash bankの設定では"auto"ではなく"lpc4300"を明示的に指定する

OpenOCDはLPC18xxをサポートしているが、LPC17xxなどのように各品種を包括的にサポートする（ほぼできそうな）lpc1xxx.cfgのようなコンフィグレーションファイルは存在しないようだ。わずかに、lpc1850.cfgのような一部のみサポートするコンフィグレーションは存在するが、flash bankやworkareaといった定義・設定がないか、不十分だと考えられる。

また、lpc1xxx.cfgで使用されている

# flash bank <name> lpc2000 <base> <size> 0 0 <target#> <variant> <clock> [calc checksum] [iap entry]

set _IAP_ENTRY 0

if { [info exists IAP_ENTRY] } {

    set _IAP_ENTRY $IAP_ENTRY

}

set _FLASHNAME $_CHIPNAME.flash

flash bank $_FLASHNAME lpc2000 0x0 0 0 0 $_TARGETNAME \

    auto $_CCLK calc_checksum $_IAP_ENTRY

というflash romの定義は"auto"とあることからLPC18xxでも使えそうな気がするが、実際には"auto"は機能しない。OpenOCDのソースコードを見て分かったのは、"auto"設定で対応可能なのはIAP（In-Application Programming）のテーブルアドレスが0x1fff1ff1に置かれているLPCデバイスに限られる。

一方、LPC18xxのIAPテーブルアドレスは0x10400100に書いてあるアドレスを読み出すことで得られる。この方式はLPC43xxシリーズと同じ方法で、実際のところflashのバンク構成などもLPC43xxの方が近い。Cortex-m3（LPC18xx）とCortex-m4（LPC43xx）の違いはあるが、どちらかというとLPC43xx用のコンフィグレーションを参考にして、LPC18xx用のコンフィグレーションを一から書いた方が早そうである。

Google日本語入力を止めるべき・・・か？

最近 Google日本語入力を使うと・・・・

• Windows Terminalを起動したとき、勝手に日本語入力モードになっていて、コマンドを入れようとすると全角文字になってしまう
• 特に最近、マイクラ（Windows BE版）がピタリとフリーズするようになった

という問題が立て続けに出るようになった。

Windows Terminalの件は、面倒だけど起動するたびに日本語入力をオフにすればよい（半角／全角キーを押すか、無変換キーを押せばよい）。まあ、ターミナルは一度立ち上げてしまえばだいたい開きっぱなしだし、bashなどの新しいタブを開く場合はこの問題は出ないから、まあ許容範囲と思っていた。

しかし、マイクラがいきなりフリーズするのは困ったものだ。いきなりマイクラだけピタリと止まるが、他のアプリは問題ない。そして、フリーズするのは画面表示＋操作だけのようで、フリーズしている間もマイクラの時間は進んでいる気がする。そのまましばらく放置していると、どうやら夜になってモブに殺されているようだ。次回起動したとき、持ち物や装備が全部無くなっていた。ダイヤのツルハシとかも・・・。

マイクラを使う際、Google日本語入力ではなくMS-IMEに変更しておくとフリーズしなくなることに先日気がついた。今のところ、MS-IMEに変えてからはフリーズしていない。でも、何でだろう？

原因はよく分からないが、とりあえず回避策は分かった。

そう言えば、MS-IMEが出始めの頃は漢字変換があまりにもヒドかったのでそれ以来「食わず嫌い」のように問答無用で避けてきたが、それから10年以上経ち、もしかすると最近のは「使える」レベルになっているのかも知れない。巷では、Google日本語入力だって漢字変換はバカだと言われているようなので、MS-IMEもそんなに毛嫌いするほどのものではないのかも知れないな、と思い始めている。Google日本語入力の方は、先に書いたような問題が出始めているので、「そろそろMS-IMEに戻れ」との知らせなのかも。

AnyDeskからRustDeskへ

 最近RustDeskを知ったので、AnyDeskからRustDeskに移行してみました。

RustDeskの方が後発（だと思う）ですが、これ、完全にAnyDeskを意識していますね。すごく似たような表示だし、ほとんど同じように使えます。

比較表を作ってみました。ただし、Windows版での動作評価限定です。LinuxやAndroid版は使っていないので、詳しくは知りません。

比較項目	AnyDesk	RustDesk
インストール必要？	インストール無しで使用可	インストール無しで使用可
UAC操作（※３）	対応（要インストール）	対応（要インストール）
特権レベルウィンドウの操作（※４）	可（要インストール）	可（要インストール）
接続の簡単さ	数桁のIDを入力	数桁のIDを入力
無人接続	可（パスワード設定後）	可（パスワード設定後）
画像のきれいさ	まずまず	やや粗い
表示ラグ	少ない	やや遅れる
ファイル転送	可	可
クリップボード共有	可	可
音声再生	可	可
チャット機能	有	有
英語←→日本語切替 （IME操作）	難あり	ALT+漢字キー または 変換キー
CTRL+ALT+DEL対応	対応	対応
デスクトップLock対応	対応	対応
TLS	対応	対応
自前サーバ対応（※１）	不可	可
マルチディスプレイ対応（※２）	不可	不可
商用利用	有償	制限なし
目立った不具合	ローカルPC側でまれにWindowsキー、SHIFT/CTRLキーが使えなくなる	アンダースコア"_"入力不可

※１：サーバとは、ホールパンチング処理と接続先の管理を行うものでRustDeskでは自前のPCをサーバにすることで、反応速度とセキュリティを向上させることが可能なようです。

サーバを自前で建てなくても使用可。その場合は、どこかのサーバを経由して接続管理がされるようです。

AnyDeskの方は、ベンダーのサーバを使うのでしょうか。詳しくはよく分かりませんが、画面共有開始時のホールパンチングにインターネット上のサーバにいったん接続することは確実だと思われます。

※２：「マルチディスプレイ対応」とは、リモート側PCがマルチディスプレイ構成のときにそれぞれのディスプレイ（デスクトップ）の内容を、ローカルPC上で表示・共有できるか？という意味です。残念ながら、リモート側PCのプライマリディスプレイの内容しか、こちら側で表示・操作できないようでした。（セカンダリディスプレイを表示・操作できる方法があれば教えてください）

※３：リモート側でUACが入る操作（アプリのインストールなど）を行った時に、操作ができるかどうか？ということです。AnyDesk/RustDesk共にインストールしておけば、UAC操作になってもちゃんと遠隔操作できます。（特権レベルで実行されるサービスとしてインストールされる模様）

インストールしていない場合は、リモートがUACになった途端、こちらから操作できなくなるので注意。

※４：AnyDesk/RustDesk共、インストールなしで起動している場合は、リモート側で特権レベルで実行されているアプリはこちら側から操作できません。Windowsタスクマネージャがその一例です。タスクマネージャを起動することはできますが、そのウィンドウ内を走査してタブを切り替えるといった操作ができません。

AnyDesk/RustDeskをインストールしておけば、UAC同様、問題なく操作できます。

不具合については、AnyDeskはWindowsキーや、SHIFT/CTRL/ALTキーがAnyDeskにキャプチャされてしまうことがあるので、ローカルPC側でWindowsキーを押してもSTARTメニューが開けなかったり、英文字入力がすべて大文字（SHIFTキー押しっぱなし？）になることがありました。

特に、AnyDeskでリモートに接続しようとしている最中に、Windows+CTRL+←（または→）操作で仮想デスクトップを切り替えると、必ずWindowsキーがキャプチャされたままになって、STARTメニューが開けません。また、同じ操作で別の仮想デスクトップ画面に切り替えることも出来なくなります。

これを解消するには、タスクトレイにあるAnyDeskを強制KILLすることです。これで再びWindowsキーが使えるようになります。

同じWindowsキー絡みでは、リモートPC側でWindowsキーを押すと、リモート側だけでなく、ローカルPC側でも同時にSTARTメニューが開いたり閉じたりすることがあります。これも、キー操作のキャプチャ処理がリモート側なのかローカルPC側なのかがおかしくなっているものと推測されます。

更にAnyDeskの話ですが、IMEに日本語・英語切り替えがダメです。リモート側で日本語入力しようとして漢字キーを押すと、リモート側で日本語モードになると同時に、ローカル側も日本語モードになってしまうので、とてつもなく入力しにくいです。マウスでタスクトレイをクリックして日本語・英語切り替えすれば回避できますが、いちいちマウスでクリックする人はほとんどいないでしょう。

この問題を解決するAnyDesk-IME-Off-controlという便利なツールを作ってくれている人がおられて、これを使うと少し幸せになれます。なぜ「少し」だけなのかは、このツールを使っていても、やっぱりリモート／ローカルで同時に日本語モードになってしまうことがあったからです。理由や再現方法ははっきりしませんが、何かを契機にして比較的頻繁にそういう現象が起き始めます。

RustDeskの致命的な不具合は、リモート側にアンダースコア"_"が入力できないことです（バージョン1.1.9で確認）。これは、githubでも不具合報告されています。回避策は、日本語モードにして「した」を変換する方法があります。他には、クリップボードに"_"をコピーして貼り付ける方法があります（が、面倒過ぎるので、早く直してほしい）。

RuskDeskもWindowsキーを押しっぱなし（キャプチャしっぱなし）問題が発生することがありますが、現象は少し違っていて、こちらは比較的軽微な問題です。リモート側で何かキー操作（例えば「１」を入力）をしようとすると、同時にその操作がローカルPC側でも「Windows+1キー」と認識されてしまうことがあります。つまり、リモートPCには「１」が入力され、同時にローカルPC側ではMS-Edgeが起動（タスクバーにピン止めしている１番目のアプリが起動）することがあります。

こちらも、不具合のきっかけは、仮想デスクトップの切り替え操作（Windows+CTRL+←）と関係がありそうです。そういう操作をしない人は、この問題は出ないのかも知れません。

解決方法は、リモート側とローカルPC側の両方で、落ち着いてWindowsキーを１回しっかりと押すことです。これでキー入力の異常なキャプチャ状態が解消されるようです。

DSG トランスミッションエラー

 パサートヴァリアントB8ですが、このモデルは先代までのDSG不具合は払拭されていると思っています。しかし、先日2022/10/16に突然「トランスミッションエラー」と表示されました。いつ、どのように発生したのか、あとで見つけられるよう、備忘録として残す。

周りにまったく車が居なくてよかった。土手沿いの道で、他に走る車も人も皆無でした。

加速の途中だったと思います。たぶん、３速→４速か４速→５速にシフトアップするときだと思います。加速中のはずなのに、一瞬、軽く減速Gを感じました。その瞬間、「ポーン」という音とともに、インジケータに「トランスミッションエラー」と出ました。

後から思うと、もしかすると４速→５速とシフトアップするはずが、４速→３速にミスったのではないかと。推測ですが。でも、エンジンは唸ってなかったから、違うかなぁ。

「トランスミッションエラー」表示に続いて、「ACCは使用できません」、更に、「ブレーキを踏んで下さい」が繰り返し出ました。その後も少しの時間はアクセルを踏み続けていたと思いますが、車の挙動自体は特に異常は無かったです。ガリッ、ゴリッというような異音がしたり、ガタガタ震えるようなこともありませんでした。ただ、アクセルを踏み続けた割には、加速はしていなかったような。。。でも、空ぶかしにはなっていなかったです。

うわぁ、ついに来たっ！DSG載せ替えかっ！と思いました。とりあえず、周りに車は居なかったので、その場で車を停めました。止まった段階では、黄色の！ランプが表示されたままでまだ異常を示している状態でした。そこから、一旦ギアをPに戻すと、その時点で異常ランプは消えました。えっ！、直ったのかな・・・と。

後ろから車が来ていないことを確認しつつ、おもむろにDレンジに入れ、異常ランプが点かないことを確認して、再発進しました。またいつ起きるかと恐る恐るでしたが、その後は現象は起きませんでした。

その後、100km以上走りましたが、特に何ともありません。今まで通りです。何だったんだろう？

「トランスミッションエラー」表示は、何年か前に１度だけ発生したことがあります。その時もたぶん加速中だっと思いますが、エラー表示は一瞬だけだったと記憶しています。

加速中、いきなり「ポーン」と警告音がなったので、メータに目をやるとその瞬間に「トランスミッションエラー」の表示は消えましたが、目の中に残った瞬間の残像で何とかエラーの文字が読めた、というくらい一瞬の表示でした。

前回起きたのはもう何年も前で、走行距離もまだ３～４万kmくらいの頃だったので、DSGに不具合を抱えているというよりは、何かの悪いタイミングでエラーが出ただけと思っていました。

しかし、走行距離が20万kmを超えた今、色んなところにガタが出始めている可能性も否定しきれず、その一つがDSGなのだろうか？もしそうならDSG載せ替え＝修理費数10万円コース？と思うと、戦々恐々とします。

しばらくの間、高速道路に乗るのは少し控えるべきかなぁ。

[備忘録]VivadoプロジェクトがRead-onlyになって開けなくなったときの対処

 Vivadoを使ってFPGAの開発をしているとき、何かの拍子でプロジェクトが開けなくなったことが何度かあった。プロジェクトが何故かRead-onlyモードになり、すべてのIPコアがLockされた状態になって、Synthesis/Implementを含むすべての操作が禁止される状態になることがあった。

Xilinxのフォーラムでも質問が出ていたが、有益な情報はなかった。

https://support.xilinx.com/s/question/0D52E00006lLhAGSA0/vivado-project-converts-to-read-only?language=ja

これまでは、プロジェクトディレクトリを丸ごと削除して、新しくソースをgitからcheckoutしてなんとかやりくりしていたが、ようやく原因と解決方法が分かったので、その備忘録を記録。

（原因）

IPコアのディレクトリに、コンテナ化（Enable Container）したIPコア名と同じ名前のサブディレクトリが存在するときに発生する。

（対処方法）

そのIPコアをコンテナ化しているならば拡張子.xcixファイルだけあれば良いので、同名のサブディレクトリを削除する。

例えば、コンテナ化したmyIP.xcixファイルがプロジェクトにあるならば、myIPという名前のディレクトリは削除する。

このことに気付いてからよくよくTclコンソールをよーく見てみると、ちゃんと原因が出力されていた！

CRITICAL WARNING: [Project 1-635] The core container source file '（プロジェクトのIPが置かれるディレクトリ）/hogehoge.xcix' is sitting next to the IP directory '（プロジェクトのIPが置かれるディレクトリ）/hogehoge'. This configuration is not supported and will lead to unexpected behavior. The project will be opened as read-only. To resolve the issue, please move aside the IP directory and reopen the project.

WARNING: [Project 1-312] File not found as '（プロジェクトのIPが置かれるディレクトリ）/hogehoge.xci'; using path '（プロジェクトのIPが置かれるディレクトリ）/hogehoge.xci' instead.

なぜこんなことになったのかはっきりしたことは覚えていないが、そういえばコンテナ化IPファイル.xcixはバイナリファイルなのでgitでは扱いにくいなと思って、コンテナ化を解除（Disable Container）したことがあった。そのときに作られた（だろう）サブディレクトリが残っていたのかも知れない。

[備忘録] Git For Windowsをアップデートしたらリモートリポジトリにpush/fetchできなくなった件

Git For Windows 2.33.1以降で発生する模様。

OpenSSHのバージョンが8.8以上に上がると、ssh接続時にデフォルトでRSAキーの使用が禁止されるようになったせいらしい。

RSAを使用している場合、非推奨ながらsshのconfigに

PubkeyAcceptedAlgorithms +ssh-rsa

を追加すると、とりあえずこれまでどおりRSAで接続は可能になった。

しかし、この方法はいつまで（安全に）使えるのだろう。

[備忘録]Windows11 Explorerの右クリックメニューの反応が遅くなる件、解決（か？）

「 Windows11の」と書いたけれど、Windows10を使っていた頃から出ていた現象、Explorerの右クリックメニュー(コンテキストメニュー）でしばらくフリーズする件について、ようやく解決方法が分かったので、その備忘録。

現象はWindows10の頃から出ていた。Windows11が出た頃、もしかして直るかもしれないと淡い期待を込めてアップデートしたけれど、結局は直らずじまい、だましだまし使ってきたけれど我慢の限界が来て調べてみました。

現象の回避策としては、

・TortoiseSVN用のIcon Overlay Handlerを無効にする

というものでした。

えっ！？Context Menu Handlerではなく、Icon Overlay Handlerの無効化！？

確かに変です、でもこれを無効にすることでコンテキストメニューはスッと表示されるようになりました。

これまで、メニューが表示されるまでに10～30秒くらい待たされることがありました。一度メニューが表示されるようになると、続けて右クリックするとすぐに表示されていました。しかし、何分か別の作業をして再度Explorerに戻ってメニューを開こうとすると、また何十秒も待たされました。Explorerとは別のファイラーを使っても、コンテキストメニューを表示させようとすると同じ現象が発生していました。本当にイライラしながらも何とか我慢して使っていましたが、これでイライラから解放されました。

最終的には、フリーソフトのShellExViewが大変役に立ちました。手軽にContext Menu HandlerをEnable/Disable切り替えができるので助かりました。

Shell ExtensionのContext Menu Handlerのどれかが悪さしているだろうことは想像に難くないので、自前のテストプログラムを作り、レジストリを走査してContext Menu Handlerを実装しているWindows内DLLをロード＆COM経由でハンドラを呼び出すようなテストをして調べていたのですが、作ったテストプログラムでは極端に遅くなる現象がどうしても再現せず、ほとんど諦めていました。

別の方法としては、ExplorerをVisual Studioのデバッガにアタッチしてシンボル情報（とは言っても、Windows系DLLのシンボルしか入手されませんが）や、デバッガ上のDLLロードタイミングなどから問題のDLLを探そうともしていましたが、こちらも問題の特定には至らなかったです。

それにしても、なぜIcon Overlay Handlerの無効化が回避策となり得るのか、本当に不思議です。でも、いいんです。PCなんてダマシダマシ使うものと割り切ってますから。

[備忘録]ブラウザがERR_CERT_COMMON_NAME_INVALIDエラーを出してページが開けない！

 自分用の備忘録。

今まで、ちゃんとアクセスできていたあるページがブラウザで開けなくなりました。何度やっても、「この接続ではプライバシーが保護されません」(ERR_CERT_COMMON_NAME_INVALID)と出ていました。

原因は基本的には証明書絡みなのだと思いました。ググると色々と出てきますが、今回の私のケースに当てはまるものは無かったので、ここで記録することにします。

原因は・・・・

• ESET Internet Securityが悪さをしていた！

ということだったようです。

というのも、この現象が発生したPCは２台あってその２台ともESETをアンインストールした時点で問題がなくなりました。その後、ESETを再インストールしてもエラーは再現せず、正しく目的のページが表示される状態に直りました。

確かに、エラーメッセージに、ESET SSL Filter CAなんたら～というのが出ていました。ググったところによると、ESETはhttpsでデータを取得するとき、ESET自身がhttpsで暗号化されたデータを取得したあと、PC内で一旦展開して内容をチェック、更にESET自身の証明書を付けてデータを元アプリに渡すとか何とか・・・（ゴニョゴニョ、詳しいことはよく分かりません！！中間者攻撃がやる方法と同じような方法で接続先との間に立って内容をチェックしているとか何とか・・・）。今回はどうもその部分が何故かぶっ壊れていたのだろうと推測します。

この問題が出ておかしくなったPCは２台。その他にも、ESETを入れているPC４台で調べてみたけれど、この現象は出ていませんでした。何か発動条件があるのだろう。

ちなみに、ERR_CERT_COMMON_NAME_INVALID問題が発生している状態で、そのエラー・警告を無視して続行すると、変なページに飛ばされていました。例えば、えいちてぃーてぃーぴー　コロン　スラッシュスラッシュ vebee ドット info とか（↓）、

他には、何故かApache2 Ubuntuのページとか（↓こんなヤツ）。

「飛ばされる」とは言ってもリダイレクトではなく、ブラウザのアドレスバーは自分で入力したURLのままで、ページの内容がこれらの妙なページが表示されるという不思議な状態でした。