Windows 11 on kenji.blog

How to Create MSIX Packages for Windows 11 and the Self-Signed Certificate Trap

Sat, 12 Sep 2026 22:00:00 +0900

In the era of Windows 11, “MSIX” is becoming the standard choice for application distribution formats. Traditional installers like MSI and EXE had many issues, but MSIX is expected to be the next-generation packaging technology that solves them. However, when developers actually create an MSIX package and attempt sideloading in an organization or test environment, they often fall into the “self-signed certificate trap”.

In this article, we will provide a very detailed explanation ranging from technical details of MSIX, how to create packages using Visual Studio and command-line tools, to the causes and solutions of the self-signed certificate errors that many developers face. We aim to make this a must-read guide for Windows app developers, infrastructure administrators, and packaging personnel.

1. What is MSIX? Comparison with Traditional MSI/EXE

MSIX is the latest application packaging format for Windows provided by Microsoft. It integrates all the excellent features and concepts of traditional MSIs (Microsoft Installers), .exe-based custom installers, App-V (Application Virtualization), and AppX (Universal Windows Platform app packages) introduced since Windows 8, and evolves them to meet modern security and deployment requirements.

Issues with Traditional Installers (MSI/EXE)

MSI and EXE, which have long been used as standard installation formats for Windows, had the following fundamental problems:

Win Rot: As applications are repeatedly installed and uninstalled, unnecessary keys are left in the registry, and DLLs are left behind in system folders (such as C:\Windows\System32). This causes the OS itself to gradually slow down and become unstable.
DLL Hell: When multiple applications try to install DLLs with the same name (but different versions) into a shared system directory, the app installed later overwrites the existing DLL, causing the previously installed app to stop working properly.
Instability from Custom Actions: MSI packages can run arbitrary scripts or code called “custom actions” with system privileges during installation and uninstallation. This carried the risk of the installer crashing midway or causing unexpected system configuration changes.

Solutions through MSIX Containerization Architecture

MSIX solves these issues by running applications inside a lightweight “container”. This containerization approach offers the following tremendous benefits:

Clean Uninstalls: Apps installed via MSIX perform file system and registry writes virtually (VFS: Virtual File System, VReg: Virtual Registry). Therefore, when uninstalled, this virtualized container is deleted entirely, leaving zero garbage (remnants) on the system. It completely prevents Win Rot.
Isolation and Security: Each app runs within its own environment and does not directly corrupt the DLLs or resources of other apps. This frees you from DLL Hell.
Network Bandwidth Optimization: The MSIX update mechanism is highly excellent and supports block-level differential updates. Since it only downloads the few blocks of binary data that have changed, it minimizes the load on the network even when updating large applications.
Reliable Installation State: The package includes a manifest file (AppxManifest.xml), and the installation transaction is strictly managed at the OS level. If it fails, it is completely rolled back to its original state.

2. Overview of MSIX Package Creation and Toolchain

There are broadly two approaches to creating an MSIX package. One is to use the Visual Studio Integrated Development Environment (IDE), and the other is to make full use of the command-line tools (MakeAppx.exe and SignTool.exe) bundled with the Windows SDK.

The following Mermaid diagram shows the process from source files to the generation of the final signed MSIX package.

flowchart TD
A["Source Files (EXE, DLL, Assets, etc.)"] --> B["AppxManifest.xml (Manifest Definition)"]
B --> C["MakeAppx.exe (MSIX Packager)"]
C --> D["Unsigned MSIX Package (.msix)"]
E["Digital Certificate (.pfx)"] --> F["SignTool.exe (Digital Signer)"]
D --> F
F --> G["Signed MSIX Package (Ready for Deployment)"]
style A fill:#f9f9f9,stroke:#333
style B fill:#e6f7ff,stroke:#333
style D fill:#ffcccb,stroke:#333
style G fill:#d4edda,stroke:#333

As can be seen from this process, simply gathering and bundling the files (packaging) is not enough; a “digital signature” step is absolutely necessary. For security reasons, Windows 11 does not permit the installation of unsigned MSIX packages at all.

3. Approach A: Creating MSIX using Visual Studio

The easiest and most common method is to use the “Windows Application Packaging Project (WAP)” in Visual Studio. Using this project template, you can easily convert WPF, Windows Forms, WinUI 3, and even legacy C++ Win32 apps into MSIX.

Step-by-Step Guide

Add a WAP Project: Right-click your existing Visual Studio solution, select “Add New Project”, and choose “Windows Application Packaging Project”.
Select Target Platforms: Specify the minimum and target versions of Windows 10/11 supported by the app.
Reference the Application: Right-click the “Applications” node in the packaging project, select “Add Reference”, and choose the main project you want to package (e.g., a WPF project).
Configure the Manifest: Double-click the Package.appxmanifest file to open the visual designer. Here, you set the app’s display name, description, logo image, and most importantly, the “Identity Name” and “Publisher”.
Create the Package: Right-click the project and select “Publish” -> “Create App Packages”. Selecting “Sideloading” and choosing the architecture (x64, ARM64, etc.) allows Visual Studio to automatically handle compilation, packaging via MakeAppx, and even generating and signing with a self-signed certificate.

It is very seamless, but if you use the automatically generated self-signed certificate (Test Certificate) from Visual Studio here, you will fall into the “trap” described later.

4. Approach B: Creating using the Command Line (MakeAppx.exe)

Command-line tools are required for automation in CI/CD pipelines or when manually repackaging a set of files from an existing installer. If the Windows SDK is installed in your environment, you can access the following tools from the Developer Command Prompt.

1. Preparing the Manifest File

Create an AppxManifest.xml describing minimal information in the root directory of the package.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40


