UniversalBGTask crashes with STOWED_EXCEPTION #5870

Activity

1. microsoft-github-policy-service

   added

   needs-triage

   on Sep 29, 2025
2. ssparach

   added

   area-BackgroundTaskTopics related to Microsoft.Windows.ApplicationModel.Background APIs in Windows App SDKTopics related to Microsoft.Windows.ApplicationModel.Background APIs in Windows App SDK

   on Sep 29, 2025
3. godlytalias commented on Oct 14, 2025

   

   Godly T.Alias (godlytalias)

   on Oct 14, 2025

   Last edited by godlytalias

   Contributor

   More actions

   I had a look into these crash dumps, and the crash is happening as CoCreateInstance fails and throws exception. On further checking the etl files, below are some relevant ones I am seeing

   Warning: PackagedCom entry for {B949185E-9ADC-4FD4-84B9-DAF90D64A3FB} in package 49297T.Partl.ClockOut_2.15.3.0_x64__jr9bq2af9farr (and possibly others) exists but is not visible to the caller. Lookup was performed without per-user state, which may indicate that the caller was elevated, non-user, or otherwise blocks per-user registrations (e.g. UWP and some OS processes).
   
   

   Package 49297T.Partl.ClockOut_2.15.3.0_x64__jr9bq2af9farr is not singleton or system registered
   
   

   Call security blocked activation call: CLSID:{B949185E-9ADC-4FD4-84B9-DAF90D64A3FB}, Client PID (image):6654 (C:\WINDOWS\system32\backgroundTaskHost.exe), Server PID (image): 0x60c4 (C:\Program Files\WindowsApps\49297T.Partl.ClockOut_2.15.3.0_x64__jr9bq2af9farr\WorkingHours.exe)
   

   Can you once check whether the LaunchAndActivationPermissions are set appropriately as done in the sample here
4. tipa commented on Oct 14, 2025

   

   Timo Partl (tipa)

   on Oct 14, 2025

   Author

   More actions

   Yes, LaunchAndActivationPermissions is set exactly like that.
   I think the background task is working as intended for most users, and if LaunchAndActivationPermissions wasn't set properly, it wouldn't work for any?
5. tipa commented on Oct 22, 2025

   

   Timo Partl (tipa)

   on Oct 22, 2025

   Author

   More actions

   Godly T.Alias (@godlytalias) please let me know if you need any additional information from me.
   Is it possible that crash happens when the WinAppSDK Runtime hasn't been properly installed alongside WorkingHours? Or has been uninstalled forcefully later on? I've heard from instances where this happened.
   For one of my apps I am now seeing almost 15.000 (!) crashes per day - and it's still an upwards trend
6. godlytalias commented on Oct 22, 2025

   

   Godly T.Alias (godlytalias)

   on Oct 22, 2025

   Contributor

   More actions

   Timo Partl (@tipa) Its not related to WinAppSDK Runtime, I can see the UniversalBGTask operations being executed, but the above COM class IDs mentioned is from your app right? Errors say that the CoCreateInstance for these COM classes fail as it is not found in the package.

   Howard Kapustein (@DrusTheAxe) Whether you have any clue on why these package related errors happen, #5870 (comment)
7. tipa commented on Oct 22, 2025

   

   Timo Partl (tipa)

   on Oct 22, 2025

   Last edited by tipa

   Author

   More actions

   Godly T.Alias (@godlytalias) Yes, that is the GUID for my background task. It's certainly in the app, you can test it yourself :) As I said, from what I can tell the background task basically works for most users.
   Isn't there a way to handle this error in your code so that it doesn't crash my app?
8. godlytalias commented on Oct 22, 2025

   

   Godly T.Alias (godlytalias)

   on Oct 22, 2025

   Last edited by godlytalias

   Contributor

   More actions

   Timo Partl (@tipa) Ignoring CoCreateInstance failures would be problematic, In that case we may not be able to know of real issues where the tasks are not running. Right path here would be to identify the issue with the package here and get it fixed. Anyway user experience would be same in this case as well as if we simply ignore the failure. Crash would be for backgroundtaskhost.exe process, not the app process
