resources

UpdateLock: An automatic Windows update management tool native to Win32

In the use of Windows, Windows Update is a very important system infrastructure, but in some scenarios,[…]

21 August, 2026173 Reading21 minutes of reading
article directories

Windows Update is a very important system infrastructure during Windows usage, but in some scenarios, users may want to temporarily control automatic update behavior. For example, test environments, old software compatibility environments, dedicated equipment that is running for a long time, or scenarios where the system needs to be avoided automatically restarting at a specific time.

UpdateLock It is a lightweight Windows tool designed for this need. Project address:

hhht110/UpdateLock GitHub Warehouse

Unlike many scenarios that rely on scripts, PowerShell, or third-party runtimes, UpdateLock uses Native C++/Win32 Implementation, runs as a single-file EXE, and adopts different system strategies for Windows 7, Windows 10, and Windows 11.

This paper mainly introduces the project from the perspective of engineering realization. Turning off system updates may reduce system security, and actual use should be made carefully based on equipment use and security policies.

1. Why do you need to build UpdateLock?

Windows Update is not simply "on" or "off".

Different Windows versions have obvious differences in update mechanisms, policy items, and related services. In particular, Windows 7 and Windows 10/11 are not exactly the same in terms of update management models.

Therefore, a truly update control tool for multiple Windows versions needs to solve several problems:

  1. How to identify the current Windows version?
  2. What policies should different systems modify?
  3. How to avoid rudely deleting system files or destroying update components?
  4. How to save the user's original configuration before modification?
  5. If the modification fails, how to restore the scene?
  6. How to confirm that the configuration is really restored successfully after recovery?
  7. How to run it without. NET, PowerShell, or other extra components?

The design of UpdateLock basically revolves around these issues.

The project README defines it as a "Win7/10/11 Automatic Update Shutdown Tool", which uses native Win32 x86 EXE and completes system configuration modifications through the Windows Registry API and Service Control Manager API.

2. The biggest feature of the project: native Win32

UpdateLock does not select PowerShell, Batch or reg.exe、sc.exe Such external commands call the Windows API directly.

As you can see from the source code, it directly contains:

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

The core logic is built directly on top of the Win32 API.

The benefits of this design are very obvious.

1. Does not rely on PowerShell

Many Windows automation scripts execute PowerShell, such as:

Set-Service
Set-ItemProperty
Get-Service

UpdateLock does not rely on these commands.

This means that it does not need to consider issues such as whether PowerShell is available, whether execution policies restrict scripts, or parsing external command output.

2. Does not rely on. NET Runtime

The project is built using a static CRT approach, with the goal of running directly on Windows 7 SP1, Windows 10, and Windows 11.

Therefore, end users are faced with a more traditional:

UpdateLock.exe

Rather than having to install a software package for the running environment first.

3. More direct error handling

Calling the Win32 API directly also means that the program can get clearer system error codes.

Defined in the source code ThrowWin32(), converts Win32 error codes into error messages that users can understand, such as:

Win32 5：拒绝访问

This approach is more straightforward than simply judging the return value of an external command.

3. Why should Win7 and Win10/11 be treated differently?

This is a more noteworthy point in UpdateLock design.

The project did not adopt a "one set of strategies to conquer the world" approach, but clearly handled Windows 7 and Windows 10/11 separately.

Windows 7

Windows 7 processing mainly involves:

  • NoAutoUpdate
  • DisableWindowsUpdateAccess
  • wuauserv

wherein wuauserv It is a Windows Update service.

In other words, in addition to modifying policies, Win7's plan will also stop and disable the Windows Update service through Windows's Service Control Manager.

However, the project deliberately did not proceed further:

  • BITS
  • CryptSvc
  • TrustedInstaller
  • SoftwareDistribution
  • Catroot2
  • system files

This kind of restraint is actually very important.

If a system tool directly deletes the update cache, modifies system directories, or even replaces system files in order to "completely turn off updates", it can easily change from a configuration tool to a system destruction tool.

UpdateLock's solution is obviously more inclined to:

Modify only the configuration necessary to complete the goal.

4. Windows 10/11: Mainly controlled through policy

Windows 10 and Windows 11 are handled differently.

The project mainly involves the following strategies:

ExcludeWUDriversInQualityUpdate
SetUpdateNotificationLevel
UpdateNotificationLevel
NoAutoUpdate
NoAutoRebootWithLoggedOnUsers
AUOptions

One of the more noteworthy is that AUOptions。

When closed, the project does not simply fix it to a certain value, but uses:

Delete it when closed, and write it back to the original state when restored.

This reflects a very important configuration management idea:

"Restore" should not mean restoring to what the program considers to be the default values, but should restore to the state it was before the user ran the program.