<?xml version="1.0" encoding="utf-8"?>
<Package xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10"
 xmlns:uap="http://schemas.microsoft.com/appx/manifest/uap/windows10"
 xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities">

 <Identity Name="MyCompany.AwesomeApp"
 Publisher="CN=MyCompany Self-Signed, O=MyCompany"
 Version="1.0.0.0"
 ProcessorArchitecture="x64" />

 <Properties>
 <DisplayName>Awesome App</DisplayName>
 <PublisherDisplayName>My Company</PublisherDisplayName>
 <Logo>Assets\StoreLogo.png</Logo>
 </Properties>

 <Resources>
 <Resource Language="en-us" />
 <Resource Language="ja-jp" />
 </Resources>

 <Dependencies>
 <TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.17763.0" MaxVersionTested="10.0.22000.0" />
 </Dependencies>

 <Capabilities>
 <rescap:Capability Name="runFullTrust" />
 </Capabilities>

 <Applications>
 <Application Id="AwesomeApp" Executable="AwesomeApp.exe" EntryPoint="Windows.FullTrustApplication">
 <uap:VisualElements DisplayName="Awesome App"
 Description="The best app ever."
 BackgroundColor="transparent"
 Square150x150Logo="Assets\Square150x150Logo.png"
 Square44x44Logo="Assets\Square44x44Logo.png">
 </uap:VisualElements>
 </Application>
 </Applications>
</Package>

What is important here is that the value of <Identity Publisher="..." /> must strictly match the Subject of the certificate that will be used for signing later.

2. Packaging with MakeAppx

Execute the following command in the Command Prompt to bundle the directory into an MSIX file.

1

MakeAppx.exe pack /d "C:\Path\To\AppFolder" /p "C:\Path\To\Output\AwesomeApp_1.0.0.0_x64.msix"

This completes an unsigned MSIX file, but it cannot be installed on Windows in this state.

5. Mathematical Background of Digital Signatures and Cryptography

To deeply understand why an MSIX package requires a signature, you need to understand the cryptographic mechanisms behind digital signatures. A digital signature guarantees that the package was “certainly created by the specified publisher (Authentication)” and that it “has not been tampered with by a third party between creation and the present (Integrity)”.

RSA cryptography and SHA-256 (Secure Hash Algorithm 256-bit) are typically combined and used for MSIX signatures.

Application of Hash Functions

First, let the entire binary (contents) of the MSIX package be the message $M$. The signing tool (SignTool.exe) applies SHA-256, a cryptographic hash function, to this message $M$ to compute a fixed-length (256-bit) hash value $H(M)$.

Generation of the Signature (Publisher)

Next, the publisher encrypts the hash value using their own “Private Key” $d$ to generate the digital signature $\sigma$. In the context of the RSA algorithm, this is expressed as a modular exponentiation operation as follows:

$$ \sigma \equiv (H(M))^d \pmod n $$

Here, $n$ is the RSA modulus (the product of two huge prime numbers). A certificate (X.509 format) containing this signature $\sigma$ and the publisher’s “Public Key” $e$ is embedded as part of the MSIX package (AppxSignature.p7x).

Verification of the Signature (Windows OS)

When a user attempts to install the MSIX, the Windows OS extracts the public key $e$ from the certificate inside the package and performs the following calculation to restore the hash value $H'(M)$:

$$ H'(M) \equiv \sigma^e \pmod n $$

