資源は

UpdateLock：Windows用のネイティブWin 32自動更新管理ツール

Windows UpdateはWindowsの使用中に非常に重要なシステムインフラストラクチャですが、特定のシナリオでは、[]

2026年8 月21日、164読書21分で読む
記事の目次

Windows UpdateはWindowsの使用中に非常に重要なシステムインフラストラクチャですが、状況によっては自動更新の動作を一時的に制御したい場合があります。たとえば、テスト環境、古いソフトウェア互換性環境、長時間稼働する専用デバイス、または特定の時間にシステムが自動的に再起動する必要があるシナリオなどです。

UPDATELOCK これは、このニーズのために設計された軽量Windowsツールです。プロジェクトの住所：

hhht110/UpdateLock GitHubリポジトリ

スクリプト、Power Shell、サードパーティ製ランタイムに依存する多くのシナリオとは異なり、UpdateLockは ネイティブC++/Win 32 単一ファイルEXEとして実行され、Windows 7、Windows 10、およびWindows 11用に異なるシステムポリシーを使用します。

本稿では、プロジェクトをプロジェクト実現の観点から紹介する。システムアップデートをオフにすると、システムのセキュリティが低下する可能性があります。実際の使用は、デバイスの目的やセキュリティポリシーに基づいて慎重に決定してください。

なぜUpdateLockを使うのか？

Windows Updateは“オン”または“オフ”ではありません。

Windowsバージョンによって、更新メカニズム、ポリシー項目、および関連サービスが大きく異なります。特に、Windows 7とWindows 10/11は、アップデート管理モデルがまったく同じではありません。

したがって、複数のWindowsバージョンの真のアップデート制御ツールには、いくつかの問題があります。

  1. 現在のWindowsバージョンを確認する方法
  2. 異なるシステムで変更すべきポリシーは？
  3. システムファイルの削除やアップデートコンポーネントの破損を避けるには？
  4. 変更前にユーザー設定を保存するには？
  5. 変更に失敗した場合、どのようにしてオンサイトを復元できますか
  6. リカバリ後、構成が実際にリカバリされたことを確認するにはどうすればよいですか
  7. . NET、Power Shell、その他の追加コンポーネントなしで実行する方法は？

UpdateLockはこれらの問題を中心に設計された。

プロジェクトREADMEでは、ネイティブのWin 32 x 86 EXEを使用し、WindowsレジストリAPIとService Control Manager APIを介してシステム構成を変更する“Win 7/10/11自動更新シャットダウンツール”として定義されている。

プロジェクトの最大の機能：ネイティブWin 32

UpdateLockがPower Shell、バッチ、または reg.exe、sc.exe このような外部コマンドは、代わりにWindows APIを直接呼び出す。

ソースコードを見ると、以下が含まれています。

  • windows.h
  • commctrl.h
  • shellapi.h
  • shlobj.h
  • sddl.h
  • aclapi.h
  • wincrypt.h
  • objbase.h
  • wuapi.h

コアロジックはWin 32 APIに直接基づいています。

この設計の利点は明らかです。

1. Power Shellに依存しない

多くのWindowsオートメーションスクリプトはPower Shellを実行します。

Set-Service
Set-ItemProperty
Get-Service

UpdateLockはこれらのコマンドに依存しません。

つまり、Power Shellが利用可能かどうか、実行ポリシーがスクリプトを制限するかどうか、外部コマンド出力の解決などを考慮する必要はありません。

2. . NETランタイムに依存しない。

プロジェクトは静的CRTとして構築され、Windows 7 SP 1、Windows 10、およびWindows 11 上で直接実行することを目標としている。

したがって、エンドユーザーはより伝統的なアプローチに直面します。

UpdateLock.exe

まず、実行環境のパッケージをインストールする必要はありません。

3.より直接的なエラー処理

Win 32 APIを直接呼び出すことで、プログラムはより明確なシステムエラーコードを取得できます。

ソースコードの定義 ThrowWin32()Win 32エラーコードは、ユーザーが理解できるエラーメッセージに変換されます。

Win32 5：拒绝访问

これは、単に外部コマンドの戻り値を判断するよりも簡単です。

なぜWindows 7とWindows 10/11の違いがあるのですか？

