UniversalBGTask crashes with 0x8007001F

Describe the bug

When using UniversalBGTask from Windows App SDK, the backgroundtaskhost.exe process crashes regularly. The actual background task is then never executed. Following crash stack:

PROCESS_NAME:  backgroundTaskHost.exe
ERROR_CODE: (NTSTATUS) 0xc000027b - An application-internal exception has occurred.
 # Child-SP          RetAddr               Call Site
00 00000044`de07e930 00007ffc`005b27bc     biwinrt!Windows::ApplicationModel::Background::CBackgroundTaskInstance::ReportSilentException+0x6c [onecoreuap\base\background\bi\winrt\impl\actbwii.cpp @ 1072] 
01 00000044`de07ef40 00007ffc`005b21d3     biwinrt!Windows::ApplicationModel::Background::CBackgroundTaskInstance::RunInternal+0x5cc [onecoreuap\base\background\bi\winrt\impl\actbwii.cpp @ 1012] 
02 00000044`de07f140 00007ffc`2eb1de14     biwinrt!Windows::ApplicationModel::Background::CBackgroundTaskInstance::Run+0x53 [onecoreuap\base\background\bi\winrt\impl\actbwii.cpp @ 821] 
03 00000044`de07f170 00007ffc`44050ce0     twinapi_appcore!Windows::ApplicationModel::Core::BackgroundTaskWrapper::ThreadProc+0xe4
04 00000044`de07f350 00007ffc`4403d7a1     ntdll!TppWorkpExecuteCallback+0x4d0
05 00000044`de07f4b0 00007ffc`4328e8d7     ntdll!TppWorkerThread+0x801
06 00000044`de07f810 00007ffc`4405c5dc     kernel32!BaseThreadInitThunk+0x17
07 00000044`de07f840 00000000`00000000     ntdll!RtlUserThreadStart+0x2c

Stowed exception:

Stowed Exception microsoft/WindowsAppSDK#1 @ 0x000002145c1514c8
	0x8007001F (FACILITY_WIN32 - Win32 Undecorated Error Codes): A device attached to the system is not functioning.

	Stack : 0x2145c1538b0
		7ffc422bb88f combase!RoOriginateLanguageException+0x5f
		7ffc31c9400d Microsoft_Windows_ApplicationModel_Background_UniversalBGTask!winrt::hresult_error::originate+0x7d
		7ffc31c942b3 Microsoft_Windows_ApplicationModel_Background_UniversalBGTask!winrt::hresult_error::hresult_error+0x1cb
		7ffc31c94543 Microsoft_Windows_ApplicationModel_Background_UniversalBGTask!winrt::throw_hresult+0x213
		7ffc31c914ef Microsoft_Windows_ApplicationModel_Background_UniversalBGTask!winrt::Microsoft::Windows::ApplicationModel::Background::UniversalBGTask::implementation::Task::Run+0x463
		7ffc31c91a5c Microsoft_Windows_ApplicationModel_Background_UniversalBGTask!winrt::impl::produce<winrt::Microsoft::Windows::ApplicationModel::Background::UniversalBGTask::implementation::Task,winrt::Windows::ApplicationModel::Background::IBackgroundTask>::Run+0x2c
		7ffc005b23c1 biwinrt!Windows::ApplicationModel::Background::CBackgroundTaskInstance::RunInternal+0x1d1
		7ffc005b21d3 biwinrt!Windows::ApplicationModel::Background::CBackgroundTaskInstance::Run+0x53
		7ffc2eb1de14 twinapi_appcore!Windows::ApplicationModel::Core::BackgroundTaskWrapper::ThreadProc+0xe4
		7ffc44050ce0 ntdll!TppWorkpExecuteCallback+0x4d0
		7ffc4403d7a1 ntdll!TppWorkerThread+0x801
		7ffc4328e8d7 kernel32!BaseThreadInitThunk+0x17
		7ffc4405c5dc ntdll!RtlUserThreadStart+0x2c

When checking the offset with the source file, the error seems to be at the lookup of the ApplicationData.Values:

(00000001`8000108c)   Microsoft_Windows_ApplicationModel_Background_UniversalBGTask!winrt::Microsoft::Windows::ApplicationModel::Background::UniversalBGTask::implementation::Task::Run+0x463   |  (00000001`800015a0)   Microsoft_Windows_ApplicationModel_Background_UniversalBGTask!winrt::impl::consume_Windows_Foundation_Collections_IMap<winrt::Windows::Foundation::Collections::IPropertySet,winrt::hstring,winrt::Windows::Foundation::IInspectable>::Lookup

