WindowsAppSDK
WindowsAppSDK copied to clipboard
1.5 preview 1: Heap corruption for self-contained unpackaged apps
Describe the bug
After updating to 1.5 preview 1, I observe the debugger stopping with the following message:
HEAP[App.exe]: Heap block at 0000019780A81B50 modified at 0000019780A81C36 past requested size of d6
This error does not occur with the 1.4 or 1.5 experimental releases. I can also avoid this issue by setting the MICROSOFT_WINDOWSAPPRUNTIME_BASE_DIRECTORY environment variable to null.
Stack trace:
[0x0] ntdll!RtlpBreakPointHeap+0x16 0x579d57d6b8 0x7ffc25812d9a
[0x1] ntdll!RtlpCheckBusyBlockTail+0x212 0x579d57d6c0 0x7ffc257e17a3
[0x2] ntdll!RtlpValidateHeapEntry+0x4a82f 0x579d57d700 0x7ffc25815278
[0x3] ntdll!RtlDebugFreeHeap+0xd8 0x579d57d740 0x7ffc257cc62e
[0x4] ntdll!RtlpFreeHeap+0x8351e 0x579d57d7d0 0x7ffc2574be44
[0x5] ntdll!RtlpFreeHeapInternal+0x7c4 0x579d57d930 0x7ffc2574ab11
[0x6] ntdll!RtlFreeHeap+0x51 0x579d57d9f0 0x7ffb8e024d71
[0x7] MRM!MrmFreeResource+0x21 0x579d57da30 0x7ffbf70b1160
[0x8] Microsoft_Windows_ApplicationModel_Resources + 0x1160!Microsoft_Windows_ApplicationModel_Resources+0x1160 0x579d57da60 0x7ffbf70b9d66
[0x9] Microsoft_Windows_ApplicationModel_Resources!DllGetActivationFactory+0x6976 0x579d57dab0 0x7ffbf70baad8
[0xa] Microsoft_Windows_ApplicationModel_Resources!DllGetActivationFactory+0x76e8 0x579d57db40 0x7ffb43950acc
[0xb] Microsoft_WindowsAppRuntime!MddGetIdForPackageDependencyContext+0xc86c 0x579d57db70 0x7ffb30ce6c53
[0xc] Microsoft_ui_xaml!Windows::Foundation::ActivateInstanceABI::Microsoft::Windows::ApplicationModel::Resources::IResourceManager+0x2b 0x579d57dc10 0x7ffb30b65b9d
[0xd] Microsoft_ui_xaml!ABI::Windows::Foundation::ActivateInstance+0xb 0x579d57dc50 0x7ffb30cdf095
[0xe] Microsoft_ui_xaml!ABI::Windows::Foundation::ActivateInstance+0x13 0x579d57dc50 0x7ffb30cdf095
[0xf] Microsoft_ui_xaml!ModernResourceProvider::Create+0x151 0x579d57dc50 0x7ffb30cdf095
[0x10] Microsoft_ui_xaml!ModernResourceProvider::TryCreate+0x11 0x579d57dce0 0x7ffb30cc4806
[0x11] Microsoft_ui_xaml!CWindowsServices::CreateResourceProvider+0x25 0x579d57dce0 0x7ffb30cc4806
[0x12] Microsoft_ui_xaml!ResourceManager::Create+0x46 0x579d57dd40 0x7ffb30cc4794
[0x13] Microsoft_ui_xaml!CJupiterControl::CreateResourceManager+0x44 0x579d57dd90 0x7ffb30b7bbad
[0x14] Microsoft_ui_xaml!CCoreServices::GetResourceManager+0x5d 0x579d57ddc0 0x7ffb30bfa7d9
[0x15] Microsoft_ui_xaml!CCoreServices::TryLoadXamlResourceHelper+0x75 0x579d57ddf0 0x7ffb30b6b0c1
[0x16] Microsoft_ui_xaml!CCoreServices::TryLoadXamlResource+0x1f 0x579d57deb0 0x7ffb30b6afca
[0x17] Microsoft_ui_xaml!CoreImports::CoreServices_TryGetApplicationResource+0x99 0x579d57deb0 0x7ffb30b6afca
[0x18] Microsoft_ui_xaml!DirectUI::DXamlCore::ShouldTryLoadAppXaml+0x82 0x579d57df30 0x7ffb30b6b3e3
[0x19] Microsoft_ui_xaml!DirectUI::DXamlCore::EnsureCoreApplicationInitialized+0xc3 0x579d57df80 0x7ffb30c2c1f5
[0x1a] Microsoft_ui_xaml!DirectUI::FrameworkApplication::StartOnCurrentThreadImpl+0x55 0x579d57dfe0 0x7ffb30c2c177
[0x1b] Microsoft_ui_xaml!DirectUI::FrameworkApplicationGenerated::StartOnCurrentThread+0x27 0x579d57e020 0x7ffb30cbc907
[0x1c] Microsoft_ui_xaml!DirectUI::WindowsXamlManager::XamlCore::Initialize+0xe3 0x579d57e060 0x7ffb30b6a751
[0x1d] Microsoft_ui_xaml!DirectUI::WindowsXamlManager::Initialize+0x1b1 0x579d57e0e0 0x7ffb30adcc03
[0x1e] Microsoft_ui_xaml!ctl::ComObjectBase::CreateInstanceBase+0x13 0x579d57e170 0x7ffb30ccd6f4
[0x1f] Microsoft_ui_xaml!ctl::ComObjectDirectUI::WindowsXamlManager::CreateInstanceDirectUI::WindowsXamlManager+0x60 0x579d57e1a0 0x7ffb30cc91f8
[0x20] Microsoft_ui_xaml!ctl::ComObjectDirectUI::WindowsXamlManager::CreateInstance+0xd 0x579d57e1d0 0x7ffb30cc913d
[0x21] Microsoft_ui_xaml!ctl::makeDirectUI::WindowsXamlManager+0x2c 0x579d57e1d0 0x7ffb30cc913d
[0x22] Microsoft_ui_xaml!DirectUI::WindowsXamlManagerFactory::InitializeForCurrentThreadImpl+0x71 0x579d57e210 0x7ffb30cc90a3
[0x23] Microsoft_ui_xaml!DirectUI::WindowsXamlManagerFactory::InitializeForCurrentThread+0x33 0x579d57e270 0x7ffb30c66470
[0x24] Microsoft_ui_xaml!DirectUI::FrameworkApplication::StartDesktop+0x1e0 0x579d57e2b0 0x7ffb30c2c090
[0x25] Microsoft_ui_xaml!DirectUI::FrameworkApplicationFactory::StartImpl+0x45 0x579d57e3b0 0x7ffae05fa305
[0x26] Microsoft_ui_xaml!DirectUI::FrameworkApplicationFactory::Start+0x70 0x579d57e3b0 0x7ffae05fa305
[0x27] Microsoft_WinUI!ABI.Microsoft.UI.Xaml.IApplicationStaticsMethods.Start+0x145 0x579d57e400 0x7ffae05f76ac
[0x28] Microsoft_WinUI!Microsoft.UI.Xaml.Application.Start+0x2c 0x579d57e550 0x7ffae05f6fc2
Steps to reproduce the bug
Build a self-contained, unpackaged app with appsdk 1.5 preview 1
Expected behavior
No heap corruption
Screenshots
No response
NuGet package version
Windows App SDK 1.5 Preview 1: 1.5.240205001-preview1
Packaging type
Unpackaged
Windows version
Windows 11 version 22H2 (22621, 2022 Update)
IDE
Visual Studio 2022
Additional context
No response
Thank you! I've attempted the repro the issue, but I'm not seeing a problem. Can you please share a minimal sample that reproes the issue?
Hmm, I'm personally not aware of the significance of the "MICROSOFT_WINDOWSAPPRUNTIME_BASE_DIRECTORY" environment variable.
@lhak Thanks for your report. I'm unable to repro this issue as well.
Here were my steps, based on your description:
- Created a solution from the "Blank App, Packaged (WinUI 3 in Desktop)" template.
- Edited the .csproj with these property additions:
<WindowsAppSdkSelfContained>true</WindowsAppSdkSelfContained>
<WindowsPackageType>None</WindowsPackageType>
- Built the app against Windows App SDK 1.4
- F5 launched with the Unpackaged profile
- App ran successfully
- Updated the Windows App SDK nuget reference to 1.5.240205001-preview1
- Built the app again, and F5 launched successfully
@lhak I was able to repro a crash when launching a PublishSingleFile-generated exe. This was due to a stale app manifest, created before I had set PublishSingleFile=true, and not later updated. A workaround for that is to manually remove these manifests to force re-creation. In my case, the files were obj\x64\Debug\net6.0-windows10.0.19041.0\win10-x64\Manifests*.manifest. This is a bug we'll address in future.
I have attached a repro project here:
Steps to reproduce the issue:
-Build project as Release / x64 -Launch the resulting .exe with windbg
@lhak Thanks for taking the trouble to provide a repro. We'll have a fix for this available shortly.
The fix is in 1.5.0, now available