At the same time, the OS recalculates the hash value $H(M)$ of the entire downloaded MSIX package $M$ on its own. Finally, it verifies whether the restored hash value and the recalculated hash value are equal ($H(M) = H'(M)$). If this equation holds true, it mathematically proves that “not a single bit of the file has been tampered with since signing”.

6. The Biggest Barrier: “The Self-Signed Certificate Trap”

Even if the mathematical proof above is perfect, Windows 11 will not permit the installation with just that. This is because it needs to verify a “Chain of Trust”, asking “is the owner of that public key (certificate) truly the secure organization/person they claim to be?”.

If the certificate was issued by a public Root Certificate Authority (Root CA) that is pre-trusted by the OS, such as VeriSign or DigiCert, it can be installed without any problems (apps distributed via the Microsoft Store are similarly trusted by Microsoft’s root certificate).

However, when costs for purchasing a public certificate cannot be justified, such as during development or for internal-only tools, developers issue a certificate themselves. This is a “Self-Signed Certificate”.

The following sequence diagram shows the behavior of the OS when attempting to install an MSIX package signed with a self-signed certificate.

sequenceDiagram
autonumber
participant U as "User (Windows 11)"
participant P as "MSIX App Installer"
participant C as "Windows Certificate Store"
U->>P: "Double click .msix file"
P->>P: "Read AppxSignature.p7x"
P->>P: "Extract Signature & Certificate"
P->>P: "Verify Math (Hashes match?)"
P->>C: "Check Publisher Certificate Trust"
alt "Certificate is in Trusted Root CA Store"
C-->>P: "Trust Verified Successfully"
P->>U: "Prompt Installation (Install button is ACTIVE)"
U->>P: "Clicks Install"
P->>U: "Installation Successful"
else "Certificate is NOT Trusted (The Trap)"
C-->>P: "Trust Verification Failed (0x800B0109)"
P->>U: "Show Error: Certificate chain processed, but terminated in a root certificate which is not trusted"
P->>U: "Install button is DISABLED"
end

This is exactly the “trap”. Even though the developer created and correctly signed it themselves, the default state of Windows 11 does not know (does not trust) that self-signed certificate, so the installation is blocked with the error code 0x800B0109. The “Install” button on the installer is grayed out and cannot be clicked.

Many developers face this error and fall into the maze of rewriting manifest files repeatedly, thinking “MSIX is full of bugs” or “the configuration must be wrong”, but the problem lies not in the package structure, but in whether or not it is registered in the OS Certificate Store.

7. Solution: Creating and Deploying a Self-Signed Certificate using PowerShell

To solve this problem, you must reliably execute the following two steps.

Create a valid self-signed certificate and export a PFX file containing the private key.
Install the public key portion (CER file) of the created certificate into the “Trusted Root Certification Authorities” store of all target PCs.

By using PowerShell, these can be processed reliably and automatically.

Step 1: Creating and Exporting a Self-Signed Certificate

First, launch PowerShell with administrator privileges and run the following script to create a certificate. Here, we generate a certificate specialized for Code Signing purposes.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


# 1. Parameter Definition
$SubjectName = "CN=MyCompany Self-Signed, O=MyCompany"
$CertStoreLocation = "Cert:\CurrentUser\My"

# 2. Generate Self-Signed Certificate (For Code Signing: 1.3.6.1.5.5.7.3.3)
$Cert = New-SelfSignedCertificate -Type Custom `
 -Subject $SubjectName `
 -KeyUsage DigitalSignature `
 -FriendlyName "MyCompany MSIX Signing Cert" `
 -CertStoreLocation $CertStoreLocation `
 -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.3", "2.5.29.19={text}")

Write-Host "Certificate generated. Thumbprint: $($Cert.Thumbprint)"

# 3. Create Password for PFX Export (including private key)
$Password = ConvertTo-SecureString -String "YourSecurePassword123!" -Force -AsPlainText

# 4. Export PFX File (For signing with SignTool)
$PfxPath = "C:\Path\To\Output\MyCompanyCert.pfx"
Export-PfxCertificate -Cert $Cert -FilePath $PfxPath -Password $Password

# 5. Export CER (Public key only) (For installation on client PCs)
$CerPath = "C:\Path\To\Output\MyCompanyCert.cer"
Export-Certificate -Cert $Cert -FilePath $CerPath

Sign the MSIX package using the $PfxPath file created here.

1

SignTool.exe sign /fd SHA256 /a /f "C:\Path\To\Output\MyCompanyCert.pfx" /p "YourSecurePassword123!" "C:\Path\To\Output\AwesomeApp_1.0.0.0_x64.msix"

Step 2: Installing the Certificate on Client PCs (Disarming the Trap)

Even if you take the signed MSIX to another PC (or virtual environment) and double-click it as is, it cannot be installed as mentioned earlier. Beforehand (or simultaneously), you must install the $CerPath file exported earlier into the “Trusted Root Certification Authorities” of the “Local Machine”.

To do this, open PowerShell with administrator privileges on the deployment target PC and execute the following command.

1
2
3
4
5
6
7


# Path to the CER file
$CerPath = "C:\Path\To\Output\MyCompanyCert.cer"

# Import into the "Trusted Root Certification Authorities" of the local machine
Import-Certificate -FilePath $CerPath -CertStoreLocation "Cert:\LocalMachine\Root"

Write-Host "Certificate installed to Trusted Root Certification Authorities."

[!CAUTION] Administrator privileges are required to add it to the root certification authority store of the “Local Machine” (LocalMachine). Be careful because if you put it in a user’s personal store (CurrentUser), it may not be recognized due to the permission context of the App Installer.

Immediately after this script succeeds, try double-clicking the MSIX file that was producing an error earlier again. Just like magic, the error message should disappear, and a bright blue active “Install” button should be displayed. You have now completely broken through the “Self-Signed Certificate Trap”.

8. Enterprise Environment Operations and Best Practices

For a developer’s local testing, the above procedure is sufficient, but when deploying a sideloaded app to dozens or hundreds of PCs within a company, it is unrealistic to have each user run the certificate installation script, and it also comes with security risks.

Best practices in an enterprise environment are as follows:

1. Utilizing Active Directory Group Policy (GPO)

If Active Directory is introduced in your company, you can use the “Public Key Policies” of a GPO to automatically distribute the self-signed certificate (CER file) to the “Trusted Root Certification Authorities” of all domain-joined PCs. This allows employees to install simply by double-clicking the MSIX file on a shared folder without being conscious of certificates at all.

2. Deployment via Microsoft Intune (MDM)

In modern environments, device management is performed using Microsoft Intune. In Intune, you can push a trusted certificate (.cer) to endpoints using the “Configuration profile” feature. Afterward, it is possible to deploy the MSIX package itself as a Line of Business (LOB) application as a silent install.

3. Automatic Updates via App Installer Files (.appinstaller)

MSIX is equipped with a powerful feature to automate app updates. By creating an XML-based .appinstaller file and placing it on a web server or SMB shared folder, you can have it check for new versions of the MSIX in the background when the app launches and automatically apply updates.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


<?xml version="1.0" encoding="utf-8"?>
<AppInstaller
 Uri="https://internal.mycompany.com/apps/AwesomeApp.appinstaller"
 Version="1.0.0.0"
 xmlns="http://schemas.microsoft.com/appx/appinstaller/2018">
 <MainPackage
 Name="MyCompany.AwesomeApp"
 Publisher="CN=MyCompany Self-Signed, O=MyCompany"
 Version="1.0.0.0"
 ProcessorArchitecture="x64"
 Uri="https://internal.mycompany.com/apps/AwesomeApp_1.0.0.0_x64.msix" />
 <UpdateSettings>
 <OnLaunch HoursBetweenUpdateChecks="0" />
 </UpdateSettings>
</AppInstaller>

By distributing this file to users and having them install it, you can subsequently update the apps for all users automatically just by replacing the MSIX file on the server and updating the version number in the .appinstaller.

Finally, let’s summarize other common errors and solutions related to certificates and signing that may occur.

0x800B0101: The certificate used for signing has expired. Reissue a new certificate, or use a timestamp server (e.g., http://timestamp.digicert.com) during signing to prove that it was signed within the certificate’s validity period (if a timestamp is attached, the signature is considered valid even if the certificate itself expires).
0x80080204: The Publisher value listed in AppxManifest.xml does not perfectly match the Subject value of the certificate. Strictly check whether they are an exact string match, including the presence or absence of spaces after commas.
Checking the Event Viewer: To investigate the detailed cause of an error, it is very important to open the Windows Event Viewer and check the logs under “Applications and Services Logs” -> “Microsoft” -> “Windows” -> “AppxPackagingOM” or “AppXDeployment-Server”.

10. Conclusion

MSIX packaging for Windows 11 is a powerful technology that dramatically improves the lifecycle management of applications. You can be freed from Win Rot and DLL Hell, providing users with a clean and secure environment.

On the other hand, because the security model has become stricter, a deep understanding of digital signatures and the “Chain of Trust” of certificates is indispensable. The “Self-Signed Certificate Trap” is a gateway that almost all developers who touch MSIX technology for the first time will face. By understanding the mechanisms of generating, exporting, and importing certificates into the appropriate stores explained in this article, and automating them using scripts or GPOs, you will be able to realize a smooth deployment that maximizes the potential of MSIX.

Please utilize this knowledge to build a next-generation, clean Windows application distribution environment.

Basic Knowledge of the Windows Registry and Safe Programmable Editing Methods

Sat, 12 Sep 2026 12:00:00 +0900

Basic Knowledge of the Windows Registry and Safe Programmable Editing Methods

In the Windows operating system, the “Registry” is a massive hierarchical database that stores various settings for the system and applications. This article provides a very detailed explanation, starting from the basic architecture of the Windows Registry to programmable and safe registry editing methods using PowerShell and C#.

1. Introduction: History and Evolution of the Windows Registry

In early versions of Windows (Windows 3.x era), system and application settings were mainly stored in .ini (initialization) files. However, countless INI files for each application scattered across the entire system, making management significantly complicated. Furthermore, since INI files are plain text-based, saving binary data was difficult, and there was no access control (security) mechanism. The file parsing speed was also slow, making it unsuitable for saving large-scale settings.

To fundamentally resolve these issues, the “Registry” was fully adopted as a centralized configuration database starting from Windows NT and Windows 95. The registry is a hierarchical database that provides strong typing, support for binary data, and robust security features through Access Control Lists (ACLs). This allowed all components, from the OS kernel to user-space applications, to read and write settings using a unified interface (the Reg* functions of the Win32 API).

Up to the modern Windows 11, the registry continues to function as the heart of the OS. All metadata required for system operation, such as hardware configuration, device driver load order, user desktop environments, and lists of installed software, are consolidated in the registry.

2. Deep Dive into the Architecture: The Reality of Registry Hives and Memory Mapping

Although the registry logically appears as a single giant tree structure, physically it is split into multiple files called “Hives” stored on the disk. This separates system-wide settings from user-specific settings, enabling efficient loading.

The main hive files are usually located in the %SystemRoot%\System32\config directory.

SYSTEM: Critical settings required for operating system boot (drivers, services, boot configurations, etc.).
SOFTWARE: System-wide settings for installed software. Most third-party application settings go here.
SAM: Security Accounts Manager (local user accounts and password hashes).
SECURITY: Local security policies and privilege assignments.
DEFAULT: The default user profile (template when creating a new user).

User-specific hive files exist as hidden files in the user’s profile directory (e.g., C:\Users\Username).

NTUSER.DAT: Basic settings for that user (most of HKCU).
UsrClass.dat: File extension association settings for that user (located in AppData\Local\Microsoft\Windows).

These files are mapped into the kernel paged pool memory by the kernel’s “Configuration Manager (CM)” during OS boot. The Configuration Manager is a kernel-mode component that processes registry read/write requests.

It is worth noting that not all registry data exists on the disk. For example, the HARDWARE hive is volatile and is never saved to a file on the disk. It is dynamically rebuilt in memory every time the OS boots and the Plug and Play (PnP) manager detects hardware.

Also, recent versions of Windows implement transaction logging to enhance registry reliability. Changes to hive files are not directly written to the data files, but are first recorded in transaction logs (.log1, .log2). This prevents data corruption during unexpected power losses or system crashes while writing, ensuring database integrity in a form close to ACID properties.

3. Hierarchical Structure of Registry Keys and Values

The registry has a hierarchical structure very similar to a file system. The root node is called a “Root Key” or “Hive”, and under it, “Keys”, “Subkeys”, and “Values” (the actual data entities) are stored. It is easy to understand if you consider keys as directories and values as files.

The main root keys are classified into the following five:

HKEY_LOCAL_MACHINE (HKLM): Stores system settings and software settings that apply to the entire computer (all users). Administrator privileges are required to make changes.
HKEY_CURRENT_USER (HKCU): Stores specific settings for the currently logged-on user. Actually, this is not an independent database, but merely a symbolic link (alias) to the specific user’s SID (Security Identifier) key under HKEY_USERS.
HKEY_CLASSES_ROOT (HKCR): Stores file extension associations, COM (Component Object Model) class registration information, and shell extensions. This key is special; it is a virtual view created by the Configuration Manager merging HKLM\SOFTWARE\Classes (system-wide) and HKCU\Software\Classes (current user). In case of conflicts, user-specific settings (HKCU) take precedence.
HKEY_USERS (HKU): Stores settings for all user profiles on the system (those currently loaded in memory). It is structured based on SIDs.
HKEY_CURRENT_CONFIG (HKCC): Settings related to the current hardware profile. It is actually a link to HKLM\SYSTEM\CurrentControlSet\Hardware Profiles\Current.

Visualizing this complex hierarchical structure and relationship of links looks like the following:

mindmap
root(("Windows Registry"))
HKLM(("HKEY_LOCAL_MACHINE"))
SAM(("SAM (Security Accounts)"))
SECURITY(("SECURITY"))
SOFTWARE(("SOFTWARE"))
SYSTEM(("SYSTEM"))
HARDWARE(("HARDWARE (Volatile)"))
HKCU(("HKEY_CURRENT_USER (Link)"))
AppEvents(("AppEvents"))
Console(("Console"))
Software(("Software"))
System(("System"))
HKCR(("HKEY_CLASSES_ROOT (Merged View)"))
HKU(("HKEY_USERS"))
SID(("User SIDs..."))
HKCC(("HKEY_CURRENT_CONFIG (Link)"))

4. Registry Data Types (Detailed Explanation)

A strict data type is defined for each “value” in the registry. When manipulating the registry programmatically, it is essential to properly understand these types and write data in the appropriate type. Writing with an incorrect type can cause applications to throw exceptions or OS features to stop functioning.

REG_SZ (String Value): The most common data type. It stores a NULL-terminated Unicode string (UTF-16LE). Used for file paths, URLs, UI display names, etc.
REG_DWORD (32-bit Integer Value): A 32-bit (4-byte) unsigned integer value. Frequently used for boolean values (0=disabled, 1=enabled), timeout values in milliseconds, error code settings, etc. Because Windows uses a little-endian architecture, it is saved on disk starting from the least significant byte (e.g., 0x12345678 is saved as 78 56 34 12).
REG_QWORD (64-bit Integer Value): A 64-bit (8-byte) integer value. With the spread of 64-bit architecture, it is used to store huge numbers (such as disk quotas or large memory size specifications) and pointer-size settings.
REG_MULTI_SZ (Multi-String Value): A format that stores multiple NULL-terminated strings consecutively, terminated with an additional empty NULL-terminated character (double NULL) at the end. Suitable for storing array-like data, such as lists of IP addresses, lists of dependent services, and binding orders.
REG_EXPAND_SZ (Expandable String Value): A special string type that includes unexpanded environment variable strings like %USERPROFILE% or %SystemRoot%. When an application reads it through the RegQueryValueEx API, or by calling the ExpandEnvironmentStrings API, it is dynamically expanded to the actual absolute path by the OS.
REG_BINARY (Binary Value): Any raw binary data stream. It stores encrypted passwords (like LSA Secrets), digital certificates, and complex application-specific structures or serialized data.
REG_NONE: Data with an undefined type. Very rare, but used for reserved areas of encryption keys, etc.
REG_RESOURCE_LIST / REG_FULL_RESOURCE_DESCRIPTOR: Advanced types exclusively for the kernel, used by device drivers to record hardware resource allocation information (IRQs, I/O ports, DMA channels).

5. Mathematical Models and Performance of the Registry in the Operating System

Since the registry is directly linked to OS performance (especially boot time and process initialization speed), it is internally optimized using an advanced data structure similar to a B-Tree called “Cell Index”.

Search Time Complexity

The time complexity $T_{\text{search}}$ when searching for a specific key (path) in the registry depends on the depth of the tree and the number of nodes at each level. The computational complexity of searching a subkey of depth $d$ (e.g., $d=4$ for A\B\C\D) can theoretically be modeled as follows:

$$ T_{\text{search}}(d, L) = \sum_{i=1}^{d} O(\log(C_i) \cdot L_i) $$

Here, $C_i$ is the number of child nodes (subkeys or values) at depth $i$, and $L_i$ is the length of the string to be compared (number of characters). Within the hive files, which are the actual entities of the registry, the list of subkeys is maintained as an index sorted by name hashes or alphabetically. Therefore, instead of a simple linear search $O(C_i)$, a binary search $O(\log(C_i))$ is possible, achieving extremely fast access even if there are tens of thousands of subkeys under a single key.

Storage Footprint (Space Complexity)

The total size of the registry (the footprint on the physical disk) is calculated as the sum of each hive.

$$ \text{Size}_{\text{Total}} = \sum_{h \in \text{Hives}} \left( N_{h} \times S_{\text{key\_metadata}} + \sum_{v \in h} S_{\text{value}}(v) \right) + S_{\text{overhead}} $$

$N_h$ is the number of keys in hive $h$, $S_{\text{key\_metadata}}$ is the size of the metadata per key (last write timestamp, pointer to the security descriptor, pointer to the parent key, etc.), and $S_{\text{value}}(v)$ is the payload size of value $v$. It also includes the overhead $S_{\text{overhead}}$ from transaction logs and unnecessary empty cells (fragmentation). Leaving unnecessary data in the registry for a long period (such as remnants of incompletely uninstalled software) increases this footprint, potentially putting pressure on the OS paged pool memory and leading to performance degradation.

6. Risks and Corruption Probabilities of Manual Editing Threatening System Robustness

Manual editing using the Registry Editor (regedit.exe) should be considered a last resort for system administration. The registry does not have an “Undo” feature like common document editors, and changes to values or deletions of keys are immediately reflected in the system through the Configuration Manager.

In particular, if critical keys essential for system boot (e.g., disk controller driver settings under HKLM\SYSTEM\CurrentControlSet\Services, or the Userinit value in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon) are incorrectly edited or deleted by even a single character, there is a fatal risk of the OS crashing with a Blue Screen of Death (BSoD) and becoming unbootable, or getting stuck after the login screen (Black Screen).

Mathematical Model of Corruption Probability

Let’s consider the probability of system failure if registry keys are randomly modified or deleted. Let $C$ be the set of critical keys essential for the system to operate normally, and $N_c = |C|$ be its total number. Let the total number of keys in the entire registry be $N_{\text{total}}$.

If $k$ keys are randomly deleted or corrupted, the probability $P_{\text{failure}}$ that at least one critical key is corrupted is expressed by probability calculation of sampling without replacement as follows:

$$ P_{\text{failure}} = 1 - \frac{\binom{N_{\text{total}} - N_c}{k}}{\binom{N_{\text{total}}}{k}} = 1 - \prod_{i=0}^{k-1} \left( 1 - \frac{N_c}{N_{\text{total}} - i} \right) $$

The total number of keys in the entire registry $N_{\text{total}}$ is on the order of hundreds of thousands to millions, but $N_c$ is also on the order of tens of thousands. Mathematically, even with random operations, the failure probability rises sharply as $k$ increases. Furthermore, in real-world manual operations, users do not edit “randomly”; they intentionally manipulate areas directly related to system settings or software operations (often following tutorial sites), making the probability of touching critical keys much higher than the theoretical value above.

7. Registry Virtualization and the WOW64 Architecture

To maintain compatibility for legacy applications, Windows implements several advanced “virtualization (redirection)” mechanisms for registry access. Programming without understanding this can cause critical bugs.

UAC Registry Virtualization

Starting with Windows Vista, User Account Control (UAC) was introduced. When old applications created in the Windows XP era (running with standard user privileges) try to write to protected keys like HKLM\SOFTWARE that natively require administrator privileges, Windows silently redirects the write to a Virtual Store within the user profile: HKCU\Software\Classes\VirtualStore\MACHINE\SOFTWARE to prevent them from crashing with an Access Denied error. When reading, it also merges and returns data from both the original location and the virtual store. This allows applications to continue operating normally without detecting errors.

However, when developing tools that programmatically change system-wide settings, you must specify <requestedExecutionLevel level="requireAdministrator" /> in the manifest file to disable this virtualization.

WOW64 (Windows 32-bit on Windows 64-bit) Redirection

When running old 32-bit applications on a 64-bit version of Windows (currently the mainstream), specific registry keys are automatically isolated and redirected so that 32-bit apps do not accidentally overwrite 64-bit native system settings or load incompatible 64-bit DLLs.

For example, if a 32-bit app tries to access HKLM\SOFTWARE\Vendor\App, the OS transparently redirects it to HKLM\SOFTWARE\WOW6432Node\Vendor\App.

flowchart TD
App32["32-bit Application"]
App64["64-bit Application"]
RegAPI["Registry API (Advapi32.dll)"]
CM["Configuration Manager (Kernel)"]
HKLM_Soft["HKLM\SOFTWARE"]
HKLM_WOW64["HKLM\SOFTWARE\WOW6432Node"]
App32 -->| RegOpenKeyEx() | RegAPI
App64 -->| RegOpenKeyEx() | RegAPI
RegAPI --> CM
CM -->| If 64-bit Process | HKLM_Soft
CM -->| If 32-bit Process (Redirection) | HKLM_WOW64

When editing the registry from PowerShell scripts or C# applications, you must be keenly aware of whether the executing process itself is 32-bit or 64-bit. Otherwise, it will cause the troublesome issue of “settings that should have been written are not visible from Explorer (written to a different location).”

8. Programmable and Safe Editing with PowerShell

To minimize the risk of manually editing the registry, the modern best practice is to codify operations (Infrastructure as Code) using PowerShell scripts to ensure automation, reproducibility, and testability. PowerShell features a “Registry Provider,” allowing transparent manipulation of the registry using exactly the same cmdlets (like Get-ChildItem, Get-ItemProperty, New-Item) used to manipulate the file system (e.g., the C: drive).

In PowerShell, dedicated PSDrives (similar to drive letters) like HKLM: and HKCU: are mounted by default.

Basic CRUD Operations

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# 1. Check existence (Read)
$keyPath = "HKCU:\Software\MyCustomApp"
if (-Not (Test-Path -Path $keyPath)) {
 # 2. Create a new key (Create)
 New-Item -Path "HKCU:\Software" -Name "MyCustomApp" -Force | Out-Null
 Write-Host "Key created."
}

# 3. Write/Update value (Update) - Write 1 as REG_DWORD
Set-ItemProperty -Path $keyPath -Name "EnableDebug" -Value 1 -Type DWord

# 4. Read value (Read)
$debugFlag = (Get-ItemProperty -Path $keyPath).EnableDebug
Write-Host "Current debug flag: $debugFlag"

# 5. Delete value (Delete)
Remove-ItemProperty -Path $keyPath -Name "EnableDebug" -Force

Practical Example 1: Automatic Setup of Development Environment (Adding PATH to Environment Variables)

The following script is an automation example that safely adds a custom tool directory to the user environment variable PATH when a developer sets up a new Windows machine.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


$envKey = "HKCU:\Environment"
$newPath = "C:\tools\bin"

# Read the current PATH (suppress errors for safe retrieval)
$currentPathInfo = Get-ItemProperty -Path $envKey -Name "Path" -ErrorAction SilentlyContinue
$currentPath = if ($currentPathInfo) { $currentPathInfo.Path } else { "" }

# Use regular expressions to check if it is already included
if ($currentPath -notmatch [regex]::Escape($newPath)) {
 # Append a semicolon if not present at the end and concatenate
 if ($currentPath -and $currentPath -notmatch ";$") {
 $currentPath += ";"
 }
 $updatedPath = $currentPath + $newPath

 # Write as REG_EXPAND_SZ type (important)
 Set-ItemProperty -Path $envKey -Name "Path" -Value $updatedPath -Type ExpandString
 Write-Host "Updated PATH environment variable: $newPath"

 # Notify running processes of environment variable changes (WM_SETTINGCHANGE)
 # This applies it to new Explorer windows, etc., without requiring a reboot
 [Environment]::SetEnvironmentVariable("Path", $updatedPath, [EnvironmentVariableTarget]::User)
} else {
 Write-Host "PATH is already added."
}

This is a script that adds a custom item called “Open with My IDE” to the context menu when right-clicking a specific file or directory.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


# Menu when right-clicking the directory background (blank space)
$menuPath = "HKCR:\Directory\Background\shell\OpenWithMyIDE"
$commandPath = "$menuPath\command"

try {
 # Create parent key for the menu item
 New-Item -Path $menuPath -Force -ErrorAction Stop | Out-Null

 # Set the display name in the (default) value
 Set-ItemProperty -Path $menuPath -Name "(default)" -Value "Open with My IDE" -Type String

 # Set icon (optional)
 Set-ItemProperty -Path $menuPath -Name "Icon" -Value "C:\Program Files\MyIDE\ide.exe,0" -Type String

 # Create command subkey and set the command line to be executed
 # %V is a variable expanded to the current directory path
 New-Item -Path $commandPath -Force -ErrorAction Stop | Out-Null
 Set-ItemProperty -Path $commandPath -Name "(default)" -Value "`"C:\Program Files\MyIDE\ide.exe`" `"%V`"" -Type String

 Write-Host "Context menu added."
} catch {
 Write-Error "Failed to modify the registry. Make sure you are running as administrator. Error: $_"
}

