Setup aborts at Phase 5/11 (Full) because SearchHighlightOff cannot write the protected SearchSettings key on Windows build 28000
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 1/5
- 見積もり時間
- 1時間未満
- 初心者へのやさしさ
- 91/100
- issue の種類
- バグ
- 明瞭さ
- 明確に書かれている
- 活発さ
- 活発
- 技術スタック
- powershell
調査の方向性
steps/registry-taskbar-search.ps1 から始め、保護された Windows 設定をすでに処理している隣接する WidgetServiceOff ステップと SearchHighlightOff を比較します。Windows 11 build 28000 で Full setup アクションを実行するか、リポジトリに用意されている場合は対象を絞ったリグレッションテストを追加します。この保護されたレジストリ値によってセットアップが中断されなくなり、後続のフェーズが継続すれば完了です。
索引モデルが issue の本文から書いたものです。
説明
Summary
On Windows 11 build 28000, the Full action aborts at Phase 5/11 because the SearchHighlightOff tweak cannot write HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\SearchSettings\IsDynamicSearchBoxEnabled. Windows blocks value writes to that key at the kernel level, even for an elevated administrator.
Because the SearchHighlightOff step is not marked BestEffort (unlike the adjacent WidgetServiceOff step), this single un-writable cosmetic setting terminates the entire run, so Phases 6–11 (Edge, fonts, Terminal, PowerShell profile, Copilot, WSL) never execute.
Environment
| Item | Value |
|---|---|
| Windows | Windows 11, build 28000 (Microsoft Windows NT 10.0.28000.0) |
| PowerShell | 7.6.6 (Core) |
| winget | v1.29.380 |
| Setup entry point | irm https://aka.ms/devconfig/full/setup.ps1 | iex |
| Resolved commit | 06200f0819136c528e09533e3c8afac7e5f46ed7 (branch main) |
| Action | Full |
| Elevation | Yes — verified IsInRole(Administrator) = True for the running process |
Steps to reproduce
- On Windows 11 build 28000, run
irm https://aka.ms/devconfig/full/setup.ps1 | iexfrom an elevated PowerShell 7 session. - Let setup complete Phases 1–4 and the first four steps of Phase 5.
Actual result
Phase 5/11 -- Taskbar, search & start tweaks
...
-> Disable Show search highlights...
Calm OS setup stopped early.
Windows blocked changing HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\SearchSettings\IsDynamicSearchBoxEnabled. Administrator access or Windows policy may restrict this setting.
(_registry.ps1 line 50)
Nothing already applied was undone -- running this again picks up where it left off.
The underlying exception is an UnauthorizedAccessException ("Attempted to perform an unauthorized operation./ 未经授权操作") raised by New-ItemProperty at steps/_registry.ps1:48, caught and rethrown with the friendly message at steps/_registry.ps1:50-52.
Re-running simply reproduces the identical failure, so Full can never advance past Phase 5 on this build.
Root cause
Windows on this build protects the SearchSettings key against value writes, independent of ACLs. The key is owned by the user and its ACL grants the user, SYSTEM and Administrators KEY_ALL_ACCESS (KA), with no Deny ACE — yet every value write is refused.
Note the key carries an explicit ACE for a MicrosoftWindows.Client.CBS AppContainer SID (S-1-15-3-1024-1086922356-207614091-3724853071-841836187-4018695103-34218837-3164163255-155871754), which is the search/taskbar package (SearchHost.exe runs from MicrosoftWindows.Client.CBS_cw5n1h2txyewy).
Methods attempted, all failing
| Method | Result |
|---|---|
New-ItemProperty (PowerShell, elevated) |
Access is denied |
reg.exe add HKCU\...\SearchSettings /v IsDynamicSearchBoxEnabled /t REG_DWORD /d 0 /f |
ERROR: Access is denied. |
[Microsoft.Win32.RegistryKey]::SetValue() via OpenSubKey($true) |
Attempted to perform an unauthorized operation. |
Rewrote the key ACL (removed the AppContainer ACE, granted the current user explicit FullControl) |
ACL change succeeded, write still failed |
Stopped WSearch service and killed SearchHost.exe |
write still failed |
| Wrote a different, brand-new value name in the same key | failed |
Modified an existing value (WebSearchInstalledVersion) |
failed |
| Created a new subkey | succeeded (so it is specifically value writes that are blocked) |
Wrote HKLM\SOFTWARE\Policies\Microsoft\Windows\Windows Search |
succeeded (proves elevation is fine) |
Wrote HKCU\...\Explorer\Advanced |
succeeded (proves general HKCU writes are fine) |
SearchSettings has no policy mirror on this build (HKLM\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\SearchSettings does not exist), so there is no supported policy-based way to set this value either.
Expected result
Either of:
SearchHighlightOffshould be markedBestEffort = $true, like theWidgetServiceOffstep in the very same file, so a platform-protected cosmetic setting cannot abort the whole run; or- If the value is genuinely un-writable on current builds, the step should be removed or its apply-path changed to a supported API.
Suggested fix
In windows-dev-config/steps/registry-taskbar-search.ps1, the file already acknowledges this exact class of problem for Widgets:
# Windows may protect the Widgets policy even from an administrator.
@{
Name = 'WidgetServiceOff'
KeyPath = 'HKLM\SOFTWARE\Policies\Microsoft\Dsh'
ValueName = 'AllowNewsAndInterests'
Value = 0
Description = 'Disable Widgets'
BestEffort = $true
}
The SearchHighlightOff tweak immediately above it has the same exposure but lacks the flag:
@{
Name = 'SearchHighlightOff'
KeyPath = 'HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\SearchSettings'
ValueName = 'IsDynamicSearchBoxEnabled'
Value = 0
Description = 'Disable Show search highlights'
}
Adding BestEffort = $true (or removing the tweak) would let Full continue on builds where Windows protects this key.
Additional notes
- Verified against the current
main:steps/registry-taskbar-search.ps1is byte-identical to the copy setup installed, so the issue is present in the latest code. - Related prior report: #109 ("Disable Widget service errors on fresh Windows 11 PC") — the same class of failure, which is presumably why
WidgetServiceOffwas givenBestEffort.SearchHighlightOffappears to have been missed. - No existing issue appears to cover
IsDynamicSearchBoxEnabled/SearchSettingsspecifically.
- 主要言語
- PowerShell
- スター
- 2.2k
- フォーク
- 168
- 平均マージ
- 6時間 48分
- マージ済み PR(30日)
- 12
環境構築
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
microsoft/WindowsDeveloperConfig のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
microsoft/WindowsDeveloperConfig#100 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
Question about shimsオープン
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
microsoft/WindowsDeveloperConfig#97 ·
メンテナーはふだん 1 日以内に返信
-
難易度 3/5 1〜2日 初心者へのやさしさ 35/100
microsoft/WindowsDeveloperConfig#96 ·
メンテナーはふだん 1 日以内に返信
-
難易度 3/5 1〜2日 初心者へのやさしさ 45/100
microsoft/WindowsDeveloperConfig#84 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 42/100
microsoft/WindowsDeveloperConfig#57 · コメント 3 件 ·
メンテナーはふだん 1 日以内に返信
microsoft/WindowsDeveloperConfig の issue をすべて見る
似ている issue
-
compiler/runtime
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
ComplianceAsCode/content#15152 ·
メンテナーはふだん 2 日以内に返信
-
Area: Browsers bug report needs triage OS: Windows
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
actions/runner-images#14810 ·
メンテナーはふだん 3 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
メンテナーはふだん 1 日以内に返信
-
out-of-date
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
CachyOS/CachyOS-PKGBUILDS#1922 ·
メンテナーはふだん 1 日以内に返信