When trying to execute similar lookup code in the packaged WinUI 3 app itself (using the TaskID as lookup value, found via PowerShell Get-AppBackgroundTask), no crash occurs and the CLSID is returned as expected.

Full dump file can be provided privately if required.

Steps to reproduce the bug

The exact conditions to reproduce are unclear. It seems to only happen if the main app isn't currently running while the background task is being started. When starting the background task via Visual Studio "Lifecycle Events", no error occurs.

Define COM server extension for background task in appxmanifest

<com:Extension Category="windows.comServer">
  <com:ComServer>
    <!-- COM Server for the background task, LaunchAndActivationPermission is required to give permission
         for backgroundtaskhost process to cocreate this COM component -->
    <com:ExeServer Executable="myapp.exe" Arguments="-RegisterForBGTaskServer" DisplayName="BackgroundTask"
                      LaunchAndActivationPermission="O:PSG:BUD:(A;;11;;;IU)(A;;11;;;S-1-15-2-1)S:(ML;;NX;;;LW)">
      <com:Class Id="918674B4-E2FF-4041-B23F-568F6B897473" DisplayName="myTask" />
    </com:ExeServer>
  </com:ComServer>
</com:Extension>

Register background task with Microsoft.Windows.ApplicationModel.Background.BackgroundTaskBuilder and SetTaskEntryPointClsid(918674B4-E2FF-4041-B23F-568F6B897473)
Run the app once to register everything
Close the app (+restart the PC?)
Get background task ID with Get-AppBackgroundTask in PowerShell
Start background task with Start-AppBackgroundTask -TaskID ... in PowerShell
Check crash dump file in %localappdata%\CrashDumps

Expected behavior

backgroundtaskhost.exe process doesn't crash.

Screenshots

No response

NuGet package version

Windows App SDK 1.7.3: 1.7.250606001

Packaging type

Packaged (MSIX)

Windows version

Windows 11 version 24H2 (26100, June 2025 Update)

IDE

Visual Studio 2022

Additional context

No response

I'm also seeing (a massive amount of) crashes in the background task, however I'm not sure if it's caused by the same thing as reported here. This crash report is being logged in the Windows Event Viewer

Faulting application name: backgroundTaskHost.exe, version: 10.0.26100.1, time stamp: 0x5bc61463
Faulting module name: Microsoft.Windows.ApplicationModel.Background.UniversalBGTask.dl, version: 1.7.0.0, time stamp: 0x5dcabba1
Exception code: 0xc0000005
Fault offset: 0x000000000000142e
Faulting process id: 0x9518
Faulting application start time: 0x1DC063030F42495
Faulting application path: C:\WINDOWS\system32\backgroundTaskHost.exe
Faulting module path: C:\Program Files\WindowsApps\My.App_1.2.3.0_x64__xyz\Microsoft.Windows.ApplicationModel.Background.UniversalBGTask.dll
Report Id: ef8e4404-c1fa-4492-bb75-caaa231ceace
Faulting package full name: My.App_1.2.3.0_x64__xyz
Faulting package-relative application ID: App

I'm using full trimming and NativeAot, if that makes a difference.
I'm also confused about the last "l" missing in "...UniversalBGTask.dl" in the crash log above

I've dealt more with this issue in the last two days as my app is still crashing pretty consistently (like every 15 mins when using a TimeTrigger), causing extremely high crash rates reported in the Partner Center. There are no crashes when debugged locally.

Looking at the BackgroundTaskBuilder code a bit closer, I wonder what the TaskGroup property is for, since I don't seem to be able to create a BackgroundTaskRegistrationGroup myself.
Can you please shed some light on how Windows.Storage.ApplicationData.Current.LocalSettings is used? It looks like it is used to provide a mapping from task id to the background task guid. However, when unregistering a task, the corresponding value in LocalSettings is not removed. Also, what is the expected behavior if an app removes the value from LocalSettings. Would the background task no longer run or even crash?

I've also tested v1.8.250702007-experimental4, but the problem persists.

I don't know why, but the crash log in the Event Viewer now looks slightly different, Microsoft.Windows.ApplicationModel.Background.UniversalBGTask, is no longer listed

