01 / SYMPTOM

The executable worked, but Windows did not recognise it as an application

The log viewer was supplied as a portable executable without an installer. It could be launched directly and could open log files, but it was not registered with Windows.

As a result, the application could not be reliably assigned as the default handler for .log files through the existing default-association policy.

02 / EVIDENCE

The application had no Windows registration

There was no application entry under:

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Applications

Windows therefore had no registered open command or application ProgID that could be referenced in the default-association XML.

The domain policy for default application associations was already configured, but the XML file referenced by the policy did not contain an association for .log files.

03 / FAILED APPROACH

A user-level selection was not suitable for a non-persistent image

Selecting the executable through Open with created association data only for the packaging account.

That configuration depended on the user profile and could not be relied on for users signing in to non-persistent VDIs. Directly modifying the UserChoice registry key was also unsuitable because Windows protects that value with a validation hash.

The association needed to be provided at the machine and policy level.

04 / FIX

Register the portable executable with Windows

The executable was copied into the application layer:

C:\Program Files\PortableLogViewer\LogViewer.exe

The following application registration was then created:

HKEY_LOCAL_MACHINE
  \SOFTWARE
    \Classes
      \Applications
        \LogViewer.exe
          \shell
            \open
              \command

The default value of the command key was set to:

"C:\Program Files\PortableLogViewer\LogViewer.exe" "%1"

This registered the executable as a Windows application and created the following ProgID:

Applications\LogViewer.exe

Export the Windows default associations

After selecting the registered application for a test.log file on the packaging machine, the current default associations were exported:

Dism /Online /Export-DefaultAppAssociations:C:\ProgramData\PortableLogViewer\DefaultAssociations.xml

The exported XML contained all current Windows associations. It was reduced to the required .log entry:

<DefaultAssociations>
  <Association
    Identifier=".log"
    ProgId="Applications\LogViewer.exe"
    ApplicationName="Log Viewer" />
</DefaultAssociations>

The XML was saved in the application layer at the path referenced by the existing domain policy.

The policy was configured under:

Computer Configuration
  > Administrative Templates
    > Windows Components
      > File Explorer
        > Set a default associations configuration file

No change to the domain policy itself was required.

05 / VALIDATION

Validation was completed on a published VDI

The packaging machine did not receive the domain policy, so the final association could not be validated there.

After publishing the updated application layer, we:

  1. Confirmed that the portable executable existed on the VDI.
  2. Confirmed that the default-association XML existed at the policy-defined path.
  3. Confirmed that the domain policy applied successfully.
  4. Signed in with a test user.
  5. Opened a .log file and confirmed that it launched in the log viewer.
  6. Repeated the test across subsequent user logins.

A one-time application confirmation appeared during initial testing. After the application was selected, subsequent launches and later logins opened .log files without further prompts.

06

LESSON

Portable applications still require Windows registration

A portable executable can run without installation, but Windows still requires an application registration and a valid ProgID before it can be used reliably in a default-association XML.

For non-persistent VDIs, the machine-level application registration and policy-controlled XML are to be preferred.