OOP Background Task doesn't run in WinUI3/WinAppSDK desktop app when selfcontained and no dotnet installed

[JosHuybrighs]

Describe the bug

I have a beta version available of my WinUI3/WinAppSDK desktop app for a restricted set of users via Microsoft Store Package Flights. One of the users reports that none of the 4 background tasks in the app are executed. The 4 type of tasks are: a 15 minutes timer triggered task, a portable device watcher task, a session connect watcher task, and a package update task. All 4 are OOP BG tasks and run without issues on the other user's machines. The manifest file of course is correctly set up with the necessary entries:

<Application>
   <Extensions>
        <Extension Category="windows.backgroundTasks" EntryPoint="SyncFolder.BackgroundTasks.ScheduleBackupTask">
          <BackgroundTasks>
            <Task Type="timer"/>
          </BackgroundTasks>
        </Extension>
        <!--Register session connected background tasks-->
        <Extension Category="windows.backgroundTasks"  EntryPoint="SyncFolder.BackgroundTasks.ExecWhenSessionConnectedTask">
          <BackgroundTasks>
            <Task Type="systemEvent"/>
          </BackgroundTasks>
        </Extension>
        <!--Register portable device watcher background tasks-->
        <Extension Category="windows.backgroundTasks" EntryPoint="SyncFolder.BackgroundTasks.PortableDeviceWatcherTask">
          <BackgroundTasks>
            <Task Type="deviceUse"/>
          </BackgroundTasks>
        </Extension>
        <!--Register update background tasks-->
        <Extension Category="windows.updateTask" EntryPoint="SyncFolder.BackgroundTasks.UpdateTask"/>
...

And:

  <Extensions>
    <Extension Category="windows.activatableClass.inProcessServer">
      <InProcessServer>
        <Path>SyncFolder\WinRT.Host.dll</Path>
        <ActivatableClass ActivatableClassId="SyncFolder.BackgroundTasks.ScheduleBackupTask" ThreadingModel="both"/>
      </InProcessServer>
    </Extension>
    <Extension Category="windows.activatableClass.inProcessServer">
      <InProcessServer>
        <Path>SyncFolder\WinRT.Host.dll</Path>
        <ActivatableClass ActivatableClassId="SyncFolder.BackgroundTasks.ExecWhenSessionConnectedTask" ThreadingModel="both"/>
      </InProcessServer>
    </Extension>
    <Extension Category="windows.activatableClass.inProcessServer">
      <InProcessServer>
        <Path>SyncFolder\WinRT.Host.dll</Path>
        <ActivatableClass ActivatableClassId="SyncFolder.BackgroundTasks.PortableDeviceWatcherTask" ThreadingModel="both"/>
      </InProcessServer>
    </Extension>
    <Extension Category="windows.activatableClass.inProcessServer">
      <InProcessServer>
        <Path>SyncFolder\WinRT.Host.dll</Path>
        <ActivatableClass ActivatableClassId="SyncFolder.BackgroundTasks.UpdateTask" ThreadingModel="both"/>
      </InProcessServer>
    </Extension>
  </Extensions>

Event viewer on the user's computer gives the following error (in the BackgroundTaskInfrastructure section) for any of the 4 tasks when it tries to trigger them (next example is for the 'deviceUse' task, and translated from Dutch):

An instance of the background task with the access point SyncFolder.BackgroundTasks.PortableDeviceWatcherTask executed for the user ML\mlgoos in session 422859 was returned with error code 0x80008083.

Did also a test with enabling diagnostics in BackgroundTaskInfrastructure. These are the events being logged when a USB flashdrive is inserted (again translated from Dutch):

An activation of a background task with access point SyncFolder.BackgroundTasks.PortableDeviceWatcherTask and name WatchPortableDevices has been placed in the buffer because 2560 has been taken out of the buffer.

An activation of a background task with access point SyncFolder.BackgroundTasks.PortableDeviceWatcherTask and name WatchPortableDevices has been placed in the buffer because 2560 has been taken out of the buffer.

An instance of a background task with access point SyncFolder.BackgroundTasks.PortableDeviceWatcherTask and name WatchPortableDevices was created in session 422859. This was given the id {adac4dc8-f853-40f1-8b45-f562b364fd71}.

An instance of the background task with the access point SyncFolder.BackgroundTasks.PortableDeviceWatcherTask executed for the user ML\mlgoos in session 422859 was returned with error code 0x80008083.

The fault occurs on Windows 10, build 19045.3930.

I looked around what 0x80008083 could mean but with no luck. Could it have something to do with OOP BG triggering and the WinRT.Host.dll that is part of the package? Wrong version?

I also checked on another Windows 10 machine with the same build but don't see any issue there. Must however say that on that machine I installed VS Remote tools for debugging. So there might be some packages installed that prevent that the error occurs.

