WindowsAppSDK icon indicating copy to clipboard operation
WindowsAppSDK copied to clipboard

1.5 preview 1: Heap corruption for self-contained unpackaged apps

Open lhak opened this issue 1 year ago • 5 comments

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

lhak avatar Feb 12 '24 19:02 lhak

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.

JesseCol avatar Feb 15 '24 01:02 JesseCol

@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

Scottj1s avatar Feb 16 '24 05:02 Scottj1s

@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.

Scottj1s avatar Feb 16 '24 05:02 Scottj1s

I have attached a repro project here:

MrtCrashRepro.zip

Steps to reproduce the issue:

-Build project as Release / x64 -Launch the resulting .exe with windbg

lhak avatar Feb 16 '24 08:02 lhak

@lhak Thanks for taking the trouble to provide a repro. We'll have a fix for this available shortly.

Scottj1s avatar Feb 16 '24 18:02 Scottj1s

The fix is in 1.5.0, now available

bpulliam avatar Feb 29 '24 19:02 bpulliam