Windowsアプリ互換の仕組み ── 互換モード・シム・Compatibility Administratorで古いアプリを延命する

「ソースコードが残っていない10年前の業務アプリが、新しいWindows 11のPCで起動しない。プロパティの互換性タブで『Windows XP』にチェックを入れたら、あっさり動いた。──これは一体何をしているのか。この状態に頼って使い続けていいのか」。お客様からよくいただく相談です。

チェック1つで動いてしまうと、かえって不安になるものです。魔法のように見える互換モードの正体は、シム(Shim)と呼ばれる、アプリとWindows APIの間に割り込んで「嘘」を返す小さなコード群です。Windowsは何世代も前のアプリを動かし続けるために、この応急処置の仕組みをOS自身が大規模に使っており、ユーザーや管理者にもその一部が開放されています。

仕組みを知らないまま使うと、「なぜ動いているのか分からないから触れない」という不安定な延命になります。逆に仕組みを理解すれば、どこまでは安心して頼れるのか、何が起きたら壊れるのか、いつ作り直すべきかを根拠を持って判断できるようになります。

この記事では、中小企業の情シス担当者と、古い業務アプリを預かるWindowsアプリ開発者を対象に、互換モードの正体であるシムの仕組み、代表的なシムでできること、Compatibility Administratorを使った組織的な適用、そしてシムでは救えない限界と「延命か移行か」の判断までを、Microsoft Learnの一次情報にもとづいて整理します。

1. まず結論

• 互換モードの正体はシム(互換レイヤー)です。互換性タブの設定は HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers に書き込まれ、起動時にそのプロセスへシムの束が適用されます。¹²
• シムはインポートテーブル(IAT)の差し替えによるユーザーモードのAPIフックです。アプリがWindows APIを呼ぶ経路に割り込み、古いWindowsと同じ答えを返します。OS本体を変えているわけではありません。³
• シムでできることは、アプリのコード修正でできることと同じ範囲です。セキュリティ機構の回避はできず、カーネルモード(デバイスドライバー)の問題も直せません。³
• バージョン詐称・ファイルパスの付け替え・レジストリの偽装・管理者チェックの偽装など、Microsoftが用意した既製のシムが多数あります。Compatibility Administratorから個別のEXEに適用できます。⁴
• Windows自身も既定でシムを使っています。起動のたびにOS標準の互換データベース(.sdb)が照合されるほか、PCA(Program Compatibility Assistant)が問題を検出して自動で互換設定を当てることもあります。¹⁵
• 「昔のWindowsだと答える」動作は、今や既定です。Windows 8.1以降、GetVersionExはマニフェストで宣言していないOSバージョンを返しません。互換モードはこの仕組みの延長にあります。⁶⁷
• 16bitアプリ・カーネルドライバー依存・ハードウェア直接アクセスにはシムは効きません。特に64bit Windowsでは16bitアプリはそもそも実行できません。⁸
• 「管理者を要求するが実際は不要」なアプリにはRunAsInvokerが定番です。__COMPAT_LAYER=RunAsInvokerで昇格要求を抑止し、一般権限で動かせます。⁹
• シムで動く=当面延命できる、ですが本筋は「シム無しで動く形に直す」ことです。延命と決めたなら、何のシムで動いているかを記録し、作り直しの判断材料として管理します。

2. アプリケーション互換性の全体像 ── Windowsが持つ後方互換の層

シムの話に入る前に、Windowsが古いアプリのために持っている仕組みを一覧しておきます。「互換モードで動いた」と一口に言っても、実際にアプリを救っているのはこのうちのどれか1つ、あるいは複数の組み合わせです。

UAC仮想化は、マニフェストを持たない32bit対話型プロセスに対して働く経過措置で、Microsoft自身が「将来のWindowsから削除する意向の暫定技術」と明言しています。¹⁰ Wow6432NodeへのリダイレクトやVirtualStoreの実害と対処は「レジストリの32bit/64bitリダイレクトと仮想化の落とし穴」で詳しく扱っているので、本記事ではシムを中心に据え、他の層は必要な範囲でだけ触れます。

DPI仮想化も补足しておくと、DPI対応を宣言していないアプリは96 DPI(100%)で描画しているものとして扱われ、Windowsがビットマップを引き伸ばして表示します。高DPIモニターで古いアプリが「ぼやける」のはこのためで、互換性タブの「高DPI設定の上書き」はこの仮想化の挙動を切り替えるスイッチです。¹¹