9. tipa commented on Oct 22, 2025

   

   Timo Partl (tipa)

   on Oct 22, 2025

   Author

   More actions

   Godly T.Alias (@godlytalias) I'd totally prefer if you could find the underlying issue, but from a developer perspective handling or not handling the error does make a difference. At the moment, my crash reporting in the Partner Center is totally flooded with those crashes and it makes it so much harder to identify the crashes I am actually able to fix. Additionally, getting so many crashes can have an impact on the Store ranking algorithm and potentially cause my app to become less visible in the Store.

   Would this crash happen when not calling CoRegisterClassObject?
   I've identified many cases in which my app throws an exception on startup (caused by the WinAppSDK - I've already reported them here). I am currently catching those errors and gracefully exit the app, without calling CoRegisterClassObject (I call that method in my Apps constructor).
10. godlytalias commented on Oct 22, 2025

    

    Godly T.Alias (godlytalias)

    on Oct 22, 2025

    Contributor

    More actions

    If the COM server don't do CoRegisterClassObject, that would fail the CoCreateInstance for sure. But I am not sure whether that is the only cause for crashes here.
    Howard Kapustein (@DrusTheAxe) may have some clues from package deployment perspective.
11. tipa commented on Oct 31, 2025

    

    Timo Partl (tipa)

    on Oct 31, 2025

    Author

    More actions

    I made sure to call CoRegisterClassObject before anything else in my app, as first instruction in the Program.Main() method (I'm using a single-instanced app, if that's of relevance here) - without luck.

    I have found yet another oddity with this background task implementation. When I omit RuntimeIdentifier in my csproj file, the background task just never fires, and I also don't see a crash. Why?

    Going through the sample, I also noted this line in which ComServer.CoRevokeObject is called. Is this of importance? If yes, why and if no, why is it included in the sample?

    Same question about this part. Is WindowsAppSDKBackgroundTask=true in the csproj really required? It seems to work without it in my apps. Why is it documented as being required?

    In the meatime, my crash count keeps rising every day and since there doesn't seem to be any fix on the horizon, I will at some point have to consider to remove the entire background task from my app again.
