microsoft / microsoft/microsoft-ui-xaml

`CCoreServices::TryLoadXamlResourceHelper` inadvertently frees the loaded XAML before returning it

Open
#11,058 2 comments 0 reactions 0 assignees View on GitHub
area-Lifetime area-Resources bug team-Core
Dominant language
C++
Stars
8.4k
Forks
942
Avg merge
2d 7h
Merged PRs (30d)
105

Description

### Describe the bug

https://github.com/microsoft/microsoft-ui-xaml/blob/main/src/dxaml/xcp/core/dll/xcpcore.cpp#L3069-L3076 is intended to detach the ownership of the IPALMemory in order to return it to the caller. However, https://github.com/microsoft/microsoft-ui-xaml/blob/main/src/dxaml/xcp/core/dll/xcpcore.cpp#L3046-L3048 means it is still owned by the IPALResource, and when `spResource` goes out of scope the memory is destroyed (m_embeddedDataBuffer inside CMRTResource's destructor gets CoTaskMemFree'd).

### Why is this important?

This memory management bug causes the loaded XAML data to be corrupted as it is overwritten by heap management structures, resulting in unpredictable XAML parsing errors later on. The overall effect is that it is impossible to load XAML data from memory.

### Steps to reproduce the bug

- Implement Microsoft.Windows.ApplicationModel.Resources.IResourceManager, and wire it up using the ResourceManagerRequested event
- Implement IResourceMap::TryGetValue, returning a ResourceCandidate made out of embedded XAML data in memory when it asks for resources such as `Files/app.xaml`
- Observe strange XAML parsing behavior and subsequent program failure

### Actual behavior

_No response_

### Expected behavior

_No response_

### Screenshots

_No response_

### NuGet package version

1.8.260317003

### Windows version

Windows 11 (25H2): Build 26200

### Additional context

I am experimenting with WinUI 3 in order to build a minimal unpackaged app that loads all of its resources from memory (among other things). As a sidenote, it seems IResourceManager's methods are expected to return WinRT objects belonging to sealed classes that have no public constructors; they should probably be fixed to return instead interface types that can be actually implemented (currently I am working around the issue).

Contributor guide

Open the contributing guide

Research direction

Start in src/dxaml/xcp/core/dll/xcpcore.cpp at lines 3046-3048 and 3069-3076, then inspect IPALResource ownership and CMRTResource's destructor. Trace how m_embeddedDataBuffer is released when spResource leaves scope. Done means the returned XAML memory remains valid after the helper returns and the in-memory resource-loading scenario no longer produces corrupted parsing.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
desktop
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
62/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.