For example, the user's original configuration may be:

AUOptions = 4

This value may be deleted after the program performs a shutdown operation.

When the user selects restore, the program rewrites:

AUOptions = 4

Rather than writing another default value on your own initiative.

5. Version 2.1 further restricts Windows Update entry

UpdateLock 2.1 adds another item:

SetDisableUXWUAccess=1

The goal of this policy is not to stop Windows Update services, but to further restrict Windows Update's user interface entry.

Simply put, it means reducing the number of users using the Windows Update page:

  • manually check for updates
  • download updates
  • install updates

Wait for the opportunity to operate.

There is one important difference here:

Windows 10/11 will not stop because of this wuauserv, BITS, UsoSvc, WaaSMedicSvc, or Update Orchestrator.

This shows that the project author did not adopt the idea of "disabling all updates when you see them", but tried to use the policy mechanism provided by Windows itself.

From the perspective of system stability, this is a relatively conservative solution.

6. Backup and recovery is one of the core designs of this project

If you just modify the registry, it is actually not difficult.

What is really difficult is:

How to recover reliably after modification?

UpdateLock is relatively complete on this point.

Policy backups for Windows 10/11 are located at:

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

The new Windows Update user interface access restrictions are saved separately:

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

Windows 7 usage:

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

This design means that the program records the original state before modifying the system.

Rather than simply assuming:

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

There are essential differences between the two.

For example:

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

Only in this way can we truly achieve "recovery".

7. RAII in source code: Avoid resource leaks

As a native C++ Windows program, UpdateLock also uses RAII to manage system resources.

Several typical packages can be seen in the source code:

ScopedHandle
ScopedRegKey
ScopedServiceHandle

For example:

struct ScopedRegKey {
    HKEY value = nullptr;

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

This type of design solves a very typical C ++/Win32 problem.

The extensive use of the Win32 API is similar:

HANDLE
HKEY
SC_HANDLE

Resource handle to.

If an exception occurs in the middle of the program, it can easily occur:

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

RAII allows resource life cycles to be bound to C++ objects.

Therefore:

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

After leaving scope, the registry handle is automatically released.

This is especially important for a system tool that requires frequent processing of registries, services, and files.

8. Registry operations are not simply "writing values"

The registry logic in the source code is also worth analyzing.

The program defines a policy description similar to this:

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

Then use:

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

A relatively clear operation chain has been formed.

It can be abstracted as:

Read
 ↓
Backup
 ↓
Modify
 ↓
Read Back
 ↓
Verify

Instead of:

Modify
 ↓
Done

This is an important difference between system tools and simple scripts.

9."Read back and verify" after modification

UpdateLock has a very useful mechanism:

Reread the registry after writing for verification.

You can see in the source code:

void VerifyPolicy(const PolicyState& expected)

It recalls the read function and compares:

exists
value

Whether it is in line with expectations.

If there is no consistency, an error is thrown.

This means that the program does not see:

RegSetValueExW()

If you return successfully, the entire operation is considered completed.

Instead:

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

For tools involving system policy, this design can significantly improve operational reliability.

10. Failure rollback

Looking further, this design can also form a complete transactional process:

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

That is, it's not just a series of unrelated registry writes.

If it fails halfway, the program can try to restore the previously modified content to its original state.

This is critical for Windows system configuration tools.

Because the most afraid thing about system configuration modifications is not "complete failure", but:

Half the success.

For example:

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

Without a rollback mechanism, the user will end up with a semi-modified state.

11. Security is also considered in the backup file itself

There is another detail in the source code that is easy to ignore:

The program creates:

%ProgramData%\UpdateLock

And set directory permissions.

Source code uses security descriptors:

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

In other words, access to backup directories is limited to system accounts and administrators.

This design is very meaningful.

Because the backup files record the system policy status, if ordinary users are allowed to modify these files at will, there may be:

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

So for system configuration backup:

Backup files are not ordinary text files.

It also requires consideration of integrity and authority.

12. Why use Base64 for backup formats?

The source code also provides:

Base64Encode()
Base64Decode()

It combines the conversion between UTF-8 and UTF-16.

The Windows API makes heavy use of Unicode strings, while the backup file itself uses UTF-8 text format.

Therefore, the project needs to deal with:

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

Reverse conversion during recovery.

The benefit of this design is to make the backup file format clearer, while avoiding parsing problems caused by certain special characters, line breaks, or local coding environments.

13. Administrator rights and single instance protection

Because the modification is:

HKEY_LOCAL_MACHINE

and system-level resources such as Windows services, so the program requires administrator privileges.

In addition, the project also adds single instance protection.

The source code defines:

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

Windows Mutex prevents users from starting multiple UpdateLock instances at the same time.

Why do you need a single instance?

Because system configuration modifications are usually not suitable for concurrent execution.

If two instances are executed simultaneously:

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

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

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

Problems may arise with the final backup state.

Therefore:

Single-instance protection is actually part of configuration transaction security.

14. The project did not "violently destroy" Windows Update

From an engineering perspective, one of the positive aspects of UpdateLock is that it has clear control over modification boundaries.

It does not expand the goal to:

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

Instead, it mainly focuses on:

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

This is an approach that is more in line with system tool design principles:

Try to meet requirements through the configuration interface provided by the operating system rather than bypassing system mechanisms.

15. For ordinary users, what problems does it solve?

From a user's perspective, the value of UpdateLock can be summarized in one sentence:

Use a native, lightweight Windows program to encapsulate complex update policy modifications, backup, restore, and verification.

Users do not need to open it manually:

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

Then revise them one by one.

The program is responsible for completing:

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

When recovering, the reverse is reversed:

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

This is much more friendly than letting ordinary users manually manipulate the registry.

16. It also has clear use boundaries

What needs to be particularly emphasized is:

Closing or restricting Windows Update is not without cost.

First of all, Windows Update is not only responsible for system patches, but also involves drivers and other content.

The project README specifically pointed out that after turning off driver updates for Windows Update, newly connected USB or other hardware may not be able to automatically obtain drivers online.

So if the equipment needs to install new hardware, consider:

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

In addition, it is not recommended to perform a shutdown or resume operation while Windows is installing or uninstalling updates.

For production environment equipment, it should also be confirmed in advance:

