When start an app, there is a WinRT error 0x8007007A: "The data area passed to a system call is too small." raised while calling `FindPackagesByPackageFamily`

[hoshiizumiya]

Describe the bug

We checked all the box for 'Break when thrown' in the exception settings firstly. And when start the app, as the screenshot: FindPackagesByPackageFamily reported insufficient buffer (ERROR_INSUFFICIENT_BUFFER / HRESULT 0x8007007A). The debugger locals show bufferLength = 80 and corrupted locals (huge vector size, invalid pointer), which indicates a buffer overflow / memory corruption after the API wrote into the caller-supplied buffer. The common root cause here is allocating the buffer with the wrong unit: FindPackagesByPackageFamily returns a required character count for a PWSTR buffer, but the code likely allocated bufferLength bytes (not bufferLength * sizeof(wchar_t)), or otherwise passed a buffer too small. That causes the API to write past the allocation, corrupting nearby stack/heap state and turning the insufficient-buffer condition into undefined behavior and an originating WinRT error. Also verify you properly handle the API return codes (treat ERROR_INSUFFICIENT_BUFFER specially) and only use the buffer after a successful second call.

Steps to reproduce the bug

A blank WinUI3 C++ project is ok.
Checked all the box for 'Break when thrown' in the exception settings.
And get the exception.

Expected behavior

No response

Screenshots

NuGet package version

Windows App SDK 1.8.5: 1.8.260209005

Packaging type

Packaged (MSIX)

Windows version

Windows 11 version 24H2 LTSC (26100, June Update), Insider Build (xxxxx), Windows 11 version 24H2 (26100, June 2025 Update)

IDE

No response

Additional context

No response

[hoshiizumiya]

You can easily use my test repo to reproduce (the same as a new solution). https://github.com/hoshiizumiya/WinUI3WorkTests.git

[DrusTheAxe]

That's not a bug. VS is overreacting

The code in your callstack is in dev\Deployment\DeploymentManager.cpp line 343

        UINT32 count{};
        UINT32 bufferLength{};
        const auto rc{ FindPackagesByPackageFamily(packageFamilyName.c_str(), PACKAGE_FILTER_HEAD | PACKAGE_FILTER_DIRECT, &count, nullptr, &bufferLength, nullptr, nullptr) };
        if (rc == ERROR_SUCCESS)
        {
            // The package family has no packages registered to the user
            return std::vector<std::wstring>();
        }
        else if (rc != ERROR_INSUFFICIENT_BUFFER)
        {
            THROW_WIN32(rc);
        }

This is a classic Win32 API pattern

1. Call API with no buffer to determine size needed
2. Allocate buffer
3. Call API with buffer

The code above is doing step 1. VS is pointing to the if (rc == ERROR_SUCCESS) but I suspect it really means the purported exception is inside FindPackagesByPackageFamily().

VS reports error 0x8007007A is thrown, which is false. ERROR_INSUFFICIENT_BUFFER = 0x7A, and HRESULT_FROM_WIN32(ERROR_INSUFFICIENT_BUFFER) = 0x8007007A.

VS is probably twitching over FindPackageByPackageFamily's implementation use of WIL (Windows internally heavily uses WIL). My hunch is yes, that code returns ERROR_INSUFFICIENT_BUFFER but it passes through a WIL LOG_*() macro, or a RETURN_*() and then WIN32_FROM_RESULT(hr) to strip the HRESULT-ness to return the Win32 error as a LONG (because the implementation evolved over the years but to preserve compat with the original interface when it debuted in Win81).

WIL typically passes every 'failure' through RoOriginateError which may be what's catching VS' eye. Could be something else about how WIL happens to report the 'error' that's normally innocuous but VS is overly-sensitive too causing the false report.

This is a Windows issue, not WinAppSDK. It's also code my team owns so I'll pass word along, perhaps it's something we can tweak inside Windows. But fair warning, even if so that's likely only for new releases. I don't see this sort of change meeting the release bar for e.g. RS5.