UWP registration of background task for StorageLibraryContentChangedTrigger fails with "not found"

In my UWP desktop application, I am trying to implement a function to follow changes in the images library using a background task. I followed usage examples (like this one https://docs.microsoft.com/en-us/archive/msdn-magazine/2016/december/universal-windows-platform-file-system-monitoring-in-universal-windows-platform-apps) and my code looks like that:

StorageLibrary docLib = await StorageLibrary.GetLibraryAsync(KnownLibraryId.Pictures);
            var requestStatus = await BackgroundExecutionManager.RequestAccessAsync();
            if (!(
                requestStatus == BackgroundAccessStatus.AllowedSubjectToSystemPolicy ||  
                requestStatus == BackgroundAccessStatus.AlwaysAllowed))
            {                
                return;
            }
            var builder = new BackgroundTaskBuilder();
            builder.Name = "Background task";            
            StorageLibraryContentChangedTrigger libraryTrigger = StorageLibraryContentChangedTrigger.Create(docLib);
            builder.SetTrigger(libraryTrigger);   
            var task = builder.Register();
            docLib.ChangeTracker.Enable();

My understanding is that this creates an "in-process" background task, and when the change in folder content happens the App OnBackgroundActivated() will be called, so I can process changes there. However when I call the task registration the exception is thrown. The exception is:

  System.Exception
  HResult=0x80070490
  Message=Element not found. (Exception from HRESULT: 0x80070490)

I don't understand what is happening. I have tried to replace the trigger with Time Zone Change trigger in the code above, and it works fine (registration is successful and OnBackgroundActivated code is executed) but the content change trigger does not. I have not found any examples of a similar error. I am using Windows 10, build 19041. The only thing that may be non-standard is that I have moved the location of my document libraries from C: drive to D: drive, but that is a standard feature of Windows OS, so I don't think it should cause a problem.