Internal Sequence of Registry Access from PowerShell

The operational sequence inside the OS when a PowerShell script modifies the registry is shown below.

sequenceDiagram
participant U as "Admin / PowerShell"
participant PS as "Registry Provider (.NET)"
participant CM as "Configuration Manager (Kernel)"
participant Disk as "Hive Files on NTFS"
U->>PS: "Set-ItemProperty -Path ... -Value ..."
PS->>PS: "Parse Path & Validate Data Types"
PS->>CM: "NtSetValueKey (System Call)"
CM->>CM: "Check Access Token against Key ACL"
alt "Access Granted (Admin Token)"
CM->>CM: "Allocate Cell in Volatile Cache"
CM->>Disk: "Flush to Transaction Log (.log1)"
Disk-->>CM: "Log Written Successfully"
CM->>Disk: "Lazy Write to Hive Data File (Background)"
CM-->>PS: "STATUS_SUCCESS (0x00000000)"
PS-->>U: "Command Completed"
else "Access Denied (Standard User)"
CM-->>PS: "STATUS_ACCESS_DENIED (0xC0000022)"
PS-->>U: "UnauthorizedAccessException Thrown"
end

9. Robust Registry Access with C# (.NET)

When accessing the registry from a .NET application (such as C#), use the Microsoft.Win32.Registry and RegistryKey classes. The greatest advantage of using C# is the capability for robust error handling via powerful exception handling (try-catch), strict type checking, and explicit specification of 32-bit/64-bit views using the RegistryView enumeration.

Below is an example of C# code that reliably reads and writes to the 64-bit registry (bypassing WOW6432Node redirection) in a 64-bit OS environment.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54


using System;
using System.Security;
using Microsoft.Win32;

class RegistryEditor
{
 static void Main()
 {
 // Path under HKLM (Requires administrator privileges)
 string keyPath = @"SOFTWARE\MyEnterpriseApp\Settings";

 // Specify RegistryView.Registry64 to open a 64-bit native view
 // Use a using statement to reliably Dispose of the registry key handle (unmanaged resource)
 try
 {
 using (RegistryKey baseKey = RegistryKey.OpenBaseKey(RegistryHive.LocalMachine, RegistryView.Registry64))
 {
 // Open key with write permission (writable: true). Create if it doesn't exist.
 using (RegistryKey subKey = baseKey.CreateSubKey(keyPath, writable: true))
 {
 if (subKey != null)
 {
 // Write value as REG_DWORD
 subKey.SetValue("MaxConnections", 100, RegistryValueKind.DWord);

 // Write value as REG_SZ
 subKey.SetValue("ApiEndpoint", "https://api.example.com", RegistryValueKind.String);

 // Write byte array as REG_BINARY
 byte[] secretData = { 0x01, 0x02, 0x0A, 0xFF };
 subKey.SetValue("BinarySecret", secretData, RegistryValueKind.Binary);

 Console.WriteLine("Successfully wrote to the registry.");
 }
 }
 }
 }
 catch (UnauthorizedAccessException ex)
 {
 // Commonly occurs when not running as administrator
 Console.WriteLine($"Permission error: Please \"Run as administrator\". Details: {ex.Message}");
 }
 catch (SecurityException ex)
 {
 // If blocked by .NET Code Access Security (CAS)
 Console.WriteLine($"Security exception: {ex.Message}");
 }
 catch (Exception ex)
 {
 // Other unexpected IO errors, etc.
 Console.WriteLine($"Unexpected error: {ex.Message}");
 }
 }
}

The “handle” returned by the OS when opening a registry key is an unmanaged resource that consumes memory and system resources. Therefore, an ironclad rule in C# programming is to reliably prevent handle leaks by either using a using block or explicitly calling .Dispose() (or .Close()) within a finally block.

10. Registry Backup and Restore Methods

Even with automation via scripts or programs, it is absolutely essential to take a backup before making critical changes.

Backup and Import using .reg Files

The most classical and versatile method is exporting to a .reg file. This is a text-based file with its own format, and its structure is as follows:

1
2
3
4
5
6


Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\MyCustomApp]
"EnableDebug"=dword:00000001
"ApiEndpoint"="https://api.example.com"
"BinaryData"=hex:01,02,0a,ff

