[Bug][Windows] MAUI has a chance to fail with 0xC0000409 crash in InputStateManager.dll when processing tap input

[BMS-Malcolm]

Description

The application crashes with a fail-fast exception (0xC0000409) coming from InputStateManager.dll, specifically in InProcInputHandler::PopulateContactInFrame. This has a chance to occur when the application receives tap input. The frequency scales with the strength of the computer. Strong computers require extreme rapid tapping to reproduce, weaker computers will crash very quickly from rapid tapping, and even have a small chance to crash on single taps. Issue is reproducible on a basically blank new maui application

This issue appears to be a regression in recent MAUI versions — it does not reproduce in 9.0.50, but is easy to reproduce in any version after this

Repository

https://github.com/BMS-Malcolm/basic-maui-app

Continuously rapidly tapping the app launched with this repo will, after a random amount of time, crash with NO exception caught by the program or propagated through the debugger or program at all with an entry in EventViewer that reads

this

Faulting application name: Blank_Maui_App.exe, version: 1.0.0.0, time stamp: 0x68760000 Faulting module name: Microsoft.InputStateManager.dll, version: 10.0.26107.1011, time stamp: 0x0bb886ad Exception code: 0xc0000409 Fault offset: 0x0000000000012848 Faulting process id: 0x7244 Faulting application start time: 0x1DC1DB1DCE859BA Faulting application path: C:\Users\user\source\repos\Blank_Maui_App\Blank_Maui_App\bin\Debug\net9.0-windows10.0.19041.0\win10-x64\Blank_Maui_App.exe Faulting module path: C:\Users\user\source\repos\Blank_Maui_App\Blank_Maui_App\bin\Debug\net9.0-windows10.0.19041.0\win10-x64\Microsoft.InputStateManager.dll Report Id: 3f63e5c4-0acc-462e-a35d-84093532cdc2 Faulting package full name: Faulting package-relative application ID:

Steps to Reproduce

Create a simple MAUI app with a Page in it

Tap the screen very quickly (clicks do not seem to work -- but that could be due to clicks not being very fast)

Observe crash after some time of tapping

Observed Behavior

App crashes without exception stack trace

No catchable exception — crash is a native fail-fast (0xC0000409)

Only trace is in Event Viewer and .dmp file and it is purely native code in that stack trace

Crash is deterministic with rapid taps on recent MAUI versions

Crash Details

ExceptionCode: 0xC0000409 (Security check failure or stack buffer overrun) ExceptionAddress: Microsoft_InputStateManager!InProcInputHandler::PopulateContactInFrame+0x5a4 Subcode: 0x7 FAST_FAIL_FATAL_APP_EXIT

WinDbg Analysis of .dmp: !gle LastErrorValue: 0x12a (298) - Too many posts were made to a semaphore. !error 0x80070578 → Invalid window handle

Expected Behavior

App should not crash during UI updates or rapid user input

Input system should gracefully ignore or defer events during layout changes

Actual Behavior

App crashes with native fail-fast (0xC0000409) from InputStateManager.dll

No managed exception is visible

Affects production users intermittently, more common on older hardware

Version with bug

Anything over 9.0.50

Is this a regression from previous behavior?

Presumably, as I cannot reproduce this on my machine anymore with 9.0.50. After we backported our application to this version our clients reported far fewer crashes due to this but it did not fix it 100% for them

Last version that worked well

9.0.50

Affected platforms

Windows

Workarounds Tested

✅ Downgrading to MAUI 9.0.50 eliminates crash in rapid tap tests on our development machines, and appears to substantially help on lower end Windows based tablets among our clients, but did not eliminate it in entirety on the lower end tablets

❌ No full fix without changing MAUI version (hard-setting the windows SDK version to lower than 1.7.x but keeping the maui version up to date does not work either)

Additional Notes

Has been occurring for quite some time, first report of this issue from users comes from early April of this year

