microsoft / microsoft/microsoft-ui-xaml
`CCoreServices::TryLoadXamlResourceHelper` inadvertently frees the loaded XAML before returning it
- 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
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