This may not help, but why not use dependency injection to end up with a method more like the following, and I'd make it an async method (note: I have not checked this against intellisense or anything):

public async Task<Account?> GetAccountAsync(Guid? userID)
{

    try
    {
    	if (userId == null || userId == Guid.Empty)
    		throw new ArgumentNullException("userId should not be null.");
    			
        using BtDbContext context = _dbContextFactory.CreateDbContext();
        Account? account = await context.Accounts.SingleOrDefaultAsync(c => c.UserId.Equals(userID));
        return account;
    }
    catch (ArgumentNullException ex)
    {
    	_errReport.LogErr(ex);
    }
    catch (Exception ex)
    {
        _errReport.LogErr(ex);
    }
    
    return null;
}

This is assuming _dbContextFactory and _errReport are private readonly variables and defined in the constructor through dependency injection.

selliot - I am not really clear on what you are saying here.  I use DI to inject the factory and then create the context from the injected factory, which seems to be what you are suggesting here.  Are you saying I need to implement Async methods throughout?

I can add that this post describes my issue in a different way but for the same reason:

https://github.com/dotnet/aspnetcore/issues/41771

Yeah, it just didn't look like you needed to pass the factory into the method, since it looked like it was already available in the class as _dbContextFactory.

The benefit to using asynchronous methods is it doesn't lock the threads and wait for operations to complete first. This is important when trying to perform multiple requests at the same time. If that doesn't work, you may want to check the IIS settings at the host to see if there is a very low limit set for how many threads can be used by the application. This is just a guess though, since I haven't ran into this issue myself.

While I am sure your observations are quite valid in other contexts, I am not so sure that they apply here - I do not have any concurrent operations.  All operations are procedural in that they do not take place in parallel.  So it is not clear that async methods will matter.  I will look at testing this, I now have a complete test harness separated from the actual project so can do a lot more disruptive testing.  For example, it was suggested that I try using Scoped instead of Transient for my Services.  This appeared to improve things on my IIS Test server on the same machine as I develop on, but when I published to my test server it failed just as quickly.  I will review the threads setting you mentioned to see if it has any impact.

Thanks!