12. godlytalias commented on Oct 31, 2025

    

    Godly T.Alias (godlytalias)

    on Oct 31, 2025

    Contributor

    More actions

    If you omit RuntimeIdentifier, I guess it may not be deploying the universalbgtask.dll as well, you can see whether the dll is getting included in the package. Also about the point 'seeing a crash', these crashes in the spikes are from backgroundtaskhost.exe, which would not crash the 'main application process'. I think you may have to look into 'Diagnostic Data Viewer' -> Problem Reports tab / search for Microsoft.Windows.BrokerInfrastructure.* telemetry to see what is the status of the tasks (If that is not the way you're checking crash).

    ComServer.CoRevokeObject does the cleanup operations when COM server shuts down, so that COM doesn't call into a dead server handle. This may be required when application closes. This can be a catch if not being done.

    WindowsAppSDKBackgroundTask=true is not required for C# projects, as the binaries gets placed during publish operations otherwise as well. Its required for cppwinrt projects only.

    If you're having so much crash count, there should be some way to repro the issue, if you can share a repro, it would be easy to figure out root cause (as mentioned above you should not be looking for the app process crashing, it would be backgroundtaskhost.exe which would be crashing). From the crash dumps what I can find out is that, the COM server looks for creating instance of the background task class registered, but that fails.
13. tipa commented on Oct 31, 2025

    

    Timo Partl (tipa)

    on Oct 31, 2025

    Last edited by tipa

    Author

    More actions

    Also about the point 'seeing a crash', these crashes in the spikes are from backgroundtaskhost.exe, which would not crash the 'main application process'.

    When I'm referring to a "crash" then I mean a "Crash" as reported by the Partner Center in the "Health" tab and these are a problem for me.

    

    I think you may have to look into 'Diagnostic Data Viewer' -> Problem Reports tab / search for Microsoft.Windows.BrokerInfrastructure.* telemetry to see what is the status of the tasks (If that is not the way you're checking crash).

    I don't think these crashes are coming from my machines, so I won't be able to gather contextual information in the Diagnostic Data Viewer. Searching for Microsoft.Windows.BrokerInfrastructure.* yields no results.

    ComServer.CoRevokeObject does the cleanup operations when COM server shuts down, so that COM doesn't call into a dead server handle. This may be required when application closes. This can be a catch if not being done.

    • If this is required (is it really?) why is it not mentioned in the documentation here?
    • Looking at just that very documentation, it is noted that

      The background task class itself—and all other classes in the background task project—need to be public.
      

      but is this really the case? My BackgroundTask is internal and it works as expected - why? Or is this even the correct documentation for my case? It contains code about RegistrationServices that is nowhere to be found in the example app. It is really confusing
    • I'm also using the CoRegisterClassObject approach to integrate into the Windows widget panel, and that component doesn't crash at all - at least I see no related crash reports in the Partner Center
    • I can try to call CoRevokeObject and report back if that changes things, but I don't have much hope to be honest, given all my previous changes didn't improve the situation either. If using this method is really required, why is it not documented anywhere, only used in the example project? Additionally, from what I can tell basd on a few quick tests, the App deconstructor is never called.

    WindowsAppSDKBackgroundTask=true is not required for C# projects, as the binaries gets placed during publish operations otherwise as well. Its required for cppwinrt projects only.

    Would you agree that the sample should be fixed then? It currently is in the C# project sample with the note This tag is required for the usage of WinAppSDK Background Task API

    If you're having so much crash count, there should be some way to repro the issue, if you can share a repro, it would be easy to figure out root cause (as mentioned above you should not be looking for the app process crashing, it would be backgroundtaskhost.exe which would be crashing). From the crash dumps what I can find out is that, the COM server looks for creating instance of the background task class registered, but that fails.

    As I wrote before, I don't think the crashes originate from my machine, nor from machines of the majority of users. The Partner Center reports that the 15.000 crashes originate from just 460 devices (and I have much more daily active users). So that makes 32 crashes per devices on an average day. I am using a background task with a 15 minute TimeTrigger - that would perfectly match a regular 8 hour work day (4 crashes per hour)

    

    What I can do is share a trimmed down example project that shows how I have implemented the background task. Would that help?
14. godlytalias commented on Oct 31, 2025

    

    Godly T.Alias (godlytalias)

    on Oct 31, 2025

    Contributor

    More actions

    You're referring to the Platform SDK Documentation which have been there for quite some time. I don't have the context of all those points. However I feel its fair point that the background task class need to be public as it need to be invoked by an external component.
    CoRevokeClassObject is required however, I can see that in the sample as well in the doc link you shared, More details can be seen in the CoRevokeClassObject docs as well, https://learn.microsoft.com/en-us/windows/win32/api/combaseapi/nf-combaseapi-corevokeclassobject (not CoRevokeObject, winappsdk sample to be fixed)
    WindowsAppSDKBackgroundTask=true is to be fixed in C# case from winappsdk targets file itself, Currently it is working through C# publishing mechanism, hence even the apps that don't require background task ends up having those universalbgtask binaries. In upcoming versions this need to be fixed that only apps which have this flag will have those binaries packaged.
    I would suggest to fix the revoke operation and once see whether crash count goes down
15. tipa commented on Oct 31, 2025

    

    Timo Partl (tipa)

    on Oct 31, 2025

    Last edited by tipa

    Author

    More actions

    Thanks for the quick response.
    It's a bit irritating that there's a documented need for the class to be public, but it appears to be working even when the visibility is internal. Shouldn't it not work at all if it's internal? Well I'll make it public and also call the CoRevokeClassObject method and report back in a few days! I will also try to prepare a sample project that shows how I implemented the background task in my app.

    When using the single-instanced app model, should I be calling CoRevokeClassObject in the Main method as seend below instead of the Apps constructor?

    static class Program
    {
        static uint token1, token2;
    
        [STAThread]
        static void Main()
        {
            try
            {
                NativeMethods.CoRegisterClassObject(typeof(WidgetProvider).GUID, new WidgetProviderFactory(), 4, 1, out token1);
                NativeMethods.CoRegisterClassObject(typeof(BackgroundTask).GUID, new BackgroundTaskFactory(), 4, 1, out token2);
    
                var keyInstance = AppInstance.FindOrRegisterForKey("main");
                if (keyInstance.IsCurrent)
                {
                    keyInstance.Activated += (_, e) => App.HandleAppActivation(e);
                    Application.Start(p =>
                    {
                        var context = new DispatcherQueueSynchronizationContext(DispatcherQueue.GetForCurrentThread());
                        SynchronizationContext.SetSynchronizationContext(context);
                        _ = new App();
                    });
                }
                else { Tools.RedirectAppActivation(keyInstance); }
            }
            catch (Exception e) { Tools.HandleStartupException(e); }// https://github.com/microsoft/WindowsAppSDK/issues/5694
    
            // https://github.com/microsoft/WindowsAppSDK/issues/5870#issuecomment-3474298468
            NativeMethods.CoRevokeClassObject(token1);
            NativeMethods.CoRevokeClassObject(token2);
        }
    }
    
    ...
    
    [LibraryImport("ole32.dll")]
    public static partial int CoRegisterClassObject(
        in Guid classId, [MarshalAs(UnmanagedType.Interface)] IClassFactory objectAsUnknown,
        uint executionContext, uint flags, out uint registrationToken);
    
    [LibraryImport("ole32.dll")]
    public static partial int CoRevokeClassObject(uint registrationToken);
    
    
16. 25 remaining items

    Load more

17. tipa commented on May 21, 2026

    

    Timo Partl (tipa)

    on May 21, 2026

    Author

    More actions

    Thanks. Could you clarify what exactly you mean by “ApplicationData got cleaned up”?

    Should I check whether ApplicationData.Current.LocalSettings is empty, whether LocalFolder is empty, or is there another package/AppData state I can reliably query?

    I can unregister background tasks when app data appears empty and old registrations still exist, but that only helps if my app process actually gets launched. If the crash happens inside backgroundTaskHost.exe / UniversalBGTask before my EXE gets control, app-side cleanup cannot run.

    Is this workaround expected to help in that pre-app-start crash case too?
18. godlytalias commented on May 25, 2026

    

    Godly T.Alias (godlytalias)

    on May 25, 2026

    Contributor

    More actions

    Yes, ApplicationData.Current.LocalSettings can be checked whether it is empty and clear up the registration. We can run this task in the UWP background task itself (as a maintenance trigger or servicing complete trigger) so that UniversalBGTask is not involved.

    This can be an improvement done to UniversalBGTask itself to clear up the registration if the LocalSettings have gone empty I think.
19. tipa commented on May 25, 2026

    

    Timo Partl (tipa)

    on May 25, 2026

    Author

    More actions

    Thanks, that clarifies it.

    If UniversalBGTask can check ApplicationData.Current.LocalSettings and unregister stale background task registrations before attempting COM activation, that sounds like the right place for this mitigation. An app-side workaround can only run after my EXE gets control, so it cannot help when backgroundTaskHost.exe / UniversalBGTask crashes before COM activation succeeds.

    For an app-side workaround: should I only check ApplicationData.Current.LocalSettings.Values.Count == 0, or should I also check for missing app-owned settings keys? If LocalSettings was cleaned and the app later started normally, it may recreate default settings, so LocalSettings would no longer be empty even though the cleanup already happened.

    Is there any other workaround you recommend that app developers can apply today, or should this mainly be fixed in UniversalBGTask?
20. godlytalias commented on May 26, 2026

    

    Godly T.Alias (godlytalias)

    on May 26, 2026

    Contributor

    More actions

    TaskId - Com GUID propertyset is what is expected in the LocalSettings for the lookup to work properly.

    Workaround can be done from app side now with the UWP Background Task as I mentioned earlier (Setup a WinRT component and give that as entry point using Windows.ApplicationModel.BackgroundTask APIs for a ServiceComplete or Maintenance trigger). These tasks would get executed outside the UniversalBGTask and can be leveraged to check the correctness of ApplicationData.
21. tipa commented on May 26, 2026

    

    Timo Partl (tipa)

    on May 26, 2026

    Author

    More actions

    Thanks. Given that the missing TaskId -> COM GUID mapping is state required by UniversalBGTask, and the crash happens inside UniversalBGTask before my app may get control, it sounds like the robust fix would need to be in UniversalBGTask itself.

    I can add app-side cleanup, but that cannot reliably stop the crash loop if COM activation fails before my EXE starts. Also, adding a separate WinRT/UWP cleanup background task to every affected app is quite a large workaround for state that is internal to the WinAppSDK background task bridge. I’ve already had to add several app-side mitigations around this area, and none can cover failures that happen before the app process starts.

    Is there anything preventing UniversalBGTask from detecting the missing mapping and unregistering/aborting cleanly before it throws?
22. godlytalias commented on May 26, 2026

    

    Godly T.Alias (godlytalias)

    on May 26, 2026

    Contributor

    More actions

    I've created the PR here: #6507
    It may take some time to get merged and serviced probably. Meanwhile if you want you can try the app workaround.

    👍React with 👍1Reacted by Timo Partl
23. tipa commented on May 26, 2026

    

    Timo Partl (tipa)

    on May 26, 2026

    Author

    More actions

    Thanks, this looks like the right place to handle it. I’ll keep my lightweight app-side cleanup/telemetry for now, but I’ll avoid adding the separate UWP cleanup task unless the PR takes too long to ship.

    Do you already know which WinAppSDK version this is expected to be serviced in?
24. godlytalias commented on May 27, 2026

    

    Godly T.Alias (godlytalias)

    on May 27, 2026

    Contributor

    More actions

    Will plan to service in 1.8 & 2.0, However it may require a rebuild and update of app post that as this DLL is bundled with app package.
25. Godly T.Alias (godlytalias)

    closed this as completedin #6507on Jun 12, 2026
26. microsoft-github-policy-service

    removed

    needs-triage

    on Jun 12, 2026
27. Glenn (glennawatson)

    added a commit that references this issue on Jul 20, 2026

    chore(deps): update dependency microsoft.windowsappsdk to 2.3.1 (#4406)

    ...

    3f04004
28. tipa commented on Aug 4, 2026

    

    Timo Partl (tipa)

    on Aug 4, 2026

    Last edited by tipa

    Author

    More actions

    Thanks a lot for the fix and the latest release! After updating to Runtime 2.3.1, Partner Center shows substantially fewer crashes but a sharp increase in hangs, without relevant app-side changes. One current release reports 288 HANG_QUIESCE events on 284 devices.

    Another affected release still reports UniversalBGTask::Task::Run crashes with 0x80073DB8 (ERROR_STATE_LOAD_STORE_FAILED). The current implementation accesses ApplicationData::Current().LocalSettings() before the guarded missing-key path, without handling state-store loading failures. Could the exception be escaping there?

    Could you check the Store-side diagnostics and whether the increased hangs are related?

    Also, is the elevated/per-user COM activation limitation mentioned earlier still applicable after #6507, and is it tracked separately?
29. microsoft-github-policy-service

    added

    needs-triage

    on Aug 4, 2026
30. godlytalias commented on Aug 4, 2026

    

    Godly T.Alias (godlytalias)

    on Aug 4, 2026

    Contributor

    More actions

    HANG_QUIESCE happens if the background task don't finish in the allowed time interval, The process would be terminated / suspended once the time runs out. Holding the deferral can increase the time window. Elevated COM activation is still applicable as the current changes was just for graciously handling some of the common crash cases.

    Tagging Howard Kapustein (@DrusTheAxe) for 0x80073DB8 on ApplicationData.
31. Lauren Ciha (lauren-ciha)

    removed

    needs-triage

    on Aug 17, 2026