On ProfileUnity Client 6.9.5 HF2 with ProfileDisk enabled, the Windows Start Menu does not open for a user whose ProfileDisk has just been created. Search and some other packaged Windows components may also fail to start. Earlier releases, including 6.9.5 GA and 6.9.5 HF1, are not affected, and an existing ProfileDisk that already holds a populated profile is not affected. This article describes the symptoms, how to confirm you are seeing this issue, and an interim workaround you can deploy until 6.9.5 HF3 is available.
📄 Contents
Status
| Issue Status | FIX IN PROGRESS |
| Fix Version | 6.9.5 HF3, when released |
| Workaround Available | Yes. See Interim Workaround › |
The issue is reproducible and understood. It affects the first logon to a newly created ProfileDisk, which makes it visible when onboarding a new user, when a ProfileDisk is replaced, and in any test that deletes a ProfileDisk to start clean.
Affected Configurations
All of the following must be true for the issue to occur.
| Component | Condition |
|---|---|
| ProfileUnity Client | 6.9.5 HF2 |
| ProfileDisk | Enabled and assigned to the user |
|
ProfileDisk state the determining condition |
Newly created. This includes a first logon for a new user, a ProfileDisk that was deleted and recreated, and a ProfileDisk replaced after corruption. |
| Windows | Any edition where the Start Menu is a packaged application, which includes Windows 10 and Windows 11 |
Symptoms
- The Start Menu does not open when clicked, or opens and immediately closes.
- Taskbar Search does not open, and may crash repeatedly.
- Other packaged Windows applications fail to start.
- A black screen may appear briefly at logon before the desktop loads.
- The desktop, File Explorer and conventional desktop applications work normally.
The condition persists for that user on every subsequent logon until it is corrected, because the application state Windows failed to create is never created on a later attempt on its own.
Cause
In 6.9.5 HF2 the ProfileDisk volume is attached with a security descriptor that
does not
grant the signed-in user permission to modify object permissions, the access
right
Windows refers to as
WRITE_DAC.
The user still has read and write access to their files, so the profile itself
loads and
ordinary applications behave normally.
Windows sets permissions on per-user packaged-application state at the moment it first creates that state. On a newly created ProfileDisk that state does not exist yet, so Windows attempts to create it and set permissions on it, and the permission step is denied. Registration of the affected packages is abandoned. The Start Menu is therefore left with no state store to start from.
An existing ProfileDisk already holds that state with its permissions in place, so nothing needs to be changed and the same client version works normally. This is why the issue is only visible on a new or recreated ProfileDisk.
How to Confirm
Run both checks in the affected user's session.
Check 1 — Look for application deployment failures
In a PowerShell window, run:
Get-WinEvent -LogName 'Microsoft-Windows-AppXDeploymentServer/Operational' -MaxEvents 200 |
Where-Object { $_.LevelDisplayName -in 'Error','Warning' } |
Select-Object TimeCreated, Id, Message | Format-List
On an affected session this returns repeated entries reading
Failed to set access rights to LocalState,
Creation of the application data local root folder failed
and
Windows cannot create the AppContainer profile,
each with error
0x80070005.
Check 2 — Compare registered packages against their state folders
In the same window, run:
# packages Windows believes are registered for this user (Get-AppxPackage).Count # package state folders that actually exist in the profile (Get-ChildItem "$env:LOCALAPPDATA\Packages" -Directory).Count
On an affected session the first number is in the dozens while the second is very low, often only one or two. On a healthy session the two are comparable.
Interim Workaround
The script attached to this article grants the signed-in user full control of their own ProfileDisk volume, which allows Windows to finish creating the application state it needs. Deploy it with an Application Launcher rule so it runs once per session. Affected users are corrected at their next logon, and new users and recreated ProfileDisks are corrected as they are created.
The script acts only on the ProfileDisk belonging to the account that runs it. It makes no change to FlexApp package volumes, to any other user's ProfileDisk, or to the operating system volume, and it writes no data to the ProfileDisk itself.
Step 1 — Stage the script on a network share
Download
Fix-ProfileDiskVolumeDacl.ps1
from this article and place it on a share that every affected user can read.
The
NETLOGON share is a convenient choice, because it already meets that requirement
and is
where ProfileUnity configuration files are commonly deployed. For example:
\\domain.local\NETLOGON\ProfileUnity\Fix-ProfileDiskVolumeDacl.ps1
Substitute your own domain and path, and use the same value in Step 2. Staging centrally means the script can be updated or withdrawn in one place rather than per image.
Step 2 — Create an Application Launcher rule
In your configuration, add an Application Launcher rule that runs the script at logon, using the earliest timing available to you:
powershell.exe -NoProfile -NonInteractive -ExecutionPolicy Bypass -File "\\domain.local\NETLOGON\ProfileUnity\Fix-ProfileDiskVolumeDacl.ps1"
Filter the rule to the users or machines that use ProfileDisk. The exact timing within logon is not important, because the correction takes effect even if it is applied after the desktop has loaded.
Step 3 — Log on and confirm the result
Log on as an affected user and review the script log:
%ProgramData%\Liquidware\PdDaclFix\PdDaclFix.log
A successful run ends with
PATCHED,
or with
already patched
on later logons in the same session. Any line beginning
ABORT
states the reason and means no change was made. An
ABORT: token is not elevated
line indicates the script was not launched the way this article describes,
since
Application Launcher rules run elevated in the user's context.
| Product | ProfileUnity |
| Applies To | ProfileUnity Client 6.9.5 HF2 with ProfileDisk |
| Updated | September 1, 2026 |