3. シム(Shim)の正体 ── IAT差し替えでAPIの間に割り込む

3.1. アプリとOSの間に立つ「通訳」

Windowsの実行ファイル(PEフォーマット)は、外部DLLのAPIをインポートアドレステーブル(IAT)経由で呼び出します。アプリがGetVersionExを呼ぶとき、実際にはIATに書かれたアドレスへ飛んでいるだけです。シムの仕組みはここを突きます。アプリのロード時に、対象APIのIATエントリをシムコードのアドレスへ書き換え、アプリとWindowsの間に割り込むのです。動的にGetProcAddressで取得されるAPIも、GetProcAddress自体をフックすることで対応します。³

割り込んだシムは、たとえば「今のOSバージョンは?」という問い合わせに古いバージョン番号を返したり、書き込めない場所へのファイルアクセスを別の場所へ付け替えたりしてから、必要に応じて本物のAPIを呼びます。アプリから見れば「昔のWindowsで動いている」ように見え、OSから見れば「行儀のよいアプリが動いている」ように見える──シムは両者の間の通訳です。

この設計から、重要な性質が3つ導かれます。³

1. シムはアプリ側のコードとして動く。OSの一部ではないため、アプリと同じセキュリティ制約を受けます。シムでOSのセキュリティ機構を回避することはできず、シムを使うためにセキュリティ設定を緩める必要もありません。
2. シムで直せることは、アプリのコード修正でも直せる。シムは「ソースがない・直せない」場合の代替手段であって、コード修正より強力なわけではありません。
3. ユーザーモード限定。カーネルモードで動くデバイスドライバーの互換問題はシムでは直せません。

3.2. シムデータベース(.sdb)とマッチング

「どのEXEにどのシムを当てるか」の対応表がシムデータベースで、拡張子.sdbのバイナリファイルです。データベースには対象アプリの実行ファイルが、ファイル名・サイズ・チェックサム・バージョンといった属性(マッチング属性)で登録されており、プロセス起動時に照合されます。解決策には、APIフックを注入するAppfix(シム)のほか、「このアプリには互換性の問題があります」というメッセージを表示するApphelpもあります。複数のシムとフラグを束ねたものが互換レイヤー(互換モード)です。¹

見落とされがちですが、この照合は互換モードを設定したアプリだけでなく、すべてのプロセス起動で行われています。Windowsには何千という既知アプリの修正を収めたOS標準のデータベース(実体は%WINDIR%\AppPatch配下)が同梱されており、あなたのPCでも今日、どこかの古いアプリが気づかないうちにシム付きで起動しているはずです。Microsoft提供の互換修正はWindowsの一部として出荷され、Windows Updateで更新されます。³

3.3. PCA ── 自動でシムを当ててくる仕組み

もう1つ、管理者が意図しなくてもシムが適用される経路がPCA(Program Compatibility Assistant)です。PCAはアプリの実行を監視し、既知の互換性問題の兆候を検出すると、修正の適用をユーザーに提案したり、一部のケースでは自動で互換設定を適用したりします。たとえば、解放済みDLL内のコードを呼んでクラッシュするアプリにはPINDLL、保護されたWindowsファイルへの書き込みに失敗するアプリにはWRPMITIGATIONのような互換モードが割り当てられます。⁵

「何も設定していないのに、いつの間にか互換モードのチェックが入っていた」の正体は、多くの場合これです。故障でも誤操作でもなく、Windowsの設計どおりの動作です。

4. 代表的なシムで何ができるか

Microsoftが公開している既製シムから、業務アプリの延命で実際によく使うものを抜粋します。⁴

眺めると分かるとおり、シムの大半は「古いアプリが期待している答えを返す嘘」です。ディスクは2GBまで、OSはXP、あなたは管理者──アプリが生まれた時代の世界観を、そのプロセスの中にだけ再現しています。

バージョン詐称は「公式の既定動作」になった

