Native TSF IME pure MSIX deployment

Hi @Maung Kaung ,

Thank you for publishing the complete minimal reproduction. I downloaded the supplied source and manifest and compared them with my successful packaged test.

Comparison result

I rebuilt the probe as an x64 C++ executable without changing the TSF registration logic. The only manifest changes required for my environment were:

• Publisher was changed to match my local test certificate.
• Logo paths were changed from Assets\... to the packaging project’s existing Images\... files.

I did not add windows.comServer, classicAppCompat, desktop7:Scope, an IME DLL, or additional capabilities.

My environment was:

• Windows 11 Enterprise 25H2
• OS build 26200.9168
• x64
• Hyper-V virtual machine

The unpackaged executable returned:

CoInitializeEx=0x00000000
CoCreateInstance=0x00000000
Register=0x00000000

The package built from the supplied source and equivalent manifest, launched through package activation and from the Start menu, also returned:

CoInitializeEx=0x00000000
CoCreateInstance=0x00000000
Register=0x00000000

Therefore, I could not reproduce 0x80004005 from the supplied source, package identity, or OS build alone. This result does not prove that the uploaded MSIX succeeds, because my package was rebuilt and signed locally rather than being the exact uploaded artifact.

Exact uploaded MSIX

I also attempted to install the uploaded TsfMinimalProbe-x64.msix, but installation stopped with:

0x800B010A
This app package's publisher certificate could not be verified.
The root certificate and all intermediate certificates of the
signature in the app package must be verified.

I have not treated this certificate error as the cause of the TSF failure. It only prevents testing the exact package on my VM.

If you want me to test the exact uploaded MSIX without rebuilding or re-signing it, please provide the public .cer signing certificate and any required public intermediate certificates. Do not provide a .pfx, private key, or password.

Highest-priority comparison

One remaining difference worth checking is the effective process context. A packaged full-trust desktop application normally runs at medium integrity, and MSIX can apply file-system and registry redirection or virtualization.

msix-containerization-overview

This does not establish that permissions or registry virtualization caused E_FAIL, but it provides two immediate tests:

1. Run the unpackaged probe from a normal, non-elevated Command Prompt.
2. Run the packaged probe under the same user account and compare the results.

Please record the following for both processes:

whoami /user
whoami /groups

Also confirm whether either executable was launched using Run as administrator, from an elevated Visual Studio instance, or by an elevated script.

If the unpackaged probe succeeds only when elevated, the difference is likely related to process context rather than package identity itself. If both unpackaged runs succeed but only the packaged run fails, capture a narrow ProcMon trace:

1. Filter Process Name to the probe executable.
2. Start capture immediately before ITfInputProcessorProfiles::Register.
3. Stop capture immediately after the call returns.
4. Include registry and file-system operations.
5. Highlight ACCESS DENIED, REPARSE, NAME NOT FOUND, and other failures.
6. Compare the packaged trace with an unpackaged, non-elevated trace.

Microsoft documents E_FAIL from ITfInputProcessorProfiles::Register only as an unspecified error, so the HRESULT alone does not identify the underlying failing operation.

nf-msctf-itfinputprocessorprofiles-register

Hi Tony,

I completed the non-elevated vs elevated comparison using the same unpackaged probe.

Non-elevated PowerShell: CoInitializeEx = S_OK CoCreateInstance = S_OK ITfInputProcessorProfiles::Register = 0x80004005 Exit code = 1

Elevated Administrator PowerShell: CoInitializeEx = S_OK CoCreateInstance = S_OK ITfInputProcessorProfiles::Register = S_OK Exit code = 0

So on my machine, the same unpackaged executable succeeds only when elevated. This strongly suggests the failure is related to process context, permissions, or registry/file-system state rather than MSIX package identity alone.

I will next capture paired ProcMon traces for the non-elevated failing run and the elevated successful run.

Hi Tony,

I completed the ProcMon comparison.

In the non-elevated run, ITfInputProcessorProfiles::Register attempts:

RegCreateKey HKLM\SOFTWARE\Microsoft\CTF\TIP\{7A0C45B1-3E89-4F7B-A142-918765CC3310}

and ProcMon reports:

ACCESS DENIED

In the elevated run, the same RegCreateKey operation returns:

SUCCESS

and Register() returns S_OK.

I also checked the ACL on:

HKLM\SOFTWARE\Microsoft\CTF\TIP

Relevant entries are:

BUILTIN\Users → ReadKey

BUILTIN\Administrators → FullControl

NT AUTHORITY\SYSTEM → FullControl

ALL APPLICATION PACKAGES → ReadKey

I have not modified these ACLs.

Could you please compare the ACL and ProcMon behavior on your VM where the packaged probe succeeds? In particular, I would like to know whether your successful packaged process writes directly to the physical HKLM TSF key or whether registry redirection/virtualization or another process-context difference is involved.

Thank you.

Hi @Maung Kaung ,

Thank you for running the controlled elevation test. The same unpackaged executable returning 0x80004005 non-elevated and S_OK elevated confirms that the determining variable is the process token, not MSIX package identity — runFullTrust does not grant administrator privileges. The HRESULT alone doesn't identify the blocked operation, since Microsoft documents E_FAIL here only as an unspecified error, so I'll follow up once the ProcMon trace pinpoints it. msix-containerization-overview

Hi @Maung Kaung ,

Thank you for the ProcMon comparison. This confirms the root cause.

Confirmed result

ITfInputProcessorProfiles::Register attempts to create:

HKLM\SOFTWARE\Microsoft\CTF\TIP\{7A0C45B1-3E89-4F7B-A142-918765CC3310}

• Non-elevated: ACCESS DENIED, then Register = 0x80004005
• Elevated: SUCCESS, then Register = S_OK

Therefore, the determining factor on your machine is the process token and access to the protected HKLM key, not MSIX package identity. runFullTrust does not grant administrator privileges.

Manifest conclusion

No MSIX manifest change resolves this runtime permission requirement:

• windows.comServer declares packaged COM registration.
• classicAppCompat and Scope affect applicable manifest registrations.
• None of these settings grants permission to write machine-level TSF state or elevates first-run code.

Do not modify the CTF/TIP ACL, disable UAC, or grant standard users write access to HKLM.

Recommended deployment model

Use an elevated MSI/EXE installer to:

1. Register the COM in-process server.
2. Register the TSF service, language profile, and categories.
3. Call InstallLayoutOrTip.
4. Reverse these operations during uninstall.

The IME DLL should perform input processing only and should not self-register at startup.

For Microsoft Store distribution, submit the signed MSI/EXE installer through Partner Center. A UAC prompt is permitted for this distribution model.

My clean-VM probe returning S_OK shows that machine state can affect the behavior. However, because non-elevated TSF registration cannot be relied upon across customer machines, pure MSIX is not a dependable deployment model for this native IME. The elevated-installer model is the appropriate solution.

If this instruction is applicable to your situation, I would greatly appreciate it if you could follow the instruction here so others experiencing similar behavior can benefit from it as well.