これはUpdateLockの設計における最も重要な点です。

このプロジェクトは“世界を征服するための一連の戦略”アプローチではなく、Windows 7とWindows 10/11を明確に分離しています。

Windows 7の場合

Windows 7の処理は主に次のとおりです。

  • NoAutoUpdate
  • DisableWindowsUpdateAccess
  • wuauserv

これらのうち wuauserv Windows Updateサービスです。

つまり、ポリシーの変更に加えて、Win 7のスキームは、Windowsのサービスコントロールマネージャを介してWindows Updateサービスを停止および無効にします。

プロジェクトは意図的に進められなかった。

  • BITSの
  • CryptSvc
  • TrustedInstaller
  • ソフトウェア配布物
  • Catroot 2
  • システムファイル

この自制は本当に重要です。

更新キャッシュを削除したり、システムディレクトリを変更したり、システムファイルを置き換えたりして“アップデートを完全に閉じる”ために、システムツールは設定ツールからシステム破壊ツールに簡単に変わります。

UpdateLockプログラムは明らかに以下のようになります。

ターゲットを完了するために必要な構成のみを変更します。

Windows 10/11：主にポリシーによる制御

Windows 10とWindows 11では処理が異なります。

プロジェクトは主に以下の戦略に取り組んでいます。

ExcludeWUDriversInQualityUpdate
SetUpdateNotificationLevel
UpdateNotificationLevel
NoAutoUpdate
NoAutoRebootWithLoggedOnUsers
AUOptions

もっと注目すべきは AUOptions。

閉じると、プロジェクトは単に値に固定されるのではなく、次のようになります。

シャットダウン時に削除し、復元時に元の状態に書き戻します。

これは非常に重要な管理概念を反映している。

“復元”とは、プログラムがデフォルトとみなす値に戻すことを意味するのではなく、ユーザーがプログラムを実行する前の状態に戻すことを意味します。

例えば、ユーザーの元の構成は：

AUOptions = 4

プログラムが閉じると、この値は削除されます。

ユーザーがリカバリを選択すると、プログラムは次のような書き込みを再開します。

AUOptions = 4

自分で別のデフォルト値を書き込む代わりに。

バージョン2.1でWindows Updateのエントリーをさらに制限

UpdateLock 2.1には以下の機能が追加された。

SetDisableUXWUAccess=1

このポリシーの目的は、Windows Updateサービスを停止することではなく、Windows Updateのユーザーインターフェイスへのアクセスをさらに制限することです。

簡単に言えば、Windows Updateページを介してユーザーを減らすことです。

  • 更新の手動チェック
  • アップデートのダウンロード
  • アップデートのインストール

操作の機会を待つ。

ここに重要な違いがあります。

Windows 10/11はすぐに停止しません wuauserv、BITS、UsoSvc、WaaSMedicSvc、またはUpdate Orchestratorを使用します。

これは、プロジェクトの著者が“アップデートを見たらすべて無効にする”という考え方を採用するのではなく、Windows自体が提供するポリシーメカニズムを使用しようとしていることを意味します。

システム安定性の観点からは、これは比較的保守的なソリューションです。

バックアップとリカバリは、このプロジェクトの中核設計の1つです。

レジストリを変更するだけでも、それほど難しくありません。

本当に難しいことは：

変更後に確実に復元する方法は？

UpdateLockはこの点でかなりうまくいきます。

Windows 10/11のポリシーバックアップは次のとおりです。

%ProgramData%\UpdateLock\policy-backup-v1.txt

Windows Updateの新しいユーザーインターフェイスアクセス制限は、別途保存されます。

%ProgramData%\UpdateLock\windows-update-access-backup-v1.txt

Windows 7では、次のような機能があります。

%ProgramData%\UpdateLock\windows7-original-state-v1.txt

この設計は、プログラムがシステムを変更する前に元の状態を記録することを意味する。

単純に仮定するより：

恢复 = 删除我刚刚写入的值

両者には本質的な違いがある

例えば：

用户原配置
    ↓
读取并保存
    ↓
UpdateLock 修改
    ↓
Windows Update 被限制
    ↓
用户选择恢复
    ↓
重新写入原配置