バージョン詐称は特別なハックではありません。Windows 8.1以降、GetVersionExが返す値はアプリのマニフェスト次第になりました。マニフェストの<compatibility>セクションに<supportedOS>の宣言が無いアプリには、実際のOSが何であれWindows 8相当(6.2)が返ります。宣言がある場合は、宣言したうち最も高いOSまでの値が返ります(例: Windows 8.1のGUIDまで宣言していれば、Windows 11上でも6.3)。⁶⁷

つまり「アプリが見るWindowsバージョン」は、次の多段で決まります。

1. マニフェストで宣言したOSまでの値が返る(宣言なしなら6.2)
2. 互換モード(VersionLie系シム)が適用されていれば、選択したOSのバージョンが返る⁶

自社開発アプリで「OSバージョンを見て分岐しているのに、Windows 11なのに8と判定される」と混乱したら、まずマニフェストのsupportedOS宣言を疑ってください。逆に言えば、バージョンチェックで起動を拒否する古いアプリは、シムのVersionLieで高確率で突破できます。バージョン番号を見ているだけで、実際の動作は新しいOSでも問題ないことが多いからです。

5. 互換モードのチェックボックスは何をするか

プロパティ→互換性タブの設定は、レジストリのAppCompatFlags\Layersキーに保存されます。DXGIのアプリ互換設定なども同じキーを使う、互換レイヤー指定の置き場所です。² 実際に確認してみます。

reg query "HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers"

互換性タブで「Windows XP (Service Pack 3)」「管理者としてこのプログラムを実行する」「高DPI設定の上書き」を設定したEXEなら、たとえば次のような値が見えます。

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers
    C:\LegacyApp\Gyomu.exe    REG_SZ    ~ WINXPSP3 RUNASADMIN HIGHDPIAWARE

チェック項目と値の対応の代表例です(Windows 11で確認した例で、OSバージョンにより項目名・値は変わり得ます)。

押さえておきたいポイントは3つです。

• 「管理者としてこのプログラムを実行する」も同じ場所に書かれます。互換モードと昇格指定は同じLayersキーに同居しており、「互換モードを設定したら昇格まで付いてきた/消えた」という混乱はここから生まれます。値を直接見れば切り分けられます。
• HKCUに書かれるのは「そのユーザーの設定」です。タブの「すべてのユーザーの設定を変更」から設定した場合は、HKLM側の同名キーに書かれ、全ユーザーに効きます。キッティングで配る場合はどちらに書いているかを意識してください。
• チェックボックスは既製レイヤーの入口にすぎません。タブから選べるのは代表的なレイヤーだけで、個別のシムを選んで組み合わせることはできません。それをやるのが次章のCompatibility Administratorです。

6. Compatibility Administratorの実務 ── カスタム.sdbを作って配る

6.1. 入手と注意点

Compatibility AdministratorはWindows ADK(Windows Assessment and Deployment Kit)に含まれるツールです。¹² インストールすると32bit版と64bit版の両方が入り、32bitアプリの修正には32bit版を、64bitアプリには64bit版を使う必要があります。¹³

もう1つ重要な注意があります。Compatibility Administratorを管理者権限(昇格状態)で起動してテストすると、UAC仮想化やリダイレクトが本来のように働かず、「直った」と誤判定することがあります。修正の効果は、必ず実際の利用者と同じアカウント・権限で確認してください。⁴

6.2. カスタム互換データベースを作る手順

大まかな流れは次のとおりです。¹⁴

1. Compatibility Administrator左ペインの「Custom Databases」で新規データベースを作成し、「Create New」→「Application Fix」を選ぶ
2. アプリ名・ベンダー名を入力し、対象のEXEファイルを指定する
3. 適用する互換モード(レイヤー)を選ぶ ── まず「Windows XP互換」のような束で試すのが近道です
4. 必要なら個別の互換修正(シム)を追加で選ぶ ── VersionLieだけ、CorrectFilePathsだけ、といった最小構成に絞り込めます
5. マッチング条件(ファイルサイズ・チェックサム・バージョン等)を確認して保存する

マッチング条件は「このEXEにだけ効かせる」ための鍵です。既定の基本条件で通常は十分ですが、アプリのバージョンを特定できる条件を残すことをおすすめします。将来ベンダーが修正版を出したとき、新バージョンにまで古い嘘が適用され続ける事故を防げるからです。¹⁴¹⁵

作成した.sdbは、まず検証機でテストします。狙いどおり動いたら組織展開です。

6.3. sdbinstで配布する

