Heap Corruption after using CfUpdatePlaceholder

Question

Heap Corruption after using CfUpdatePlaceholder

Jöran Malek 96

I can reliably crash .NET and C++ packaged applications (MSIX) on Windows 11 24H2 with Heap Corruptions, when updating Cloud Filter mini-driver placeholder files using CfUpdatePlaceholder.

Repro: https://github.com/iterate-ch/CloudFiles-HeapCorrupt The application will never actually complete the 300 placeholder updates, and sometime crash with heap corruption inside the loop:

Ausnahmefehler bei 0x00007FFA2DE9DA95 (ntdll.dll) in SyncApp.exe: 0xC0000374: Ein Heap wurde beschädigt (Parameter: 0x00007FFA2DFCB0E0)

This does not happen on Windows 11 23H2.

Please let me know, what I have to do to get this fixed.

Minxin Yu 13,506 Reputation points Microsoft External Staff

2024-11-19T07:44:03.66+00:00

I am able to reproduce the problem on Win11 24H2.
As this issue is complex, if you want to resolve this issue as soon as possible, you can open an incident via Contact us tab at link below: https://developer.microsoft.com/en-us/windows/support/

Please choose the Technical Support - Coding/Debugging for Windows SDK for this issue. In-addition, if the support engineer determines that the issue is the result of a bug the service request will be a no-charge case and you won't be charged.
Jöran Malek 96 Reputation points

2024-11-19T10:22:18.2733333+00:00
So, I've did more testing, and it looks like what previously worked (handing over a Win32 handle of a not exlusively opened OpLock handle) doesn't work anymore - basically

CfOpenFileWithOplock(file.wstring().c_str(), CF_OPEN_FILE_FLAG_EXCLUSIVE, handle.put()) CfUpdatePlaceholder(handle.get())

without going through all of the protected handle stuff.

I've previously not used an exclusive handle, which works on 23H2, and previous versions, due to this documentation comment:

In the case of a file, the caller must acquire an exclusive handle to the file if it also intends to dehydrate the file at the same time or data corruption can occur.

Which I assumed meant that to update metadata, there's no need to use an exclusive oplock handle. However, this seems to be enforced on 24H2, or an implementation error in CldApi.
Emil Kalchev 0 Reputation points

2025-02-27T08:50:25.1766667+00:00

We suffer from the same issue. Microsoft any words on that?

sysadmin 40

We are experiencing the same issue:


                CfOpenFileWithOplock(filePath, CF_OPEN_FILE_FLAGS.CF_OPEN_FILE_FLAG_EXCLUSIVE, out var protectedHandle).ThrowIfFailed();

                using (protectedHandle)
                {
                    CfUpdatePlaceholder(protectedHandle.DangerousGetHandle(),
                        FileIdentityLength: 0,
                        DehydrateRangeCount: 0,
                        UpdateFlags: CF_UPDATE_FLAGS.CF_UPDATE_FLAG_ENABLE_ON_DEMAND_POPULATION,
                        UpdateUsn: usn).ThrowIfFailed();
                }

Heap corruption in 25h2, worked in 22h2

Your answer

Minxin Yu 13,506 Reputation points Microsoft External Staff

2024-11-19T07:44:03.66+00:00

I am able to reproduce the problem on Win11 24H2.
As this issue is complex, if you want to resolve this issue as soon as possible, you can open an incident via Contact us tab at link below: https://developer.microsoft.com/en-us/windows/support/

Please choose the Technical Support - Coding/Debugging for Windows SDK for this issue. In-addition, if the support engineer determines that the issue is the result of a bug the service request will be a no-charge case and you won't be charged.
Jöran Malek 96 Reputation points

2024-11-19T10:22:18.2733333+00:00

So, I've did more testing, and it looks like what previously worked (handing over a Win32 handle of a not exlusively opened OpLock handle) doesn't work anymore - basically

CfOpenFileWithOplock(file.wstring().c_str(), CF_OPEN_FILE_FLAG_EXCLUSIVE, handle.put()) CfUpdatePlaceholder(handle.get())

without going through all of the protected handle stuff.

I've previously not used an exclusive handle, which works on 23H2, and previous versions, due to this documentation comment:

In the case of a file, the caller must acquire an exclusive handle to the file if it also intends to dehydrate the file at the same time or data corruption can occur.

Which I assumed meant that to update metadata, there's no need to use an exclusive oplock handle. However, this seems to be enforced on 24H2, or an implementation error in CldApi.
Emil Kalchev 0 Reputation points

2025-02-27T08:50:25.1766667+00:00

We suffer from the same issue. Microsoft any words on that?
sysadmin 40 Reputation points

2025-11-18T04:52:40.0633333+00:00

We are experiencing the same issue:

CfOpenFileWithOplock(filePath, CF_OPEN_FILE_FLAGS.CF_OPEN_FILE_FLAG_EXCLUSIVE, out var protectedHandle).ThrowIfFailed(); using (protectedHandle) { CfUpdatePlaceholder(protectedHandle.DangerousGetHandle(), FileIdentityLength: 0, DehydrateRangeCount: 0, UpdateFlags: CF_UPDATE_FLAGS.CF_UPDATE_FLAG_ENABLE_ON_DEMAND_POPULATION, UpdateUsn: usn).ThrowIfFailed(); }

Heap corruption in 25h2, worked in 22h2

Share via

Heap Corruption after using CfUpdatePlaceholder

Your answer