The error occurs on the user's machine when installing from the Microsoft Store but also when sideloading the .msix package.

Any idea?

Steps to reproduce the bug

Register for participating in the beta test of the SyncFolder app and install SyncFolder from the Microsoft Store.

Expected behavior

No response

Screenshots

No response

NuGet package version

Windows App SDK 1.4.4: 1.4.231219000

Packaging type

Packaged (MSIX)

Windows version

Windows 10 version 22H2 (19045, 2022 Update)

IDE

Visual Studio 2022

Additional context

No response

[DarranRowe]

I found a reference to this error code in the dotnet/runtime github repository. It was in a file named host-error-codes.md. That doesn't mean that it is this CoreHostLibMissingFailure error though.
I think your best course of action is to see if you could get a crash dump from the customer.

[JosHuybrighs]

@DarranRowe
Thanks for the prompt answer.

I activated crash dump on the computer but no dump is being generated. I had 'taskbackgroundHost.exe' as key in the registry.

Then started to look deeper in the Windows 10 computer and don't find any of the mentioned dotnet dlls (coreclr, hostfxr, hostpolicy) in there.
Is this normal on a non-developer client computer? On my computers I see these files in various folders and so I am wondering whether this is because I have VS and/or Remote tools installed there.
I can for instance execute 'dotnet' in command prompt on my machines but not on the user's machine. It comes back with 'dotnet' not understood.

Shouldn't a MSIX package install everything that is needed and/or complain when there are some core dlls missing. The strange thing is that the app itself (.NET6) runs without problems. Only OOP background tasks don't run.

[DarranRowe]

Is this normal on a non-developer client computer?

Yes. The dotnet executable is part of the .NET (.NET core) runtime. This doesn't come pre-installed with any of the release versions of Windows. Visual Studio installs this and the .NET SDK when you install any of the .NET workloads. So it is not surprising for a developer system to have dotnet.exe but a non developer system to not have it.

Shouldn't a MSIX package install everything that is needed and/or complain when there are some core dlls missing.

This is a very much a no.
When Windows installs a MSIX package, the dependencies it checks for are those listed in the package manifest file. If a dependency isn't listed then Windows will not know that the package depends on something. It is possible to experiment with this easily. There are two easy examples of this. The first is to write a C++ application that uses C++ features and then package this up. But make sure that you do not include the dependency on the C++ desktop runtime. Windows will not complain about a lack of dependencies, but the package will not run on a clean install of Windows. The second is .NET.
The issue here is that .NET works in an interesting way. If you look at the package manifest for applications that depend on .NET 5 or newer created using the WinUI 3 templates, then you should see that there is no listed dependency for a .NET runtime. As far as I'm aware, there is no framework package for the newer .NET versions either. This means that the runtime must be available in some other way. The options generally are:

1. Have a system installation of .NET.
2. Have the files available locally in the package.
3. Compile everything to native code to remove the dependency.

The WinUI 3 projects choose option 2, the .NET runtime is placed in the MSIX package. With how the packaging works, Windows should never end up with an incomplete package install either. There should be an integrity check for the files on install. So the interesting situation here is that if you take any .NET 5 or newer application (even without WinUI 3/Windows App SDK), package this up but do not publish it as self contained then the application will require a system installation of .NET to run.
Option 3 was available for UWP applications (.NET Native), but this option still isn't completely there for .NET. Native AOT is available in .NET 8, but it can't just be enabled. For WinUI 3, the C# projection is something that would need to be made AOT compatible. The 1.4 projection isn't, but 1.5 should be. There have been commits to CsWinRT's repository fixing bugs.

I suppose one other means of testing this situation is to have a machine with a clean Windows 10 install on it. Make sure to never install .NET or Visual Studio. Then sideload your package and try it out. Hopefully this should place you in the same situation. If it does fail in that situation, another test is to then install the .NET runtime that matches the application's .NET version on the system. If it then works, this would show that the background task engine in Windows isn't using the packaged version of .NET.
Reproducing this issue in a controlled environment is the first step, unfortunately.

I activated crash dump on the computer but no dump is being generated. I had 'taskbackgroundHost.exe' as key in the registry.

IIRC, .NET uses its own unhandled exception handler and this ignores the registry. Have you tried using the instructions here?

[JosHuybrighs]

@DarranRowe
I fully agree but given the number of external package dependencies I have it will probably be a challenge to start doing this today. Earlier I did already some tests with trimming. According to what I know about .NET 8 this is then mandatory but in my tests this was not a success . There is still a lot of dynamic binding in my XAML files that requires rework and some external libraries also didn't work well.

Anyhow, .NET 8 and Native AOT is indeed the way forward and I will look into this as soon as I have the current beta version of my app in a state where it can become the release version.

[rndl0304]

Hello. Regarding this solution "NativeHost project that @jlaanstra made available in a branch" is it working? Could you give more demais, please?