カスタム.sdbを各PCに適用するコマンドがsdbinst.exeです(要管理者権限)。¹⁵

:: インストール(-q は確認なしのサイレント)
sdbinst -q "C:\Deploy\MyCorpFixes.sdb"

:: アンインストール(ファイル指定)
sdbinst -q -u "C:\Deploy\MyCorpFixes.sdb"

:: アンインストール(データベースGUID指定)
sdbinst -q -u -g {データベースのGUID}

組織展開の戦略としてMicrosoftは、アプリのインストーラーに個別の.sdbを同梱する方式よりも、会社として1つ(または部門ごと)のカスタムデータベースに集約して集中管理する方式を推奨しています。修正が増えるほど、多数の1行データベースを配るより1つのデータベースを更新して再配布するほうが管理しやすいからです。カスタムデータベースは固有のGUIDを持ち、同じGUIDの新バージョンをインストールすると旧バージョンは自動的に置き換えられるため、更新運用もシンプルです。配布自体は、MSIパッケージ化やスタートアップスクリプトなど、管理者権限で実行できる既存の配布経路に載せます。¹⁵

インストール済みのカスタムデータベースは「プログラムと機能(インストールされているアプリ)」に項目として登録されるので、棚卸しや削除はそこからも確認できます。どのPCに何の.sdbが入っているかは、資産管理台帳に載せておくべき情報です。

7. 効かないケースと限界

シムは万能ではありません。仕組み上、次のケースには効きません。

• カーネルモードの問題。シムはユーザーモードのプロセス内で動くため、デバイスドライバーの非互換は直せません。古い計測機器・USBドングル・プリンターのドライバーがWindows 11に対応していない場合、アプリ側に何を当てても解決しません。ウイルス対策ソフトの一部などカーネルで動くコードも同様です。³
• 16bitアプリ。64bit Windowsは16bitアプリの実行をサポートしていません。ハンドルが64bit Windowsでは32bitの有効ビットを持ち、16bitアプリに切り詰めて渡せないためで、起動はERROR_BAD_EXE_FORMATで失敗します。⁸ アプリ本体は32bitでも、インストーラーの起動部分(スタブ)が16bitという時代のパッケージがあり、この場合「アプリは動くのにインストールできない」という形で現れます。
• ハードウェアへの直接アクセス。I/Oポートや物理メモリを直接触る前提の産業用アプリは、そもそも現代のWindowsではユーザーモードから許可されておらず、シムで偽装できる範囲を超えています。
• セキュリティ機構の回避。シムはアプリと同じセキュリティ制約下で動くため、「権限がなくてできないこと」を可能にはできません。ForceAdminAccessやWRPMitigationは、チェックや書き込みの成功を偽装してアプリを先へ進めるだけで、実際に保護された資源を書き換えているわけではありません。³⁴
• 自己整合性チェックをするアプリ。古いコピープロテクトや改ざん検出を持つアプリは、API フックそのものを異常とみなして動かなくなることがあります。

そして、シムに共通する本質的な限界が「応急処置である」ことです。シムは特定のAPIの特定の使い方に合わせた嘘であり、OS側の実装が変われば前提が崩れます。Microsoft提供のシムはWindowsの一部としてWindows Updateで保守されますが³、カスタムデータベースで当てた嘘の面倒を見るのは自組織です。機能更新のたびに「シムで延命中のアプリ一覧」を検証する運用を、延命の費用として見込んでください。

8. RunAsInvokerの実務価値 ── 昇格要求だけを黙らせる

シムの中でも、情シスの日常業務でもっとも出番が多いのがRunAsInvokerです。

古い業務アプリには、マニフェストでrequireAdministratorを宣言していたり、EXE名や内容からインストーラーと誤検出されたりして、起動のたびにUAC昇格を要求するものがあります。ところがその多くは、XP時代の惰性で管理者を要求しているだけで、実際には管理者権限を使っていません。RunAsInvokerシムを当てると、インストーラー検出もマニフェストも上書きして、親プロセスから継承したトークン(=一般ユーザー権限)のままアプリが起動します。⁹

Compatibility Administratorで.sdbを作らなくても、環境変数__COMPAT_LAYERで同じレイヤーを一時的に適用できます。