  • Whether there is an enterprise update strategy;
  • Whether there are security patch requirements;
  • Whether you rely on Windows Update to obtain drivers;
  • Whether there is a unified terminal management system;
  • Whether there are requirements to restore system configuration.

In other words:

UpdateLock is a system configuration tool, not a replacement for the Windows update mechanism.

17. Construction method

The project uses Visual Studio Build Tools, MSVC v141 toolchain, and Windows 10 SDK 19041.

in native Catalog execution:

build-native.cmd

Native construction can be carried out.

The project README states that the build output is located in:

native\build

And the build script is generated at the same time:

UpdateLock.exe

and native test procedures.

This project structure is suitable for developers who want to study Win32 system programming.

You can see directly from the source code:

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

Rather than being hidden behind a large number of third-party frameworks.

18. How to evaluate this project?

Judging from the "functional complexity", UpdateLock is not a particularly huge project.

But if we look at the "engineering quality of system tools", it contains many designs worth learning:

1. native APIs

Avoid relying on PowerShell, CMD, reg.exe, and sc.exe.

2. state backup

Record the original configuration before making modifications.

3. recoverable

What is restored is the user's original state, rather than simply restoring the default values.

4. readback verification

After writing, read and confirm again.

5. Failure rollback

Avoid the system in a semi-modified state as much as possible.

6. RAII

Automatically manage Win32 resources.

7. authority control

Limit access to backup directories.

8. single-instance

Avoid multiple configuration operations simultaneously.

These designs actually go beyond the scope of simply "turning off Windows Update scripts."

19. What can you learn from this project?

If you are learning Windows C++ development, UpdateLock is worth paying attention to more than just "how to turn off Windows Update."

What is more worth learning is the engineering ideas behind it:

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

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

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

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

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

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

These principles apply equally to many other system tools, such as:

  • Windows Service Configurator;
  • Registry policy management tool;
  • System initialization tool;
  • Enterprise terminal configuration tool;
  • Local Security Policy Manager;
  • System maintenance procedures.

20. Conclusion

UpdateLock is a small native Windows tool, but it reflects a typical system tool development idea:Reliance less, call system APIs directly, clearly modify boundaries, and put backup, verification and recovery at the core.

It does not attempt to solve the Windows Update problem by deleting system files or roughly disabling all related services, but instead designs separate policies to address the differences between Windows 7 and Windows 10/11.

In particular:

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

It constitutes a relatively important engineering closed loop for the entire project.

For ordinary users, it provides a simple Windows Update control tool; for developers, the more worthy part of it is Win32 registry operations, service control, rights management, RAII, atomic file writing, and system configuration transaction processing。

If your goal is to learn Windows native C++, this project is a good small case: the code is not huge, but it covers many of the problems that real Windows system tools encounter.

Project address:
https://github.com/hhht110/UpdateLock

Note: This article is organized based on the current README and source code in the UpdateLock repository. Windows update policies will change with system versions, patches, and enterprise management policies. Specific behavior should be based on the actual test results of the target system.