[JosHuybrighs]

@rndl0304

Hello. Regarding this solution "NativeHost project that @jlaanstra made available in a branch" is it working? Could you give more demais, please?

Yes, it is working. I actually still use it to implement the UpdateTask in my app. An UpdateTask in WinAppSDK is automatically executed when the app is being updated. Depending on the update one sometimes might have to do something in the app's repository to make it compliant with the new version. That is why I need such a background task. And, unfortunately it can only be an OOP task.

What you have to do then is to add 2 projects to your package:

• The "NativeHost" project of @jlaanstra.
• The OOP task project. That must be a WinRT project and consequently will have some issues for most people if there is a need to reuse code from the main project. That code can't be shared and so you have to 're-code' these classes in the WinRT project to be valid for WinRT.

When done, you must add the OOP background task to the appxmanifest file of your package. Like so:

  <Applications>
    <Application Id="App"
      Executable="$targetnametoken$.exe"
      EntryPoint="$targetentrypoint$">
      <uap:VisualElements DisplayName="SyncFolder"
						  Description="SyncFolder - v2"
						  BackgroundColor="transparent"
						  Square150x150Logo="Images\Square150x150Logo.png"
						  Square44x44Logo="Images\Square44x44Logo.png">
        <uap:DefaultTile Wide310x150Logo="Images\Wide310x150Logo.png"/>
        <uap:SplashScreen Image="Images\SplashScreen.png" />
      </uap:VisualElements>

      <Extensions>
        <!--Need a fullTrustProcess because SyncFolder.exe must be called by a background task/process-->
        <desktop:Extension Category="windows.fullTrustProcess" Executable="SyncFolder.exe">
            <desktop:FullTrustProcess>
            <desktop:ParameterGroup GroupId="ExecTasksRequest" Parameters="--execReq" />
			...
          </desktop:FullTrustProcess>
        </desktop:Extension>

        <desktop:Extension Category="windows.startupTask"
                           Executable="SyncFolder.BackgroundServices.exe"
                           EntryPoint="Windows.FullTrustApplication">
          <desktop:StartupTask TaskId="BackgroundService"
                               Enabled="true"
                               DisplayName="SyncFolder Services" />
        </desktop:Extension>

        <!--Register toast notifications CLSID and COM server-->
        <!--Specify which CLSID to activate when toast clicked-->
        <desktop:Extension Category="windows.toastNotificationActivation">
          <desktop:ToastNotificationActivation ToastActivatorCLSID="ff91078c-37e0-4d32-aab3-4b4966ae55e8" />
        </desktop:Extension>
        <!--Register the COM ToastActivator CLSID with a comServer in order for the comServer to be able to launch the app when a toast message is clicked-->
        <com:Extension Category="windows.comServer">
          <com:ComServer>
            <com:ExeServer Executable="SyncFolder.exe" Arguments="----AppNotificationActivated:" DisplayName="Toast activator">
              <com:Class Id="ff91078c-37e0-4d32-aab3-4b4966ae55e8" DisplayName="Toast activator"/>
            </com:ExeServer>
          </com:ComServer>
        </com:Extension>

        <!--Register InProc COM background tasks-->

        <!--Register OOP C#/WinRT background tasks-->
        <!--Register update background tasks-->
        <Extension Category="windows.updateTask" EntryPoint="SyncFolder.BackgroundTasks.UpdateTask"/>

      </Extensions>

    </Application>
    
  </Applications>

  <!-- To host the OOP C#/WinRT background task components, you must add these activatable class entries -->
  <Extensions>
    <Extension Category="windows.activatableClass.inProcessServer">
      <InProcessServer>
        <Path>NativeHostNE.dll</Path>
        <!--<Path>WinRT.Host.dll</Path>-->
        <ActivatableClass ActivatableClassId="SyncFolder.BackgroundTasks.UpdateTask" ThreadingModel="both"/>
      </InProcessServer>
    </Extension>
  </Extensions>

In the Applications section you must specify your background task (UpdateTask in my case).
In the Extensions section you must add an entry for each WinRT InProcessServer, with the NativeHostNE.dll.

Depending on the type of OOP background task you might also need to register that task in your main app. For UpdateTask this is not required, but for other type of tasks like timer, systemEvent, etc. it will be.

You can find the NativeHost and UpdateTask project I am using here.

Note: my app builds against .NET 6. I can't help you with .NET 8.

Wish you success with this. But, as I replied earlier if you want to do serious work in a background task I am not sure if this is the right way to go. For an UpdateTask this is still relatively simple (and the only way to go) but if you consider adding lots of services in your background tasks then you will soon or later find out that it is hard to do.

[rndl0304]