Note: Binary data is represented by comma-separated hexadecimal numbers following hex:.

You can implement automatic backups in batch scripts using the command-line tool reg.exe.

1
2
3
4
5


REM Backup specified key (subkeys are also exported recursively)
reg export HKLM\SOFTWARE\MyEnterpriseApp C:\backup\myapp_backup.reg /y

REM Restore backup
reg import C:\backup\myapp_backup.reg

More Advanced Backup Methods Using PowerShell

Instead of just text, you can leverage PowerShell’s object orientation to export registry objects and save them in XML format (CliXML). This allows you to handle them while maintaining type information during restoration, without relying on string parsing.

1
2
3
4
5
6
7


# Take backup (Save properties as XML)
Get-ItemProperty -Path "HKCU:\Software\MyCustomApp" | Export-Clixml -Path "C:\backup\reg_backup.xml"

# Concept of restoring
$backup = Import-Clixml -Path "C:\backup\reg_backup.xml"
# Because $backup contains restored custom PSObjects,
# you can build logic to loop through its properties and reapply them with Set-ItemProperty.

11. Troubleshooting Using Sysinternals Process Monitor (Procmon)

If it’s unclear where a program is writing in the registry, or if you want to find the cause of an “Access Denied” error, the Process Monitor (Procmon)—a free Sysinternals tool provided by Microsoft—is extremely powerful. By using Procmon, you can capture all registry API calls (RegOpenKey, RegQueryValue, RegSetValue, etc.) occurring on the OS in real-time and troubleshoot with advanced filtering such as the following:

