GetSettingの参照先について

Question

さっそくですが質問です。

VBAにてSaveSetting関数およびGetsetting関数を使ってレジストリを操作した場合、「HKEY_CURRENT_USER\Software\VB and VBA Program Settings」を主キーにするものと認識していました。

この認識の元、ツールを開発して配布していましたが、このたび、エンドユーザーから不具合の報告がありました。

調査の結果、SaveSetting関数およびGetsetting関数の場所が、上記以外になっていることが判明しました。

このように判断したのは、Regeditで当該場所を目視した結果です。

当該ツールは、これまで、数年にわたって数百人の方が利用し、安定的に動作していましたが、今年になってから別々のユーザーから報告がありました。

この現象は、何でしょうか？

主キーが変わる原因について、どなたかからお教え頂ければと思います。

Answer 1

ちなみに、現象が発生しているのは、Windows10(64bit管理者ユーザー)+Excel2016(32bit)で、バージョンは1912です。

ただし、同じく1912の別機（クリーンインストールされたWindows10(64bit)+Excel2016(32bit)）では現象は発生しません。

Answer 2

環境を持っていないので私は検証できませんが、確認事項としては

• 実際にはレジストリのどこが書き換わっているのか？（レジストリ監視ツールなど使えば確認できるでしょう）
• SaveSettingしたデータをGetSettingできないのか、それともSaveSettingしたのをGetSettingとは別の方法で取得できない or SaveSettingとは別の方法で書き込んだのをGetSettingで取得できないのか？

Answer 3

Hongliang様

ありがとうございます。

> 実際にはレジストリのどこが書き換わっているのか？（レジストリ監視ツールなど使えば確認できるでしょう）

エンドユーザーにお願いしなければならず、事実上、難しいのです。

> SaveSettingしたデータをGetSettingできないのか、

> それともSaveSettingしたのをGetSettingとは別の方法で取得できない

> or SaveSettingとは別の方法で書き込んだのをGetSettingで取得できないのか？

VBAのSaveSettingで書き込んだデータは、VBAのGetSettingで読むことはできます。

VBAからVB6製プログラムを起動し、VB6製プログラムからSaveSettingにより同じ場所にデータを上書きしている（つもり）のですが、VBA側のGetSettingで読み込みできません。

（正確に言うと、一部のパソコンで読み込みができない）

Answer 4

該当の Excel が、C2R 版、MSI 版、ストア版のいずれであるかは確認されましたか? （自分は環境を持っていないので検証できませんが…）

• Microsoft ストア アプリ版 Office 2016 (Centennial) での開発 – その1 – (DLL の読み込み)
• Office の製品名、バージョン、デスクトップ/ストアアプリ版の確認方法 (Windows)

Answer 5

魔界の仮面弁士様
ありがとうございます。

> 該当の Excel が、C2R 版、MSI 版、ストア版のいずれであるかは確認されましたか?

いえ。確認していません。
（クライアントはさほど詳しくはないため、頼みづらいという側面があります。）

長々と書きましたが、今回の事象は、以下に集約されます。
C2R 版、MSI 版、ストア版のいずれであるかにより、影響しそうでしょうか？

-------------------
下記条件でメッセージボックスを表示すると、なぜか「0」と表示される。

　レジストリの記述内容↓
　キー：HKEY_CURRENT_USER\Software\VB and VBA Program Settings\test\hoge
　名前：sample
　種類：REG_SZ
　値：1

　マクロ構文↓
　MsgBox GetSetting("test", "hoge", "sample", "0") '←なぜか「0」になる
-------------------

Answer 6

同種の事例は幾つか見つかりますが…解決策が見当たらないですね。

• Click-to-run Office 2010, virtualization and registry settings problems with Add-In
• VBA SaveSetting result not visible in registry
• VB and VBA Program Settings are invisible in RegEdit but accessible via VBA

　

C2R 版、MSI 版、ストア版のいずれであるかにより、影響しそうでしょうか？

自分は MSI 版しか使っていないので確証は持てませんが、変わる可能性はあると思っています。先ほど紹介した記事でも、下記の記載があったわけですし。