Faulting application name: backgroundTaskHost.exe, version: 10.0.26100.1, time stamp: 0x5bc61463
Faulting module name: biwinrt.dll, version: 10.0.26100.4768, time stamp: 0x536763fa
Exception code: 0xc000027b
Fault offset: 0x0000000000012713
Faulting process id: 0xAE80
Faulting application start time: 0x1DC0774FF034DDE
Faulting application path: C:\WINDOWS\system32\backgroundTaskHost.exe
Faulting module path: C:\Windows\System32\biwinrt.dll
Report Id: 651989c2-42c6-487f-a192-74f1ca6f3ec2
Faulting package full name: My.App_1.2.3.0_x64__xyz
Faulting package-relative application ID: App

Any help would be greatly appreciated.

Timo Partl (@tipa)

Timo Partl (@tipa) The new crash log you mentioned seems to be the same as mine. Because this is a stowed WinRT exception 0xc000027b, the actual crash not directly visible and must first be extracted from the dump file.

I've been looking at the crash dump files on my computer in %localappdata%\CrashDumps . I also had to create a registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\backgroundtaskhost.exe DumpType = 2 (DWORD) to ensure a full dump is created on crash. Otherwise, the stowed exception would get lost.

BernhardMarconato

BernhardMarconato thanks. After creating that registry key, I am getting much larger crash dumps, but I don't know how to "read" them. I'm happy to provide them to Godly T.Alias (@godlytalias) if it helps resolving this issue.
Have you found any workaround for this problem in the meantime or how are you dealing with those crashes?

Timo Partl (@tipa)

Timo Partl (@tipa) To answer your queries,

TaskGroup is for grouping some of the background task registrations together, For creating a BackgroundTaskRegistrationGroup you may have to leverage this API, https://learn.microsoft.com/en-us/uwp/api/windows.applicationmodel.background.backgroundtaskregistrationgroup?view=winrt-26100