Process Name is powershell.exe
Operation begins with Reg
Result is ACCESS DENIED

With this, you can instantly pinpoint which key lacks ACL settings, or whether it’s being mistakenly redirected to the WOW6432Node.

12. Security and Best Practices

Finally, we summarize the important design principles and best practices for handling the registry.

Strictly Enforce the Principle of Least Privilege: Application and script settings should be stored under the Software key within HKCU (Current User) whenever possible. Writing to HKLM requires an administrator privilege escalation via UAC, which expands the security attack surface and degrades user experience.
Enable Auditing: For keys that are extremely critical to security (e.g., the Run key responsible for automatic startup, or service configuration keys), configure a SACL (System Access Control List) to record (audit) who modified or deleted values and when, in the Windows Event Viewer’s “Security Log”.
Address the Deprecation of Transaction Features: The registry transaction feature (TxR) utilizing the “Kernel Transaction Manager (KTM)”, introduced back in Windows Vista, has been deprecated since Windows 10. The application side must implement its own backup and rollback mechanisms (such as reading the original value and keeping it in memory before making changes).
Beware of Conflicts with Group Policy (GPO): The HKLM\SOFTWARE\Policies and HKCU\Software\Policies areas are to be centrally managed by Active Directory Group Policies. Even if you modify these keys directly from a script, they will be forcefully overwritten by the Domain Controller’s settings during the next background Group Policy update cycle (typically every 90 to 120 minutes), causing your settings to not persist.