Hello @JosHuybrighs thank you for your advise. Today I can find the dependency need to execute the background task using WinRT.Host.dll. My project use .net6 and I need install the .net desktop runtime version 6.0.33. After install this, the background task is running always. I tested using .net8 and it working too. I installed desktop runtime version 8.0.0. Now, my question, how can I add this instalation in package application?

[JosHuybrighs]

@rndl0304
Are you saying that you are still using winrt.host.dll? If so then, as this github issue is explaining, it will not work when .net is not available on the target device. At least when winrt.host.dll has not been updated the last year, which I don’t know because I don’t use it anymore.
If you still see the .net missing error today on a windows machine then you need to deploy self-contained and with the NativeHost project I mentioned.

[JozefGula]

I have the same problem. My WinUI 3 application does not start any background task. I do not see any error or problem, but it does not work.

[JosHuybrighs]

@ppoirier1

So you are saying you can't use CsWinRT to generate the WinRT component?

No, you can create OOP background tasks with CsWinRT. What I want to say is that if you do so and your app/package must be selfcontained (what I assume everyone wants) that you must not package the app with the winrt.host.dll file in the InProcessServer (as Microsoft explains) but instead must use the NativeHostNE.dll file from @jlaanstra, available here. When you have the winrt.host.dll in the server then self-contained will not work. It needs some stuff of .NET that will not be available on a standard Windows device.

The manifest file must have an entry like the following:

<Extensions>
    <Extension Category="windows.activatableClass.inProcessServer">
      <InProcessServer>
        <Path>NativeHostNE.dll</Path>
        <!--<Path>WinRT.Host.dll</Path>-->
        <ActivatableClass ActivatableClassId="SyncFolder.BackgroundTasks.UpdateTask" ThreadingModel="both"/>
      </InProcessServer>
    </Extension>
  </Extensions>

The above is for an OOP update task.

It will work but it is not my favorite mainly because building the BG task in a CsWinRT library is less than ideal if the task is big and you want to re-use code from your host project. A CsWinRT component poses restrictions on namespaces, method declarations, etc.

Disclaimer: I haven't included the latest winrt.host.dll in my package and so I am not sure if the above is still true.

What also bothers me: why isn't anyone from Microsoft reacting on this?

[rndl0304]

Hello Guys,

I my case, I add a rotine to install the .net dependency. In my case I am using .net 8. When I installed the.NET Desktop Runtime 8.0.10 the background task is launch is working for me. I added in my application the flow to user install the installer.

You can install the dependency using powershell script in C#.

[rndl0304]

I tried use NativeHostNE.dll instead WinRT.Host.dll with selfcontained app/package but it is not working for me. My solution was install the .net desktop runtime dependency in runtime.

[ppoirier1]

CsWinRT and the resultant WinRT.Host.dll worked fine except for this problem. The host and background task executables are in the same directory as the .NET assemblies (because the host is self-contained). So I'm guessing there's a manifest or .deps.json problem with the background task. NativeHostNE doesn't work for me either, nor would it be possible for the user to install .NET manually because the first interaction could be via a background task that doesn't load.

What also bothers me: why isn't anyone from Microsoft reacting on this?

@JosHuybrighs , since you filed the original issue as a bug, can you reactivate it as a bug?

[JosHuybrighs]

@ppoirier1

CsWinRT and the resultant WinRT.Host.dll worked fine except for this problem. The host and background task executables are in the same directory as the .NET assemblies (because the host is self-contained)

Do you say that WinRT.Host.dll works fine when self-contained? I am on .NET 6 and when I posted this discussion topic it definitely didn't work on .NET 6. That's why I have to use NativeHostNE.
Now, things might have been changed the last months so I cannot be 100% sure if WinRT.Host.dll with self-contained is still an issue in .NET 6. I also don't know the situation with .NET 8 because I am reluctant to migrate my package to .NET 8.

Why is it a problem that the host and background task dll or in the same directory as the .NET assemblies?

[ppoirier1]

Hi @JosHuybrighs , sorry if that wasn't clear, "except for this problem" means that it doesn't work self contained. It's not a problem that the assemblies are in the same directory. If all the DLLs are in the same folder then the only reason I can think it wouldn't work is some manifest problem. Anyway, the point of this is that the original bug should be reactivated. If that's not possible then I can prepare a new sample project and post a new bug.

[JosHuybrighs]

@ppoirier1

I did a quick rescan of what I discovered beginning of the year and want to point to Self-contained WinRT components don't work. You can also read about NativeHostNE there. Looks like this topic is still open what makes me think that the issue is:

• Known by Microsoft.
• Still open.
• Not a WinAppSDK issue but a CsWinRT issue.
• Of little importance for Microsoft (to say it politely) when considering the date the issue originately has been posted (March 2022).

You can post a new bug report of course but I have the feeling that the WinAppSDK people look at the CSWinRT people to solve it. I also made a suggestion yesterday in WinAppSDK 1.7 Plans to improve support for background tasks.