Based on the errors being received, my best guess is that the input reception channels are not being cleared and/or cleaned up when an element on the screen is modified in memory, resulting in it being possible that a touch input is sent through the input processing channel for a element that has changed in memory since the event was first queued up, and so the stack pointers in that processing channel are no longer valid as the underlying element is now using a new section of memory. This explains the error codes (Invalid window handle, Buffer overrun), it explains why this error has a random chance to occur on tap rather than being deterministic and how this issue scales with machine strength (faster machines will process element changes more quickly, thus the window of time in which this can occur becomes small enough to be almost impossible to hit)

Workaround Update: For anyone else experiencing this issue, adding both of these two things to your csproj file

<MauiVersion>9.0.50</MauiVersion>

<ItemGroup>
    <PackageReference Include="Microsoft.WindowsAppSDK" Version="[1.6.250205002,1.7)" />
</ItemGroup>

Seems to help, but does not fix the problem. It simply reduces the crash frequency by a good amount

[jfversluis]

Please use the issue template and attach a reproduction or relevant code at the very least. In the current state, this issue is very unlikely to be fixed.

[BMS-Malcolm]

Changed the formatting of my message so hopefully the bot catches that I added repro steps. Working on getting a repo up of a basic maui app that experiences this issue

[BMS-Malcolm]

Added a repository with directions for it

[TamilarasanSF4853]

This issue has been verified in Visual Studio 17.14.13 Preview 1.0 with .NET MAUI version 9.0.110. It cannot be reproduced on the Windows platform. I have attached the video for your reference.

https://github.com/user-attachments/assets/703af818-d9f6-4b83-af65-510b1a33ad88

[BMS-Malcolm]

I used snipping tool to show an example of me receiving the crash, and then dragged up event viewer to show the event viewer entry

https://github.com/user-attachments/assets/fd0093e8-f3de-44e9-83c0-a89ba5e20888

[bronteq]

What are your pc specifications? (pc, cpu, gpu models, ram amount, touch type, windows version) Do you repro the issue both in debug and release?

[BMS-Malcolm]

What are your pc specifications? (pc, cpu, gpu models, ram amount, touch type, windows version) Do you repro the issue both in debug and release?

Processor Intel(R) Core(TM) i5-8400 CPU @ 2.80GHz, 2808 Mhz, 6 Core(s), 6 Logical Processor(s)

RAM: 32gb 2 chips Manufacturer PartNumber 859B0000802C CT16G4DFRA32A.M16FE 859B0000802C CT16G4DFRA32A.M16FE

No dedicated GPU

Touch screen and mouse plugged in

OS Name Microsoft Windows 11 Enterprise Version 10.0.26100 Build 26100

Some examples of tablet models that we know are experiencing this issue are: Surface_Go_4_2067 Surface_Go_1824_Consumer

This issue is both observable launched from debug as well as in a proper published app made in release mode

[bronteq]

I tried the proposed project with my pc and a touch display but I was not able to repro the issue, I'm sorry

[BMS-Malcolm]

Could you try using a weaker computer to do it? The frequency seems to scale inversely with computer strength.

Also last week we made an update adding

<ItemGroup>
    <PackageReference Include="Microsoft.WindowsAppSDK" Version="[1.6.250205002,1.7)" />
</ItemGroup>

to the .csproj file, and that actually appeared to have helped significantly based on feedback

So having BOTH

<MauiVersion>9.0.50</MauiVersion>
<ItemGroup>
    <PackageReference Include="Microsoft.WindowsAppSDK" Version="[1.6.250205002,1.7)" />
</ItemGroup>

appears to help considerably with this issue. Having one but not both of these csproj entries does not give the same results, and using any SDK of 1.7 or higher or any maui version over 9.0.50 results in no improvement with this issue, if that helps you narrow anything down.

[bronteq]

At the moment i don't have a weaker machine, but maybe the bug is related to one of these inconsistencies that hopefully will be solved soon: https://github.com/dotnet/maui/pull/31669 https://github.com/dotnet/maui/pull/31667