Conclusion

The Windows Registry is a powerful and complex foundational system that integrally manages every behavior of the OS and application settings. Disorderly manual editing carries a high, mathematically proven risk of system corruption. Therefore, using programmable means such as PowerShell and C# to manage configurations securely, testably, and reproducibly, in accordance with the principles of Infrastructure as Code, is essential in modern system administration and development. Utilize the deep architectural understanding and implementation patterns explained in this article to aim for building a more robust and secure Windows environment.

Windows 11 on kenji.blog

How to Create MSIX Packages for Windows 11 and the Self-Signed Certificate Trap

1. What is MSIX? Comparison with Traditional MSI/EXE

Issues with Traditional Installers (MSI/EXE)

Solutions through MSIX Containerization Architecture

2. Overview of MSIX Package Creation and Toolchain

3. Approach A: Creating MSIX using Visual Studio

Step-by-Step Guide

4. Approach B: Creating using the Command Line (MakeAppx.exe)

1. Preparing the Manifest File

2. Packaging with MakeAppx

5. Mathematical Background of Digital Signatures and Cryptography

Application of Hash Functions

Generation of the Signature (Publisher)

Verification of the Signature (Windows OS)

6. The Biggest Barrier: “The Self-Signed Certificate Trap”

7. Solution: Creating and Deploying a Self-Signed Certificate using PowerShell