:: このコマンドプロンプトから起動する子プロセスにRunAsInvokerを適用
set __COMPAT_LAYER=RunAsInvoker
start "" "C:\LegacyApp\Gyomu.exe"

# PowerShellの場合
$env:__COMPAT_LAYER = 'RunAsInvoker'
Start-Process 'C:\LegacyApp\Gyomu.exe'

この2行をバッチファイルにしてショートカット代わりに配れば、一般ユーザーにローカル管理者権限を配らずに済み、UACのパスワード入力で毎回情シスが呼ばれることもなくなります。最小権限の原則にも沿う、守りを固める方向の互換テクニックです。

注意点も明確にしておきます。

• 権限が増えるわけではありません。本当に管理者権限が必要な処理(HKLMへの書き込み、Program Files配下の更新など)は、アプリ内でエラーになるか、条件を満たせばUAC仮想化でVirtualStoreへ転送されます。¹⁰ 設定保存が「効かなくなった」ように見えたら仮想化を疑ってください。
• 環境変数方式は子プロセスにしか効きません。恒久適用したい場合は、互換性タブ(RUNASINVOKERはタブに項目がないためLayersキーへの直接設定)か、.sdbでの配布が確実です。
• 書き込み先の是正が本筋です。アプリを改修できるなら、設定ファイルを%APPDATA%配下へ移し、マニフェストでasInvokerを宣言するのが正しい姿です。⁹

9. 延命か移行かの判断 ── シムで動いたあとに考えること

シムで動いた瞬間は安堵しますが、そこで思考を止めないことが重要です。シムで動いた=Windowsが用意した受け皿にたまたま収まった、ということにすぎません。判断の軸を表にします。

延命と決めた場合は、次の3点をセットで運用に載せてください。

1. 記録する。どのEXEに、どのシム/レイヤーを、なぜ当てたか。Layersキーの値と.sdbのGUIDを台帳に残します。「なぜ動いているのか誰も知らない」状態が、次の担当者への最大の負債です。この考え方は「ソースコードも仕様書もないシステムを引き継いだら」で扱った保全の発想と同じです。
2. 検証する。Windowsの機能更新の検証項目に、シム延命中アプリの起動・主要操作を含めます。OS入れ替えの計画(Windows 10サポート終了後の現実解)とも連動させます。
3. 期限を切る。「次の基幹システム更改まで」「2028年3月まで」のように延命の終わりを決め、移行の検討を並走させます。

移行側の選択肢は、アプリの技術によって定石が変わります。VB6製なら「VB6アプリはいつまで動くのか」で整理した全面リライト・自動変換・段階移行の3択、ActiveX/OCXに依存しているなら「ActiveX / OCX を今どう扱うか」の残す・包む・置き換えるの判断表が使えます。シムは、こうした移行プロジェクトの検討・準備期間を安全に稼ぐための時間稼ぎ、と位置づけるのが健全です。

10. まとめ

• 互換モードの正体はシムです。互換性タブの設定はAppCompatFlags\Layersキーに書かれ、起動時にIAT差し替えによるAPIフックとしてプロセスに注入されます。
• シムは「古いアプリが期待する答えを返す嘘」の集まりです。バージョン詐称、パスの付け替え、レジストリの偽装、管理者チェックの偽装などの既製シムが用意されています。
• Windows自身が既定で大量のシムを使っており、PCAが自動適用することもあります。互換モードに頼ること自体は、OSの正式な仕組みに乗った妥当な選択です。
• ユーザーモード限定・セキュリティ回避不可という原理的な限界があり、カーネルドライバー・16bitアプリ・ハードウェア直接アクセスは救えません。
• 組織展開はCompatibility Administrator(Windows ADK)でカスタム.sdbを作り、sdbinstで配布します。32bit/64bit版の使い分け、実利用アカウントでのテスト、GUIDによる更新管理が実務の勘所です。
• 「管理者を要求するが実際は不要」なアプリは__COMPAT_LAYER=RunAsInvokerで一般権限化できます。権限を配るのではなく昇格要求を黙らせる、守りのテクニックです。
• シムで動くのは延命であって解決ではありません。何で動いているかを記録し、機能更新のたびに検証し、期限を切って移行を並走させる──この3点セットまで含めて「互換モードに頼る」判断です。