『この方法で提供される Office 2016 はユニバーサル Windows プラットフォーム (UWP) でパッケージ化されています (デスクトップ ブリッジという方法を用いています)。このような仕組みを Centennial とも呼ぶため、Microsoft ストア版 Office は「Office Centennial」とも呼ばれます。UWP パッケージ化されたアプリは、ファイル システムやレジストリなどが UWP パッケージ独自の構成となり、また、動作上もそのままアプリを実行する場合とは異なる点があります。』

---

また、COM コンポーネントやオートメーション等で外部連携する場合、ストア版 Office だとうまくいかず、デスクトップ版をインストールしたことで回避できるという事例は、度々目にしています。今回の事例もそうであるとは限らないですけれども。

• ストア版だとアドインが使えないので、デスクトップ版への入替を提案している事例
• ストア版とデスクトップ版の違いを紹介している記事
• ストア版の COM 公開方法の違い(Desktop Bridge 関連)の記事

Answer 7

魔界の仮面弁士様

引き続きありがとうございます。

「ファイル システムやレジストリなどが UWP パッケージ独自の構成となり」というところがきな臭いですね。

これが影響している可能性が高そうなので、エンドユーザーの方に調査の協力を要請してみたいと思います。

結果が出ましたら報告させて頂きますね。

Answer 8

> ちなみに、現象が発生しているのは、
> Windows10(64bit管理者ユーザー)+Excel2016(32bit)で、
> バージョンは1912です。
> ただし、同じく1912の別機
> （クリーンインストールされたWindows10(64bit)+Excel2016(32bit)）
> では現象は発生しません。

上記環境条件でまず思いつくのは WOW64 によるリダイレクトですが、クリーン インストール環境では起きないのであれば、3rd ベンダー製のなんかのソフトの影響が高いのでは？
Excel プロセスに対して DLL Injection (あるいは Code Injection) を行う 3rd ベンダー製ソフトウェアが存在し、その影響でレジストリ キーへのアクセスがリダイレクトされているとか。
今回の件に該当するかはわかりませんが、例えば Sand Box 配下で実行されるプロセスのレジストリ アクセスは、Injection された DLL あるいは関連するレジストリ制御用のドライバによりリダイレクトされるのが一般的だと思います。

まずは 3rd ベンダー製ソフトウェアの影響かどうかを切り分けるためにも、問題の発生する環境と発生しない環境それぞれで、Process Monitor による該当処理時のキャプチャを採取し、Excel プロセスにロードされている DLL 等のモジュールに差異がないか (特に 3rd ベンダー製の DLL)、確認されることをお薦めします。

Answer 9

お馬鹿様

お名前に似合わず、天才的なご回答ありがとうございます。
WOW64 によるリダイレクトについては頭をよぎったものの、エクセルマクロの場合は該当しないものと認識していました。
挙動がサンドボックス内で動作している感じに似ているな、と思いはしたものの、具体的な対応を思いつかず、とりあえずセキュリティソフトの一時停止を試してもらったのですが、効果はありませんでした。
セキュリティソフト以外でインジェクションを行うようなソフトの存在は、顧客層的に考えづらい（しかも別々の顧客で同時期に発生）ので、可能性は低いかもしれません。
目下のところ、「ストアアプリ版であるか」という点が怪しいので、調査をお願いしているところです。

Answer 10

手元の環境で、Excel VBA のイミディエイトから
　SaveSetting "MyAppName", "MySection", "MyKey", "MyValue"
を実行して、regedit で確認してみました。

ストア版が手元に無いので、ひとまずそれ以外の環境での実験結果ですが、下記いずれの環境においても、
HKEY_CURRENT_USER\Software\VB and VBA Program Settings\
が利用されていました。ストア版の環境を見つけたら追記します。

1. Microsoft Office Professional Plus 2016, 32bit, C2R版
   バージョン 1912 (ビルド 12325.20288 クイック実行) 月次チャネル
   Microsoft® Excel® 2016 MSO (16.0.12325.20280) 32 ビット
   