Step 1: Creating and Exporting a Self-Signed Certificate

Step 2: Installing the Certificate on Client PCs (Disarming the Trap)

8. Enterprise Environment Operations and Best Practices

1. Utilizing Active Directory Group Policy (GPO)

2. Deployment via Microsoft Intune (MDM)

3. Automatic Updates via App Installer Files (.appinstaller)

9. Troubleshooting: Common Certificate-Related Errors

10. Conclusion

Basic Knowledge of the Windows Registry and Safe Programmable Editing Methods

Basic Knowledge of the Windows Registry and Safe Programmable Editing Methods

1. Introduction: History and Evolution of the Windows Registry

2. Deep Dive into the Architecture: The Reality of Registry Hives and Memory Mapping

3. Hierarchical Structure of Registry Keys and Values

4. Registry Data Types (Detailed Explanation)

5. Mathematical Models and Performance of the Registry in the Operating System

Search Time Complexity

Storage Footprint (Space Complexity)

6. Risks and Corruption Probabilities of Manual Editing Threatening System Robustness

Mathematical Model of Corruption Probability

7. Registry Virtualization and the WOW64 Architecture

UAC Registry Virtualization

WOW64 (Windows 32-bit on Windows 64-bit) Redirection

8. Programmable and Safe Editing with PowerShell

Basic CRUD Operations

Practical Example 1: Automatic Setup of Development Environment (Adding PATH to Environment Variables)

Practical Example 2: Adding Custom Actions to the Context Menu

Internal Sequence of Registry Access from PowerShell

9. Robust Registry Access with C# (.NET)

10. Registry Backup and Restore Methods

Backup and Import using .reg Files

More Advanced Backup Methods Using PowerShell

11. Troubleshooting Using Sysinternals Process Monitor (Procmon)

12. Security and Best Practices

Conclusion