LocalSettings is used to store the mapping between a background task registration and the corresponding task GUID, While doing task registration, a unique GUID is generated for the background task, and this is used for the mapping (https://learn.microsoft.com/en-us/uwp/api/windows.applicationmodel.background.backgroundtaskregistration.taskid?view=winrt-26100). Whether you're seeing some scenario where same TaskID gets generated for multiple registrations?
For reference, the storing logic is done here

If an app explicitly removes these LocalSettings values, then background task won't execute (it will throw exception as the lookup fails). This would happen even if users explicitly removes background task execution permission for the application. Whether you're noticing any of these cases?

Use WinDbg (from Microsoft Store) to open the dmp file, and then run the !dse command and it should list the stowed exceptions.

I have not found a workaround for the issue yet... especially since the error code makes no sense at all: 0x8007001F (FACILITY_WIN32 - Win32 Undecorated Error Codes): A device attached to the system is not functioning. Why would this HRESULT be returned when reading a value from a ApplicationData.Values IMap? Maybe they also misused the error code, thinking it would be a "general" error since it's defined as ERROR_GEN_FAILURE.

As I mentioned above, from my regular app I can read the LocalSettings without any problem and it also contains the correct GUIDs. I feel like there is some bug in the ApplicationData.Values API that it doesn't work from backgroundtaskhost.exe in some cases.

Godly T.Alias (@godlytalias)

Godly T.Alias (@godlytalias) Thanks for your responses.
I am not using BackgroundTaskRegistrationGroup and I'm not removing those mapping values from the LocalSettings, just wanted to get a better understanding of how this works.

If an app explicitly removes these LocalSettings values, then background task won't execute (it will throw exception as the lookup fails).

From what I see, the mapping value is present and can be retrieved in the main app and it appears to contain the correct Guid.

This would happen even if users explicitly removes background task execution permission for the application. Whether you're noticing any of these cases?

I didn't understand this part. What exactly happens when a user removes background task execution permission? I'd expect the app not to throw an exception and crash in that situation. In my case, I have not removed this permission, yet I'm seeing those crashes

Use WinDbg (from Microsoft Store) to open the dmp file, and then run the !dse command and it should list the stowed exceptions.

Thanks - I now see the exact same stack trace that you posted - same offsets also!

I have not found a workaround for the issue yet... especially since the error code makes no sense at all: 0x8007001F (FACILITY_WIN32 - Win32 Undecorated Error Codes): A device attached to the system is not functioning. Why would this HRESULT be returned when reading a value from a ApplicationData.Values IMap? Maybe they also misused the error code, thinking it would be a "general" error since it's defined as ERROR_GEN_FAILURE.

How were you able to identify this line as the source of the crash (sorry, I have very little experience in symbolicating stack traces)? Can we be sure it's not caused by the GUID unboxing?

It's certainly a very weird bug. I have a two apps that use background tasks and I have multiple instances of each installed on my machine. For some app instances, the background task works consistently, while for other app instances, it crashes consistently - from what I can tell across Windows restarts. I have not yet found out what the differentiating factor is.

From the machines that are having crashes, Can you open Diagnostic Data Viewer and share me the Bucket Id of the crash?

Godly T.Alias (@godlytalias)

Godly T.Alias (@godlytalias) sure, here's the ids:

Machine 1:
App1:
Bucket ID: 339e97a4dc872199c3b32f93dc2fbe23 (1419530619652652579)

App2:
Bucket ID: 6ae47c90b9c8ba7310c13ab1a8683deb (1207310709821029867)
Bucket ID: 2f065eaf722e34639625569ee319dcc3 (1595776883387653315)
Bucket ID: b719a17bae38347aaaafd1c66f34e0fc (1922986216109957372)
Bucket ID: 4b7df6f9140aec0d48b7146a9de9e5f3 (1780914625796761075)

Machine 2:
App1:
Bucket ID: f41973ca1ff1b5855ea0768be25c5a9c (2206894160581778076)
Bucket ID: 0e1fe4eff60852ea4baa08a5b44a75d1 (1993415292852270545)

App2:
Bucket ID: b99f2402634781405772c994b5b01c5d (1689634450757917789)

As I said before, on the same machine one instance of my app works without issue, while another one (that is installed side-by-side) crashes. Or is this not supported since both app instances are using the same Background Task Guid? What would be the expected behavior in such a case?

Here some more Bucket IDs:
Bucket ID: 46305015d38f30663aad5f8d8a748c0d (1922297677474991117)
Bucket ID: 396bcf2984d63350a456c3d7c3d7c5eb (1465574060226758123)
Bucket ID: 35aeeb6293f71175bf09cb27a9318747 (2236542061168920391)

Timo Partl (@tipa)

Timo Partl (@tipa) I used following command: ln Microsoft.Windows.ApplicationModel.Background.UniversalBGTask.dll+0x2c But I'm no WinDbg expert either, so no guarantees here.

It looks like the exceptions stopped for me (at least for the moment) once I uninstalled one of the app instances that used the same background task guid. So this can be one way to reproduce the crash: installing multiple apps that register their background task using the same guid. I'm assuming only the background task of one app will run successfully, while the others fail. I think this could be handled more gracefully, perhaps throwing an exception when registering a background task with a guid that's already taken?

That being said, this does not explain why I see so many crash reports in the Partner Center and why users are reporting that background task functionality is not working (like SystemTrigger with SystemTriggerType.UserPresent and SystemTriggerType.UserAway). I'm distributing two variants of my apps that use the same background task guid - one for the Microsoft Store and one for sideloading - but it's very unlikely that many users have them both installed.

Maybe there's a way to ensure that every app has a truly unique background task guid? Hypothetically, another developer could break my app's background task by releasing an app that uses the same background task guid.
And is storing the guid in the LocalSettings really necessary or could it be retrieved from the app registration/appxmanifest? It's currently not documented that clearing the LocalSettings would break the background task

Using unique GUIDs has solved my problem. Closing the issue

I'm still seeing thousands of crashes for my apps every day. They are reported as both "ACCESS_VIOLATION" (the large majority) as well as "STOWED_EXCEPTION" (still several hundreds) in the Partner Center.
What are my options? Should I open a new issue?

Timo Partl (@tipa)

Timo Partl (@tipa) Can you mention which is the app? Earlier when I went through majority of the crash stacks with ACCESS_VIOLATION, it was all related to COM class registration (When background task tries to invoke the COM class passed in background task registration, the CoCreateInstance of the COM class fails)

Godly T.Alias (@godlytalias)

Godly T.Alias (@godlytalias) The apps I am seeing the crashes for are WorkingHours & SubTotal

I did implemented the following workarounds in my latest app versions, but the crashes persist:

using unique CSLID, but keep old background task registration with old CSLID in appxmanifest
completely clear and re-register all background tasks the first time the app is launched (either by the user or through the old background task registration)

This is the code I am using to register my background class:

In my App.xaml.cs constructor:

NativeMethods.CoRegisterClassObject(typeof(BackgroundTask).GUID, new BackgroundTaskFactory(), 0x4, 0x1, out _);

NativeMethods.cs:

[LibraryImport("ole32.dll")]
public static partial int CoRegisterClassObject(
    in Guid classId, [MarshalAs(UnmanagedType.Interface)] IClassFactory objectAsUnknown,
    uint executionContext, uint flags, out uint registrationToken);

BackgroundTask.cs:

[ClassInterface(ClassInterfaceType.None)]
[Guid("MYGUID")]
sealed partial class BackgroundTask : IBackgroundTask
{
    [MTAThread]
    public async void Run(IBackgroundTaskInstance taskInstance)
    {
        // ...
    }
}

BackgroundTaskFactory.cs

[GeneratedComClass]
internal sealed partial class BackgroundTaskFactory : ComClassFactoryBase
{
    public override Guid GetClsid() => typeof(BackgroundTask).GUID;

    public override nint CreateInstancePtr() => MarshalInspectable<IBackgroundTask>.FromManaged(new BackgroundTask());
}

ComClassFactoryBase.cs

internal abstract class ComClassFactoryBase : IClassFactory
{
    const uint CLASS_E_NOAGGREGATION = 0x80040110u;
    const uint E_NOINTERFACE = 0x80004002u;
    static readonly Guid IID_IUnknown = new("00000000-0000-0000-C000-000000000046");

    public abstract IntPtr CreateInstancePtr();
    public abstract Guid GetClsid();
    public uint LockServer(bool lockServer) => 0;
    public uint CreateInstance(IntPtr pUnkOuter, in Guid riid, out IntPtr ppvObject)
    {
        if (pUnkOuter != IntPtr.Zero)
        {
            ppvObject = IntPtr.Zero;
            return CLASS_E_NOAGGREGATION;
        }

        if (riid != GetClsid() && riid != IID_IUnknown)
        {
            ppvObject = IntPtr.Zero;
            return E_NOINTERFACE;
        }

        ppvObject = CreateInstancePtr();
        return 0; // S_OK
    }
}

[GeneratedComInterface, Guid("00000001-0000-0000-C000-000000000046")]
public partial interface IClassFactory
{
    [PreserveSig] uint CreateInstance(IntPtr pUnkOuter, in Guid riid, out IntPtr ppvObject);

    [PreserveSig] uint LockServer([MarshalAs(UnmanagedType.Bool)] bool fLock);
}

Also, this is the stack trace I see for the STOWED_EXCEPTION crashes

"Frame"	"Image"	"Function"	"Offset"
"0"	"combase.dll"	"RoOriginateLanguageException"	"0x0000000000000000"
"1"	"Microsoft.Windows.ApplicationModel.Background.UniversalBGTask.dll"	"winrt::hresult_error::originate"	"0x0000000000000000"
"2"	"Microsoft.Windows.ApplicationModel.Background.UniversalBGTask.dll"	"winrt::hresult_no_interface::hresult_no_interface"	"0x0000000000000000"
"3"	"Microsoft.Windows.ApplicationModel.Background.UniversalBGTask.dll"	"winrt::Microsoft::Windows::ApplicationModel::Background::UniversalBGTask::implementation::Task::Run"	"0x0000000000000000"
"4"	"Microsoft.Windows.ApplicationModel.Background.UniversalBGTask.dll"	"winrt::impl::produce_winrt::Microsoft::Windows::ApplicationModel::Background::UniversalBGTask::implementation::Task,winrt::Windows::ApplicationModel::Background::IBackgroundTask_::Run"	"0x0000000000000000"
"5"	"biwinrt.dll"	"Windows::ApplicationModel::Background::CBackgroundTaskInstance::RunInternal"	"0x0000000000000000"
"6"	"biwinrt.dll"	"Windows::ApplicationModel::Background::CBackgroundTaskInstance::Run"	"0x0000000000000000"
"7"	"twinapi.appcore.dll"	"Windows::ApplicationModel::Core::BackgroundTaskWrapper::ThreadProc"	"0x0000000000000000"
"8"	"ntdll.dll"	"TppWorkpExecuteCallback"	"0x0000000000000000"
"9"	"ntdll.dll"	"TppWorkerThread"	"0x0000000000000000"
"10"	"kernel32.dll"	"BaseThreadInitThunk"	"0x0000000000000000"
"11"	"ntdll.dll"	"RtlUserThreadStart"	"0x0000000000000000"

Godly T.Alias (@godlytalias)

Godly T.Alias (@godlytalias) Have you been able to gather additional information? Do you see a problem in my code?
Please consider silently failing in the backgroundtaskhost.exe and not crashing the app. Those crashes are completely destroying my Health report in the Partner Center

Timo Partl (@tipa)

Timo Partl (@tipa) I did check to some of the cabs for these apps and the issue seems to be with COM object activation (CoCreateInstance returning failure)
btw you mentioned that you're doing CoRegisterClassObject in the app.xaml.cpp, Whether this is getting invoked at the point when a background task is triggered? If not, the registration won't be happening and CoCreateInstance would fail

Yes the CoRegisterClassObject call happens in my apps constructor, directly after some initialization code that needs to run before the background task can be called.
Why could the CoCreateInstance method fail and only fail for a small (but still significant) part of my users? And why does it cause a crash of my app instead of the background task simply not running? Isn't it possible to ignore the activation failure in backgroundtaskhost.exe?
In order to have a single-instanced app, I am also using this code:

class Program
{
    [STAThread]
    static void Main()
    {
        try
        {
            var keyInstance = AppInstance.FindOrRegisterForKey("main");
            if (keyInstance.IsCurrent)
            {
                keyInstance.Activated += (_, e) => App.ShowMainWindow();
                Application.Start(p =>
                {
                    var context = new DispatcherQueueSynchronizationContext(MainThread.MainDispatcherQueue);
                    SynchronizationContext.SetSynchronizationContext(context);
                    _ = new App();
                });
            }
            else
            {
                var args = AppInstance.GetCurrent().GetActivatedEventArgs();
                var redirectEventHandle = NativeMethods.CreateEvent(IntPtr.Zero, true, false, null);
                Task.Run(() =>
                {
                    keyInstance.RedirectActivationToAsync(args).AsTask().Wait();
                    NativeMethods.SetEvent(redirectEventHandle);
                });
                NativeMethods.CoWaitForMultipleObjects(0, 0xFFFFFFFF, 1, [redirectEventHandle], out _);
            }
        }
        catch (Exception e) { }
    }
}

I'm aware that sometimes AppInstance.FindOrRegisterForKey() can fail.
I currently try-catch those exceptions (see my example code) in which case CoRegisterClassObject isn't called (because I don't create an App instance). Would this also cause the crash we're seeing? Even if the answer is yes, I am seeing so many crashes for my app, I am uncertain if this can be the only reason for the amount of failures I am seeing in the Partner Center

