Windows 11 のアップデート直後から「スタートボタンが反応しない」「Teams/Outlook/Windows セキュリティ等の UWP アプリが即落ちする」「Intune の接続が切れる」といった複合不具合が、主に Lenovo Legion／ThinkPad 系で報告されています。本記事はその原因を技術的に解説し、最短で復旧・再発防止できる実運用レベルの対処（PowerShell／Intune リメディエーション）を、コピペで使える形で提供します。
Windows 11 でスタートボタンが反応しない／UWP アプリが即時クラッシュする問題の全体像
以下の 3 つが同時または連鎖的に発生します。特に Windows 11 Enterprise 24H2（ビルド 26100 系）で、Microsoft Update の適用直後から顕著です。
- スタートボタンや Windows キーを押してもメニューが開かない（Start Menu / Search / Widgets 等が沈黙）。
- Windows Security・Microsoft Teams・Outlook・Company Portal などの UWP 系アプリがスプラッシュ直後に落ちる。
- Intune（Entra ID MDM）との接続が切れ、再サインインやライセンス再認証が求められる（MDM トークン更新失敗）。
PC をクリーンインストールしても、Microsoft Update を適用すると再発し、Lenovo Legion／ThinkPad での発生率が高いのが特徴です。
再発条件（実地観測）
| 条件 | 内容 |
|---|---|
| OS とビルド | Windows 11 Enterprise 24H2（ビルド 26100 系）で顕著。 |
| 適用タイミング | OS セットアップ直後は正常でも、Microsoft Update 適用直後から再発。 |
| 機種傾向 | Lenovo Legion／ThinkPad 系ノート PC で多発（他社機でも条件が合えば発生）。 |
| 管理形態 | Intune 管理下で影響が表面化しやすい（MDM 更新が失敗）。 |
原因（判明済み）：レジストリ ACL から「ALL APPLICATION PACKAGES」の ReadKey が消える
Lenovo Vantage／Lenovo System Interface Foundation（以下 LSIF）の旧バージョンが、レジストリ キー HKLM\SYSTEM\CurrentControlSet\Control のアクセス制御（ACL）から ALL APPLICATION PACKAGES の ReadKey 権限を誤って削除することが根本原因です。
この権限は UWP アプリと Windows シェル コンポーネント（Start Menu、Search、通知、Windows セキュリティ等）が OS の重要キーへ読み取りアクセスするために必須です。権限が消えると、UWP は初期化時に例外で即時終了し、シェル機構が動かずスタートメニューが開かなくなります。また、MDM クライアント（デバイス管理サービス）もトークン更新時に必要な情報へ到達できず、Intune 接続が失われます。副作用として explorer.exe の断続的クラッシュも発生しえます。
Lenovo は 2025-09-05 付けで本件を修正した Vantage／ドライバーパッケージをリリースしており、最新版へ更新すれば再発を抑止できます。ただし、既に壊れた ACL は自動では戻らないため、まず ACL を修復する必要があります。
最短で復旧する手順（確認済みの有効策）
下表の順で対応すると、スタートメニュー無反応・UWP 即落ち・Intune 切断の 3 つを一気に解消できます。
| 手順 | 内容 |
|---|---|
| 1 | レジストリ ACL を修復 管理者権限の PowerShell で次のスクリプトを実行します（コピペ可）。 |
| 2 | PC を再起動し、スタートメニューや UWP アプリが起動することを確認します。 |
| 3 | Lenovo Vantage／System Interface Foundation を最新版（v3.6.92 以降）へ更新して再発を防止します。 |
| 4 | 企業環境では Intune リメディエーション スクリプトとして配布し、一括修復・監視を行います。 |
PowerShell：ACL 修復スクリプト（管理者で実行）
powershell
$p = 'HKLM:\SYSTEM\CurrentControlSet\Control'
$acl = Get-Acl $p
$rule = New-Object System.Security.AccessControl.RegistryAccessRule(
'ALL APPLICATION PACKAGES',
'ReadKey',
'ContainerInherit,ObjectInherit',
'None',
'Allow'
)
$acl.SetAccessRule($rule)
Set-Acl $p $acl
ポイント
- ACL 修復は 1 回で十分です。権限が再び壊れない限り持続します。
- もし再発するなら、旧版 Vantage/LSIF の DLL やサービスが再度 ACL を上書きしています。必ず最新版へ更新してください。
- Intune 自体が原因ではありません。Lenovo ソフトが変更した ACLが UWP/MDM を妨げていました。
なぜこの ACL が重要なのか（技術解説）
- ALL APPLICATION PACKAGES は UWP/ストア アプリおよび一部のシェル機能が属する SID（S-1-15-2-1）で、システムの標準キーへの読み取りが必要です。
HKLM\SYSTEM\CurrentControlSet\Controlは OS 全体の初期化・構成に関わる「親」キーであり、ここに ReadKey が無いと多くのコンポーネントが設定を列挙できません。- MDM（Intune）のトークン更新も内部でレジストリ問い合わせを行うため、権限欠落は MDM 断（要再認証）に直結します。
発生確認と切り分け：まず ACL を見る
GUI（regedit）での確認
regedit.exeを管理者で開く。HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Controlを右クリック →「アクセス許可」。- エントリに「ALL APPLICATION PACKAGES」が存在し、読み取り（ReadKey）が許可になっているか確認。
PowerShell での確認（スクリプト化向け）
powershell
$path = 'HKLM:\SYSTEM\CurrentControlSet\Control'
$acl = Get-Acl $path
$allAppPkgSid = New-Object System.Security.Principal.SecurityIdentifier('S-1-15-2-1')
$allAppPkg = $allAppPkgSid.Translate([System.Security.Principal.NTAccount])
$hasRead = $false
foreach($ar in $acl.Access){
if($ar.IdentityReference -eq $allAppPkg -and
($ar.RegistryRights -band [System.Security.AccessControl.RegistryRights]::ReadKey) -and
$ar.AccessControlType -eq 'Allow'){
$hasRead = $true; break
}
}
'ALL APPLICATION PACKAGES ReadKey: ' + ($hasRead ? 'OK' : 'NG')
ここが NG なら、本記事の修復スクリプトで復旧できます。
Intune での一括自動修復（リメディエーション）
エンドポイント数が多い組織では、Intune の「デバイス リメディエーション」を用いて、検出（Detection）と修復（Remediation）を定期実行すると安全です。以下はそのまま使えるサンプルです。
Detection スクリプト（準拠なら 0、非準拠なら 1 を返す）
powershell
$path = 'HKLM:\SYSTEM\CurrentControlSet\Control'
try{
$acl = Get-Acl $path
$sid = New-Object System.Security.Principal.SecurityIdentifier('S-1-15-2-1')
$acct = $sid.Translate([System.Security.Principal.NTAccount])
$ok = $false
foreach($ar in $acl.Access){
if($ar.IdentityReference -eq $acct -and
($ar.RegistryRights -band [System.Security.AccessControl.RegistryRights]::ReadKey) -and
$ar.AccessControlType -eq 'Allow'){
$ok = $true; break
}
}
if($ok){ Write-Output 'Compliant'; exit 0 } else { Write-Output 'NonCompliant'; exit 1 }
}catch{
Write-Output "Error: $($_.Exception.Message)"; exit 1
}
Remediation スクリプト（権限を付与し復旧）
powershell
$path = 'HKLM:\SYSTEM\CurrentControlSet\Control'
try{
$acl = Get-Acl $path
$rule = New-Object System.Security.AccessControl.RegistryAccessRule(
'ALL APPLICATION PACKAGES','ReadKey','ContainerInherit,ObjectInherit','None','Allow'
)
$acl.SetAccessRule($rule)
Set-Acl $path $acl
Write-Output 'Remediated'
exit 0
}catch{
Write-Output "Remediation failed: $($_.Exception.Message)"
exit 1
}
推奨ポリシー設定
- スケジュールは 1～4 時間間隔程度（短期監視）→ 安定後は 1 日 1 回へ。
- 修復後に再起動を促すトースト通知（エンドユーザー通知）を併用。
- 検出と修復は「全社」ではなく、まずパイロット グループ（Lenovo 機種 OU / Azure AD グループ）で段階展開。
Lenovo ソフトの更新（再発防止）
ACL を戻すだけでは再発の恐れが残ります。以下の順で Lenovo 関連コンポーネントを更新してください。
- Lenovo Vantage（Microsoft Store の「ライブラリ」から更新、または企業配布パッケージ）。
- Lenovo System Interface Foundation（LSIF） と関連ドライバー。デバイス マネージャーや企業内配布ソースから最新に。
- ImControllerService 等の Lenovo サービスは最新版に置換（旧版が残ると ACL を再度上書きする場合あり）。
Vantage／LSIF は v3.6.92 以降が安全策としての目安です。更新後にもう一度 Detection スクリプトで準拠を確認し、再発が止まっているかを監視しましょう。
効果のなかった／限定的だった対処とその理由
- SFC /scannow・DISM /RestoreHealth：システム ファイル整合性の検査であり、レジストリ ACL の論理権限欠落は修復対象外。
- AppX の再登録（
Get-AppxPackage再配備）：アプリ コンテナの登録を再作成しても、親キーの ReadKey 欠落は解消されないため再発。 - ユーザー プロファイル作り直し：問題は HKLM 配下＝マシン全体の ACL のため効果なし。
- OS 再イメージ／初期化：初期状態では直るが、Update 後に旧版 Lenovo ソフトが入ると再度 ACL が壊れて再発。
- 更新プログラムの一時停止・ロールバック：発生を遅らせるだけで根本の権限欠落は残存。
- Intune から端末を外す：MDM の症状は止まるが、管理要件に反し、UWP/シェル自体の不調は継続する場合あり。
運用者向けチェックリスト（現場でそのまま使える）
| 項目 | 実施内容 | 合格ライン |
|---|---|---|
| ACL 確認 | regedit または PowerShell で HKLM\SYSTEM\CurrentControlSet\Control の権限を確認。 | ALL APPLICATION PACKAGES に ReadKey（許可）がある。 |
| 一時復旧 | 本記事の ACL 修復スクリプトを管理者で実行、再起動。 | Start/Menu が開き、UWP 起動、Intune 状態「準拠」。 |
| 再発防止 | Vantage/LSIF を v3.6.92 以降へ更新。旧版サービスを残さない。 | Detection が 0 を返し続ける。 |
| 監視 | Intune リメディエーション（検出/修復）を配布、スケジュール実行。 | 非準拠＝自動修復/アラート。 |
| ログ確認 | イベント ビューアの AppModel-Runtime、AppXDeployment-Server、Shell-Core、DMClient（DeviceManagement-Enterprise-Diagnostics-Provider）を確認。 | UWP 初期化失敗や MDM トークン更新失敗が解消。 |
トラブルシュートの深掘り（再発・未解決時）
1. まだ Start/Menu が開かない場合
- ACL 修復後の再起動を実施しているか確認（サインアウトでは不十分なことがある）。
- 第三者製スタートメニュー置換ツールやハードニング（WDAC/AppLocker）が介在していないか。
- 追加で壊れたキーがないか：
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policiesなどに不正な Deny が入っていないか確認。
2. Vantage/LSIF 更新後に再汚染する場合
- 旧版サービス（例：
ImControllerServiceの旧ビルド）が残存し、起動時スクリプトで ACL を再適用している可能性。 - サービス停止→アンインストール→再起動→最新版のクリーンインストールを推奨。
- スタートアップ項目やタスク スケジューラに「権限を操作する」処理が残っていないか監査。
3. Intune が「アカウント修復を求める」から戻らない場合
- MDM クライアント（DmClient）のスケジュール実行まで数分～十数分かかることがあります。
dsregcmd /statusで AzureAdJoined と MdMUrl を確認。 - 会社ポータル（UWP）の即落ちが止まっているか先に確認し、設定 > アカウント > アクセスの職場または学校 から同期を実行。
セキュリティ観点の注意
- 本記事のスクリプトは ReadKey（読み取り）のみを付与します。不要な FullControl などは付けないでください。
- テナント全体での一括配布時は、まずはパイロットで権限が期待通りに入るかを確認します。
- 監査ポリシーでレジストリ キーの権限変更をログ化しておくと、再発時の原因追跡が容易になります。
よくある質問（FAQ）
Q. 他社 PC でも起きますか？
A. 条件さえ整えば起こりえます。まずは HKLM\SYSTEM\CurrentControlSet\Control の ACL を確認してください。ここが壊れていれば機種に関係なく UWP/シェルが停止します。
Q. ドメイン参加（オンプレ AD）に切り替えれば直りますか？
A. いいえ。ACL が壊れている限り、ドメイン参加・ローカル運用でも症状は継続します。最優先は ACL の修復です。
Q. レジストリ ACL を触るのが怖いのですが……
A. 本記事の付与権限は読み取り限定で、最小限の操作です。とはいえ、必ず管理者で実行し、実施前にシステムの復元ポイントやバックアップを推奨します。
Q. Vantage のバージョン確認方法は？
A. Microsoft Store 版の場合は「設定 > アプリ > インストール済みアプリ」や、PowerShell の Get-AppxPackage 'E046963F.LenovoCompanion' -AllUsers | Select Name,Version で確認できます。企業配布版は配布元のパッケージ情報を参照してください。
まとめ：まず ACL、次に Vantage/LSIF の更新。Intune で監視・自動修復。
スタートメニュー無反応・UWP 即落ち・Intune 切断という一見バラバラな症状は、実際には HKLM\SYSTEM\CurrentControlSet\Control の ACL で ALL APPLICATION PACKAGES の ReadKey が消えるという 1 点に収束します。ACL を PowerShell で復旧 → 再起動 → Vantage/LSIF を最新版へ更新――この 3 ステップで根本から解消し、Intune のリメディエーションで継続監視すれば、再発も抑止できます。
付録：現場配布用の「一括メモ」
- 現象：Start/Menu 開かない、UWP 即落ち、Intune 切断、explorer.exe が時々落ちる。
- 原因：
HKLM\SYSTEM\CurrentControlSet\Controlの ACL から「ALL APPLICATION PACKAGES: ReadKey」が消失（主因：旧版 Lenovo Vantage/LSIF）。 - 即効策：管理者 PowerShell で ACL 修復 → 再起動。
- 再発防止：Vantage/LSIF を v3.6.92 以降へ。旧版サービスを残さない。
- 企業対応：Intune リメディエーション（Detection/Remediation）で常時監視＋自動修復。
コメント