[BMS-Malcolm]

If it is helpful at all in the discovery process, here is another input related bug that stems from the InputStateManager.dll

Not exactly the same bug as mine, but the underlying issue may be the same

https://github.com/microsoft/microsoft-ui-xaml/issues/10802

[PureWeen]

@BMS-Malcolm if you update to the latest MAUI and/or the latest WinAppSDK (version 1.8) does that help?

[BMS-Malcolm]

@PureWeen I installed the new Maui 10 workload and the newest visual studio update and created a fresh template project with dotnet maui 10. https://github.com/BMS-Malcolm/basic-maui-app-10

The issue appears to still exist when I set my maui target with <MauiVersion>10.0.10</MauiVersion> If I rapidly tap on the screen with two hands the app will fail-fast crash with no exception given to the debugger after a short period of time with InputStateManager.dll listed as the fault source in Windows' Event Viewer

If I browse my Windows SDK version in the nuget package manager, it appears Maui 10 still uses SDK version 1.7.2

I attempted to hard reference the Windows SDK to 1.8.251106002 but I get the error "The Windows App SDK requires a specific target OS version. Please set the <TargetFramework> property to an appropriate value. For more information, visit https://aka.ms/winappsdk.TFM."

Could you advise me on what OS version needs to be targeted for Windows SDK 1.8.x? My googling yielded that my current setup should be working properly

Update 11/18/25 I still cannot get SDK 1.8.2 to build with MAUI 10.0.10, but I was able to get it to build with MAUI 9.0.50, and using the 9.0.50 + SDK 1.8.2 combo still results in the InputStateManager crash

[DrCSharp]

My company and I are experiencing the same problem, specifically with the WinUI3 Desktop App. Since Microsoft.WindowsAppSDK version 1.7.xx/1.8.xx, the application crashes randomly and involuntarily when using touch gestures. The error message is: (0xC0000409) from InputStateManager.dll. Therefore, we are using Microsoft.WindowsAppSDK version 1.6.xx for our development until further notice.

[bronteq]

@DrCSharp how do you set in Maui the specific Microsoft.WindowsAppSDK version to use?

[DrCSharp]

I don't use Maui; I develop native WinUI3 apps. But the problem seems to be the same; I found something about it in the forum, and it seems that not many people have noticed the issue so far.

[BMS-Malcolm]

@DrCSharp Were you able to nail down a specific Windows SDK version that resolves this? We are currently using

<ItemGroup>
    <PackageReference Include="Microsoft.WindowsAppSDK" Version="1.6.250205002" />
</ItemGroup>

And it helped compared to not referencing any SDK version and letting MAUI choose (MAUI uses WinUI3 under the hood for Windows), but we still experience crashing.

Any insight on workarounds you have found to work would be extremely helpful.

The crashing on our product is disruptive and most certainly not up to our standards, and we are starting to have to seriously consider making the hard decision of restarting with another framework because there seems to be nothing that can be done about this on our end but it is completely unsustainable for a product to just be crashing with no immediate resolution

[DrCSharp]

@BMS-Malcolm We are using version Microsoft.WindowsAppSDK 1.6.250602001. It seems to be running fairly stably; at least no customers are complaining, although some report occasional crashes. But that could also be due to one's own shortcomings 😁

Things get bad from version 1.7.xx and 1.8.xx onwards. I tapped it 5 times and the app crashed. Customers and our service technicians have complained. We ship our app with an energy-efficient panel PC. The problem hardly ever occurs on my development machine; there I have to force it and tap the screen what feels like 100 times per second. Then it occasionally happens. But on the slower panels, a gentle tap is enough.

Yes, you get the feeling that Microsoft develops things for fun and doesn't consider that their products are also used in production environments and that everything needs to be stable, because those in charge get impatient very quickly.

The touch keyboard was also a huge problem for a long time. Initially, it didn't work at all in the WinUI 3 environment, then it started doing crazy things and stopped working altogether. It took Microsoft over two years to solve the problem...