2. Microsoft Office Professional Plus 2013, 64bit, MSI版
   Microsoft® Excel® 2013 (15.0.5207.1000) MSO (15.0.5172.1000) 64 ビット
   
3. Microsoft Office Professional Plus 2019, 64bit, C2R版
   バージョン 1912 (ビルド 12325.20298 クイック実行)
   Microsoft® Excel® 2019 MSO (16.0.12325.20280) 64 ビット
4. Microsoft Office Personal 2019, 64bit, C2R版
   バージョン 1912 (ビルド 12325.20288 クイック実行)Microsoft® Excel® 2019 MSO (16.0.12325.20280) 64 ビット

Answer 11

Win10 / Excel2016 (C2R) , Excel2010 ですが、

Excel2016/Excel2010 ともに下図の場所になっていますね。

数字の羅列のキーについては下記サイトを参照してください。

レジストリキーのSIDからユーザアカウントを識別する方法

https://tipstour.net/windows/2194

Answer 12

AddinBox_Tsunoda様

ありがとうございます。

おそらくですが、HKEY_USERSは、全ユーザーの HKEY_CURRENT_USER の値が集約されているだけなので、ちょっと趣旨が違うような・・・

（違ったらごめんなさい）

Answer 13

魔界の仮面弁士様

ご検証頂きありがとうございます。

エンドユーザーのうちの一人に確認したところ、ストアアプリ版を利用していました。

そして、デスクトップアプリ版に入れなおしてもらったところ、無事解決に至りました。

ご推察の通り、ストアアプリ版の「UWPパッケージ化」の影響のようです。

明日もしくは来週早々に、もう一人のエンドユーザーから報告があると思いますので、その解決（たぶんするはず＾＾；）をもって、本質問を締めれればと思っています。

まずはご報告まで。

Answer 14

UWP（ストアアプリ）の Office では、他の UWP デスクトップアプリ同様、HKCU の書き込みは AppData のファイルにリダイレクトされるので、レジストリエディタから普通には見えないはずですね。
参考： https://docs.microsoft.com/ja-jp/windows/msix/desktop/desktop-to-uwp-behind-the-scenes#registry

Office VBA とレジストリを共有するツール・アプリケーションを利用する場合は、UWP 版ではなく、C2R 版か MSI 版を使わないと難しいと思われます。
ユーザーサイドでそのことに自発的に気づくことは難しいので、そのツール・アプリケーションの FAQ を整備するぐらいですね…。

Answer 15

> セキュリティソフト以外でインジェクションを行うようなソフトの存在は、
> 顧客層的に考えづらい（しかも別々の顧客で同時期に発生）ので、
> 可能性は低いかもしれません。

Injection を行うのがセキュリティ ソフトだけどは限りません。
Intel が提供しているサービス系の多くは、Office 関連プロセスにも Injection をかけますし、Intel 以外の 3rd ベンダー製サービスの多くが、Office 関連プロセスに Injection をかけます。

Answer 16

Azulean様

ありがとうございます。

どうやら、UWPアプリ（＝ストア版）は個別のサンドボックス内で実行されるようですね。

もう一人のエンドユーザーからは、まだ報告がありませんが、ストア版であったことが原因と結論付けてよさそうです。

ストア版＝メトロスタイルアプリ＝モバイル向けアプリ＝簡易版　という認識だったため、まさかエンドユーザーがストア版を使っているとは思いもしませんでした。

いつのまにか時代に取り残されていたようです-o-;

ストア版は、エクセルの実行ファイルのパスが変わっている（＝Windows￥Apps配下）そうなので、そのことを検証し、処理を切り分けできるように改良していこうと思っています。

参考にしたURL↓

https://www.buildinsider.net/enterprise/uwpapp/01

Answer 17

お馬鹿様

引き続きの回答ありがとうございました。

今回の事象は、「ストア版であること」と結論付けましたが、将来的に、インジェクションが原因となり問題が生じる可能性もあるかもしれませんので、頭の片隅に留めておこうと思います。