Forum Discussion
CfExecute(TRANSFER_PLACEHOLDERS) returns E_INVALIDARG inside an FSLogix profile container
We develop a Cloud Files sync provider. When the sync root lives in a user profile that FSLogix redirects to a per-user VHDX container, some FETCH_PLACEHOLDERS callbacks cannot be answered: every CfExecute(CF_OPERATION_TYPE_TRANSFER_PLACEHOLDERS) for them fails with E_INVALIDARG (0x80070057), including the error completion. The request stays pending until the platform cancels it after about 60 s, and the application that triggered it (File Explorer, Office and Edge background processes, line-of-business apps) hangs for that time.
The callback is raised by a name lookup of a non-existent child (`CreateFileW` / `GetFileAttributesExW` on `<dir>\missing.txt`) inside a placeholder directory with on-demand population enabled, and nobody has had that directory open for about one to two minutes. The same callback raised by a directory enumeration is answered fine every time. A lookup on a directory opened a few seconds earlier is fine too.
A standalone PowerShell script (own throwaway sync root, no third-party software) reproduces it on a clean Windows Server 2022 (20348.5761, October 2026 CU) with FSLogix 26.08 (3.26.826.17182) for a user with a profile container. The same script on the same server, ten minutes later, as a local user in the "FSLogix Profile Exclude List": all answers accepted. Also reproduced on Windows Server 2022 20348.3328 and 20348.5622 and on Windows Server 2025 26100.1742 with profile containers; not reproducible on the same builds without FSLogix, with a sync root on a plain VHDX volume or a mount point, or on Windows 11. The OS patch level and the FSLogix release did not make a difference in our tests.
Waiting, an attributes-only open of the directory, or omitting the correlation vector, request key and sync status from CF_OPERATION_INFO do not help.
If the provider opens the directory with FILE_LIST_DIRECTORY (and may close it again) before answering, or after the rejection and then resends the byte-identical answer, CfExecute returns S_OK. CfUpdatePlaceholder(DISABLE_ON_DEMAND_POPULATION) on the directory has the same effect. We ship the directory open as a workaround.
Is this a known issue for a Cloud Files sync root inside an FSLogix-redirected profile?
Script and both logs (reproduced / not reproduced, same server): https://gist.github.com/pdupont1/85cc0b4a708a784db03087bdcdbe74c8
Full write-up with the environment matrix and all tested variants on https://learn.microsoft.com/en-us/answers/questions/6039901/cfexecute-transfer-placeholders-returns-e-invalida
1 Reply
Your same-server comparison and byte-identical retry succeeding after a directory open make this more specific than a generic invalid-parameter report. They suggest an interaction involving the redirected profile and directory population state, but do not establish a confirmed Microsoft defect or identify which component is responsible. Keep your minimal reproduction and environment matrix as the primary evidence. As a final API-contract check, verify the operation-specific ParamSize, callback connection and transfer identifiers, placeholder counts and completion status against the Cloud Files documentation. Then collect FSLogix support data from both failing and excluded-user runs, preserving matching timestamps and the successful enumeration comparison. Open a Microsoft support case requesting investigation across FSLogix and Cloud Files rather than repeating OS reinstalls. Describe your FILE_LIST_DIRECTORY workaround as an observed mitigation, not a documented requirement. Retain it only with your own regression coverage while seeking an official support determination.
