Long running UWP App Crash | Exception 0xc0000005 in Windows.UI.Xaml.dll

[rnavulla]

Our team has been developing a UWP app for the better part of two years that communicates with various PLC Equipment Controllers. We send commands, receive sensor data, and then display the received data via graphs, text fields, etc.

We have been running in to issues during long running executions of the application. Our clients expect to be able to run the app in the field without production interruptions 24/7 for several weeks at a time. At present the app will crash unexpectedly after roughly 3 days of running at the maximum load for our application.

At maximum load, our app will be running 20 different screens across 10 different monitors. All of them are displaying a combination of graphs and text fields which are updated roughly once per second.

After checking the Event Viewer for more information, I have seen the below error codes after our app crashes. I’ve been working on this issue for over a month now, it’s always one of these three and for the life of me I’m unable to pinpoint where in our code this would be happening.

Error codes:
1: c0000005 (Windows.UI.Xaml.dll)
2: c0000409 (ucrtbase.dll)
3: c0000374 (ntdll.dll)

The error codes above all seem to be some flavor of a memory/pointer issue and my instincts are telling me they're all related somehow. I honestly don't know what steps to take at this point to identify the root cause of this issue.

I haven't been able to reproduce this error in debug mode.

Any help would be greatly appreciated.

Below is the specific Event Viewer log from the Windows.UI.Xaml.dll crash. I can make the other two available as well if they would be useful.

---

From Event Viewer:

(Application Error)
Faulting application name: [Our App Name], time stamp: 0x5a68410c
Faulting module name: Windows.UI.Xaml.dll, version: 10.0.18362.657, time stamp: 0xda02d3eb
Exception code: 0xc0000005
Fault offset: 0x00000000000b808f
Faulting process id: 0xe40
Faulting application start time: 0x01d5ec225ebfa2d9
Faulting application path: C:\Program Files\WindowsApps[Our App Name]
Faulting module path: C:\Windows\System32\Windows.UI.Xaml.dll
Report Id: 66139cf4-adb6-4c63-9fe7-c169cde9def6
Faulting package full name: [Our App Name]
Faulting package-relative application ID: App

---

(Windows Error Reporting)
Fault bucket 1388243377398654764, type 5
Event Name: MoAppCrash
Response: Not available
Cab Id: 0
Problem signature:
P1: [Our App Name]
P2: praid:App
P3: 1.0.0.0
P4: 5a68410c
P5: Windows.UI.Xaml.dll
P6: 10.0.18362.657
P7: da02d3eb
P8: c0000005
P9: 00000000000b808f
P10:

I also have the Report.wer file and a crash dump if needed.

[ranjeshj]

@rnavulla Thanks for reporting. can you please share the crash dump ?

[grantuland]

Hi @ranjeshj, I'm working on this issue with @rnavulla. Do you want the full dump or will a partial dump be enough? Is there an email we can send it to? I'd rather not post the full dump publicly.

[ranjeshj]

@grantuland - sorry for the delayed response. I was trying to figure out the alternative to sharing dumps in public. I think the best option would be to file a feedback hub item and share the URL here. Then we can track the crash dump through the Watson system. Thanks.

@jevansaks as FYI

[grantuland]

@ranjeshj - No problem, thank you for taking the time to respond. I uploaded the dump file to Feedback Hub.

Link: https://aka.ms/AA7rpq3

[ranjeshj]

This looks to be a crash in Windows_UI_Xaml!DirectUI::UIAffinityReleaseQueue::DoCleanup.

[grantuland]

@ranjeshj Can that be caused by something is our solution? We aren't calling DoCleanup anywhere.

[ranjeshj]

@ranjeshj Can that be caused by something is our solution? We aren't calling DoCleanup anywhere.

I'm not entirely sure about that. If you have a standalone repro of the issue you can share, that would be really useful.

[chrisglein]

Windows_UI_Xaml!DirectUI::UIAffinityReleaseQueue::DoCleanup.

This is a known class of lifetime issues (internal link).

@grantuland What Windows version is this occuring on? There were fixes made to Windows in version 18362 to address this issue that dramatically cut down on the hits by something like 99%. That fix was then was backported to the 2 preceding releases of Windows. Let us know which versions you are hitting this on and especially if it's still a problem on latest versions of Windows.

[grantuland]

@chrisglein Version 1909 (OS Build 18363.720)

[grantuland]

@chrisglein Our application is still targeting 1803 I believe, could that be causing the issue to come back up?

We were running in to issues with EntityFramework when upgrading to 1903 which is why we haven't updated it yet.

[chrisglein]

Possibly. Here's the information I have about the backport:

The largest impact was addressed in 19H1 (1903), which was then backported to RS4 and RS5. Impacted customers can:
If staying on RS4 (1803), upgrade to at least 10.0.17134.799 (KB 4499183).
If staying on RS5 (1809), upgrade to at least 10.0.17763.529 (KB 4497934).

Adding @jonthysell in case he can add any more context.

[grantuland]

@chrisglein We are currently updating our app to target 1903 and will start our tests again. I'll keep you informed. Thank you for the insight.

[grantuland]

@chrisglein FYI: We sideload our application with developer mode enabled. We also aren't using the .Net Native Toolchain for compilation. Do you know if the fix deployed for 1903 is dependent on either of those things?

[msft-github-bot]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.

[HppZ]

any updates?

[jevansaks]

@HppZ What updates are you looking for? In reading this thread it sounds like the platform fix was serviced. Are you still seeing the crash on your system?