それが本当に“回復”するのです。

ソースコード内のRAII：リソース漏洩を避ける

C++ WindowsネイティブプログラムであるUpdateLockは、システムリソースの管理にRAIIを使用します。

ソースコードにはいくつかの典型的なパッケージがあります：

ScopedHandle
ScopedRegKey
ScopedServiceHandle

例えば：

struct ScopedRegKey {
    HKEY value = nullptr;

    ~ScopedRegKey() {
        if (value) RegCloseKey(value);
    }
};

このタイプの設計は、典型的なC++/Win 32の問題を解決します。

Win 32 APIはよく似ています。

HANDLE
HKEY
SC_HANDLE

資源管理者。

プログラムの途中で例外が発生すると、簡単に発生します：

打开资源
↓
执行操作
↓
中途失败
↓
没有释放资源

RAIIはリソースのライフサイクルをC++オブジェクトに結びつけることができる。

そのため、

{
    ScopedRegKey key;
    // 操作注册表
}

スコープを離れると、レジストリハンドルが自動的に解放されます。

これは、レジストリ、サービス、およびファイルを頻繁に処理する必要があるシステムツールでは特に重要です。

レジストリ操作は単純な“値の書き込み”ではありません。

ソースコード内のレジストリロジックも分析する価値があります。

プログラムは次のようなポリシー記述を定義します：

struct PolicyValue {
    const wchar_t* path;
    const wchar_t* name;
};

そして使用する：

ReadDwordState()
SetDword()
DeleteDword()
RestorePolicy()
VerifyPolicy()

より明確な操作チェーンが形成されます。

抽象化できる。

Read
 ↓
Backup
 ↓
Modify
 ↓
Read Back
 ↓
Verify

代わりに：

Modify
 ↓
Done

これは、システムツールと単純なスクリプトの重要な違いです。

9.改正後の“バック·バリデーション”

UpdateLockには便利なメカニズムがあります。

書き込み後にレジストリを再読み込みして検証します。

ソースコードで見ることができます：

void VerifyPolicy(const PolicyState& expected)

read関数を再呼び出し、比較します：

exists
value

期待と一致しています

一致しない場合はエラーがスローされます。

つまり、プログラムは表示されません。

RegSetValueExW()

成功を返すと、操作全体が完了したとみなされます。

しかしながら：

写入成功
    ↓
重新读取
    ↓
比较预期状态
    ↓
确认一致

システムポリシーに関わるツールの場合、この設計は運用の信頼性を大幅に向上させます。

10.失敗の回復

さらに、この設計は完全なトランザクションフローを形成することもできます。

保存原始状态
       ↓
修改策略 A
       ↓
修改策略 B
       ↓
修改策略 C
       ↓
某一步失败
       ↓
恢复 A
       ↓
恢复 B
       ↓
恢复 C

つまり、無関係な一連のレジストリ書き込み操作を実行するだけではありません。

途中で失敗した場合、プログラムは以前に変更したものを元の状態に復元しようとすることができます。

これは、Windowsシステム構成ツールでは非常に重要です。

システム構成の変更が最も恐れるのは“完全な失敗”ではなく、

半分成功した。

例えば：

策略 1 修改成功
策略 2 修改成功
策略 3 修改失败

ロールバックメカニズムがなければ、ユーザは半修正状態になります。

11.バックアップファイル自体もセキュリティを考慮している

ソースコードには見落とされがちな詳細があります。

プログラムが作成されます：

%ProgramData%\UpdateLock

ディレクトリ権限を設定します。

セキュリティ記述子を使用するソース：

D:P(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)

つまり、バックアップディレクトリへのアクセスは、システムアカウントと管理者に制限されます。

デザインは意味がある。

バックアップファイルにはシステムポリシーの状態が記録されるため、一般ユーザーがこれらのファイルを自由に変更できるようにすると、次のようになります。

程序保存状态
        ↓
文件被篡改
        ↓
用户点击恢复
        ↓
程序恢复恶意/错误配置

システムバックアップの場合：

バックアップファイルは通常のテキストファイルではありません。

完全性と能力も考慮する必要があります。

なぜBase 64を使用するのか？

ソースコードも提供します：