ssparach

ssparach This is clearly not a WinUI issue?

Godly T.Alias (@godlytalias)

Godly T.Alias (@godlytalias) I migrated another app to WinUI and made sure there is a unique CSLID - yet the ACCESS_VIOLATION crashes appear again. There must be some sort of bug. What are my options? Should I raise another issue? If so, should I file it here in microsoft/microsoft-ui-xaml or in microsoft/WindowsAppSDK (where I think it belongs)?
For my WorkingHours app I am seeing almost 10k crashes coming from the background task per day - and it keeps increasing. This is just not something I can leave as-is

Since the crashes did not stop after upgrading to WinAppSDK 1.8, I filed a new issue here

Navigation Menu

Repository navigation

UniversalBGTask crashes with 0x8007001F #10769

Describe the bug

Steps to reproduce the bug

Expected behavior

Screenshots

NuGet package version

Packaging type

Windows version

IDE

Additional context

12 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

UniversalBGTask crashes with 0x8007001F #10769

Description

Describe the bug

Steps to reproduce the bug

Expected behavior

Screenshots

NuGet package version

Packaging type

Windows version

IDE

Additional context

Activity

tipa commented on Aug 5, 2025

tipa commented on Aug 7, 2025

BernhardMarconato commented on Aug 7, 2025

tipa commented on Aug 7, 2025

godlytalias commented on Aug 7, 2025

BernhardMarconato commented on Aug 7, 2025

tipa commented on Aug 7, 2025

godlytalias commented on Aug 7, 2025

tipa commented on Aug 7, 2025

BernhardMarconato commented on Aug 7, 2025

BernhardMarconato commented on Aug 7, 2025

tipa commented on Aug 7, 2025

12 remaining items

BernhardMarconato commented on Aug 20, 2025

tipa commented on Aug 28, 2025

godlytalias commented on Aug 28, 2025

tipa commented on Aug 28, 2025

tipa commented on Aug 31, 2025

godlytalias commented on Sep 2, 2025

tipa commented on Sep 2, 2025

whiskhub commented on Sep 8, 2025

tipa commented on Sep 23, 2025

tipa commented on Sep 29, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions