UWP query.GetItemCountAsync - Fails on mapped network drives. 'The library, drive, or media pool is empty. (Exception from HRESULT: 0x800710D2)'

If I enumerate a mapped network drive using the code below, while it takes ages and consumes 5 GB memory, it gets the job done, no errors.

var files = await folder.GetFilesAsync(CommonFileQuery.OrderByName);

If I use the query system to get the number of files, which works perfectly on a local disk, it fails on the same network mapped drive.

var fileTypeFilter = new List<string>();
var queryOptions = new QueryOptions(CommonFileQuery.OrderByTitle, fileTypeFilter);
var query = folder.CreateFileQueryWithOptions(queryOptions);
var x2 = await query.GetItemCountAsync();

The error is "System.Exception: 'The library, drive, or media pool is empty. (Exception from HRESULT: 0x800710D2)'" - which isn't useful at all. Yes I've looked this up on google and get a huge, 5 results.

Any thoughts on why this is happening ? Maybe because the local drive is indexed and the network not, but then that makes this query pointless anywhere as you can't guarantee a folder is indexed.

I figured it out, it was actually documented, but the error was not.

The original question was on why I sometimes get an error using:

var fileTypeFilter = new List<string>();
var queryOptions = new QueryOptions(CommonFileQuery.OrderByTitle, fileTypeFilter);
var query = folder.CreateFileQueryWithOptions(queryOptions);
var x2 = await query.GetItemCountAsync();

The answer is in the use of "CommonFileQuery.OrderByTitle", it doesn't work on network drives. It has to be replaced with "CommonFileQuery.OrderByName" and then it works.

Of course, performance is still dire, and the Runtime Broker memory consumption is appalling. I don't agree that consuming 5GB memory and not releasing it, is acceptable. That basically stops me using the new WinRT StorageFile/Folder, even in Win32 app on .net 5.

But the question is answered; let's hope .net 6 and WinRT can fix this :)