Base64Encode()
Base64Decode()

UTF-8とUTF-16間の変換を組み合わせてください。

Windows APIはUnicode文字列を多用しますが、バックアップファイル自体はUTF-8テキスト形式です。

プロジェクトに取り組む必要がある：

Windows UTF-16
        ↓
UTF-8
        ↓
Base64
        ↓
备份文件

復元時に変換を逆にする。

この設計の利点は、特定の特殊文字、改行、またはローカルコーディング環境に起因する解析の問題を回避しながら、バックアップファイルの形式を明確にすることです。

13.管理者権限と単一インスタンス保護

変更された理由：

HKEY_LOCAL_MACHINE

Windowsサービスなどのシステムレベルのリソースと同様に、プログラムには管理者権限が必要です。

これに加えて、プロジェクトは単一インスタンス保護を追加します。

ソースコードの定義：

const wchar_t* const kMutexName =
    L"Global\\UpdateLock.SingleInstance.7A64EA9A";

Windows Mutexを使用すると、複数のUpdateLockインスタンスを同時に起動できなくなります。

なぜ単一例が必要か？

システム構成の変更は、通常、同時実行に適した操作ではないためです。

2つのインスタンスが同時に実行される場合：

实例 A：读取旧配置
实例 B：读取旧配置

实例 A：写入新配置
实例 B：写入新配置

实例 A：备份
实例 B：备份

最終的なバックアップ状態に問題があるかもしれない。

そのため、

単一インスタンス保護は、実際には構成トランザクションセキュリティの一部です。

プロジェクトに“暴力的な破壊”Windows Updateはない

エンジニアリングの観点から、UpdateLockの素晴らしい点の1つは、変更の境界をより明確に制御できることです。

目標を拡張していない：

删除 SoftwareDistribution
删除 Catroot2
禁用所有相关服务
删除更新文件
修改系统文件
阻止 Windows Update 进程启动

主に焦点を当てた：

Windows Update Policy
+
必要的服务控制
+
备份与恢复

これは、システムツールの設計原則に沿ったアプローチです。

システムメカニズムをバイパスするのではなく、オペレーティングシステムが提供する構成インターフェイスを介して要件を実装します。

一般ユーザーにとって、どんな問題が解決されますか？

ユーザーの観点から見ると、UpdateLockの価値は1つの文に要約できます。

複雑な更新ポリシーの変更、バックアップ、復元、検証を、ネイティブで軽量なWindowsプログラムでカプセル化します。

ユーザーが手動で開く必要はありません：

注册表编辑器
本地组策略
服务管理器
命令提示符
PowerShell

そして、一つ一つ修正。

手続き完了の責任：

识别系统
   ↓
读取原配置
   ↓
备份
   ↓
修改策略
   ↓
验证
   ↓
必要时回滚

逆に回復します：

读取备份
   ↓
恢复原配置
   ↓
回读
   ↓
验证

これは、通常のユーザーが手動でレジストリを操作するよりもはるかにフレンドリーです。

また、明確な境界線があります。

特に強調すべき点は：

Windows Updateのシャットダウンまたは制限にはコストがかかります。

まず、Windows Updateはシステムパッチだけでなく、ドライバなども担当しています。

プロジェクトREADMEでは、Windows Updateのドライバ更新をオフにすると、新しく接続されたUSBやその他のハードウェアが自動的にオンラインでドライバを取得できないことがあると指摘しています。

新しいハードウェアをインストールする必要がある場合は、以下を検討します。

恢复 Windows Update
       ↓
安装/获取驱动
       ↓
重新关闭更新策略

また、Windowsが更新プログラムをインストールまたはアンインストールしている間にシャットダウンまたは復元操作を実行することはお勧めしません。

生産環境機器については、事前に以下を確認する必要があります。

  • エンタープライズアップデートポリシーの存在;
  • セキュリティパッチ要件があるかどうか。
  • Windows Updateに依存してドライバを取得します。
  • 統合ターミナル管理システムの有無。
  • システム構成を復元するための要件があるかどうか。

言い換えれば、

UpdateLockはシステム構成ツールであり、Windowsアップデートメカニズムの代替ではありません。

17.建設の仕方