次に互換モードのチェックで古いアプリが動いたら、こう問い直してください。「このアプリは、どの嘘のおかげで動いているのか。その嘘はいつまで通用するか」。答えられるなら、延命は立派な戦略です。

関連記事

• レジストリの32bit/64bitリダイレクトと仮想化の落とし穴 ── Wow6432Nodeと「書いたはずの値がない」問題
• VB6アプリはいつまで動くのか ── ランタイムのサポート状況と現実的な.NET移行の進め方
• ActiveX / OCX を今どう扱うか - 残す・包む・置き換える判断表
• Windows 10サポート終了後の現実解 ── ESU・LTSC・買い替えの判断表
• ソースコードも仕様書もないシステムを引き継いだら ── 止めずに運用・保守するための実務手順
• Windowsシェル統合の今 ── 右クリックメニュー・ファイル関連付け・Windows 11の変化

関連する相談領域

合同会社小村ソフトでは、ソースコードのない古い業務アプリの動作調査と延命設計(シム・互換モードの選定、カスタム.sdbの作成と展開)、Windows 11移行にともなう既存アプリの互換性検証、そして延命と並走する作り直し・移行の計画づくりを扱っています。「互換モードで動いてしまったが、このままでいいのか」という段階からの相談で構いません。

• 既存資産活用・移行支援
• Windowsアプリ開発
• 技術相談・設計レビュー
• お問い合わせ

参考リンク

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

互換モードにチェックを入れたら動いたアプリは、そのまま使い続けていいですか？

当面の業務継続という意味では使い続けて問題ありません。互換モードの実体はシムと呼ばれるユーザーモードのAPIフックで、OSの設定として正式に用意された仕組みだからです。ただし、シムはあくまでアプリを直さずに動かすための応急処置であり、OSの更新で前提が変わればまた動かなくなる可能性があります。互換モードで動いている事実は台帳に記録し、そのアプリを作り直すか、計画的に延命するかの判断とセットで運用してください。

互換モードのチェックボックスは、具体的に何をしているのですか？

プロパティの互換性タブで設定を保存すると、HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers キーに、対象EXEのパスと「WINXPSP3」「HIGHDPIAWARE」のような値が書き込まれます。次にそのEXEを起動するとき、Windowsのローダーがこの値を読み、対応する互換レイヤー(シムの束)をプロセスに適用します。たとえばWindows XP互換モードなら、OSバージョンを問い合わせるAPIに古い値を返すバージョン詐称などが働きます。OS本体の動作を変えているのではなく、そのプロセスにだけ「昔のWindowsのふり」をして見せる仕組みです。

16bit時代の古いアプリは64bit Windowsの互換モードで動かせますか？

動かせません。64bit WindowsはWOW64という仕組みで32bitアプリを実行しますが、16bitアプリの実行はサポートしておらず、起動しようとするとERROR_BAD_EXE_FORMATで失敗します。これはシムでは回避できないアーキテクチャ上の制限です。インストーラーの起動部分だけが16bitという古いパッケージも同じ理由で失敗します。どうしても必要な場合は、32bit版Windowsを含む仮想マシンなど、互換モード以外の手段を検討することになります。

「管理者として実行しないと起動しない」アプリを、一般ユーザー権限のまま動かせますか？

試す価値があるのがRunAsInvokerです。コマンドプロンプトで set __COMPAT_LAYER=RunAsInvoker を実行してからアプリを起動すると、マニフェストのrequireAdministrator指定やインストーラー検出による昇格要求が抑止され、呼び出し元と同じ(一般ユーザーの)権限で起動します。管理者権限を「要求するだけで実際には使っていない」アプリなら、これだけで日常運用から昇格を排除できます。ただし権限が増えるわけではないので、本当に管理者権限が必要な処理はそのアプリ内で失敗します。動作確認のうえで採用してください。

Compatibility Administratorはどこで入手できますか？

Windows ADK(Windows Assessment and Deployment Kit)に含まれています。MicrosoftのサイトからADKをダウンロードし、インストール時にApplication Compatibility Tools系の機能を選択すると使えるようになります。32bit版と64bit版の両方がインストールされ、32bitアプリの修正には32bit版を、64bitアプリには64bit版を使う必要がある点に注意してください。作成したカスタム互換データベース(.sdb)は、各PCでsdbinstコマンドを実行して適用します。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。