プロジェクトでは、Visual Studio Build Tools、MSVC v 141ツールチェーン、およびWindows 10 SDK 19041を使用します。

そこには native カタログの実行：

build-native.cmd

ネイティブビルドが可能です。

プロジェクトREADMEによると、ビルド出力は以下の通りです。

native\build

同時にスクリプトを生成します：

UpdateLock.exe

ネイティブテストプログラムです。

このプロジェクト構造は、Win 32システムプログラミングを研究したい開発者に適しています。

ソースから直接見ることができます：

Win32 API
   ↓
Registry API
   ↓
SCM API
   ↓
文件 API
   ↓
安全描述符 API
   ↓
GUI

多くのサードパーティ製フレームワークの背後に隠れていません

18このプロジェクトを評価する方法は？

UpdateLockは、“機能の複雑さ”から判断すると、特に大きなプロジェクトではありません。

しかし、“システムツールのエンジニアリング品質”の観点から見ると、学ぶ価値のあるデザインがたくさん含まれています。

1.ネイティブAPI。

Power Shell、CMD、reg.exe、sc.exeに依存しないでください。

2.状態バックアップ

変更前に元の構成をログに記録します。

3.回復可能です。

単純にデフォルト値を復元するのではなく、ユーザーの元の状態を復元します。

4.読み取りバック検証

書き込み後に再度読み出し確認を行う。

5.失敗したロールバック

システムが半修正状態になるのは、できるだけ避けてください。

6. RAIIさん

Win 32リソースの自動管理。

7.アクセス権制御

バックアップ·カタログへのアクセス権を制限します。

8.シングル·インスタンス

複数の設定操作を同時に行うことを避ける。

これらのデザインは、単純な“Windows Updateスクリプトを閉じる”というものを超えています。

このプロジェクトから何が学べるでしょうか。

Windows C++開発を学んでいる場合、UpdateLockは“Windows Updateをオフにする方法”だけではありません。

さらに興味深いのは、その背後にあるエンジニアリングのアイデアです。

不要直接修改
      ↓
先读取状态

不要假设修改成功
      ↓
写入后验证

不要覆盖用户配置
      ↓
先备份

不要只考虑成功路径
      ↓
设计失败回滚

不要依赖外部命令
      ↓
直接调用系统 API

不要无限扩大修改范围
      ↓
只操作必要的系统接口

これらの原則は、以下のような他の多くのシステムツールにも当てはまります。

  • Windowsサービスコンフィグレータ;
  • レジストリポリシー管理ツール
  • システム初期化ツール。
  • エンタープライズ端末の設定ツール;
  • ローカルセキュリティポリシーマネージャ;
  • システムメンテナンス手順。

XX.おわりに

UpdateLockはWindows用の小さなネイティブツールですが、システムツール開発の典型的な考え方を反映しています。依存関係が少なく、システムAPIを直接呼び出し、境界を明確に変更し、バックアップ、検証、リカバリを中心に据えます。

システムファイルを削除したり、関連するすべてのサービスを無効にしたりすることでWindows Updateの問題を解決しようとするのではなく、Windows 7とWindows 10/11の違いに対処するために別々のポリシーを設計します。

特に：

原始状态备份
      +
策略修改
      +
回读验证
      +
失败回滚
      +
完整恢复

プロジェクト全体のより重要なエンジニアリングクローズドループを構成します。

一般ユーザーにとっては、シンプルなWindows Update制御ツールを提供しますが、開発者にとっては、より興味深い部分があります。 Win 32レジストリ操作、サービス制御、アクセス権管理、RAII、アトミックファイル書き込み、およびシステム構成トランザクション処理。

WindowsネイティブC++を学ぶことが目標であれば、このプロジェクトは小さなケースです。コードサイズはそれほど大きくはありませんが、実際のWindowsシステムツールが遭遇する多くの問題をカバーしています。

プロジェクトの住所：
https://github.com/hhht110/UpdateLock

注：この記事はUpdateLockリポジトリの現在のREADMEとソースコードに基づいています。Windowsアップデートポリシーは、システムのバージョン、パッチ、およびエンタープライズ管理ポリシーによって変更され、対象システムの実際のテスト結果に基づいて変更されます。