You could try using DbContextFactory and create a new DbContext from the factory with each database call. This would prevent the issue with a call trying to use the DbContext before it's released from a previous call, if that's what your issue is. https://learn.microsoft.com/en-us/ef/core/dbcontext-configuration/#using-a-dbcontext-factory-eg-for-blazor 

Sorry, I did not mention directly that is exactly how I implemented the UoW short lifetime pattern.  I have a DBContext Factory that generates a DBContext which is done in a Using statement.  I have also confirmed that every context which is created is being disposed of properly, and none are being kept open for very long.  Ah!  I think I will add a timestamp to confirm the last statement.  Thanks for providing a context within which I thought of this - my biggest challenge is the complete lack of error data from which to derive a strategy.

It's difficult to say much more based on the provided information, without any kind of specific error messages or anything. 

• You could try running your application locally in Visual Studio with the debugger and set a breakpoint early enough to hit, then step through and look for anything that's unexpected. If there are any exceptions, it should display too.
• Look to see if there are any methods that aren't catching exceptions and logging them, because exceptions should log to the terminal if you run the app with "dotnet run" or "dotnet watch". On Blazor Server, Console.WriteLine() will also write to the terminal. While developing, I launch the app with "dotnet watch" 95% of the time and watch the terminal (and for WASM, since it's running in the browser, it will write to the browser console).
• I'd also try deploying the app to a free AppService tier in Azure to see if it runs okay there. It may be related to the setup of your hosting environment.
• If you are running on a machine that you can RDP into, you could launch the app from a terminal there to see if it prints out any additional information that may shed light on the issue.
• If none of this helps, maybe look through your methods to see there are any methods not handling Tasks correctly and creating deadlocks or something.

Thanks for responding!  I appreciate the help.  I have no specific error messages to provide as I am getting none from the system.  That is part of why this is such a challenge.

I have run it locally and it works perfectly, and when I attach to the code running on the server, it never throws any meaningful errors of any kind which is partly why I am so frustrated.

All methods are wrapped in Try/Catach blocks to trap all errors, that is part of why I am having such a hard time.  I have not had this kind of problem in decades so am having to dredge up old techniques I employed when normal debugging does not work.  None are producing any useful results.

I can look into the free AppService tier, but the app requires the DB and it is complex to set up, so I am trying to do things like that locally using different machines. I tested with a different DB server and it still fails.

I rdp into the machine and see everything.  No logs are showing any causes, Event Log only shows at best a vague message about an unhealthy ISAPI process.

None of my tasks are creating deadlocks - as noted, it works perfectly when run in the VS Debugger web server and only fails when run on an actual server.

If you're connecting to your current database through a connection string in appsettings.json, you should be able to deploy the application to an AppService and continue to connect to the same database, as long as the database port is open to the AppService.

I have to ask:  How is what you are suggesting any different than running it in the VS Web Server, and by extension, how is that any different from running it on my IIS10 Web Server?

I may try what you suggested at some point, as I have been looking to do more or less what you suggested anyway, and you gave me a potentially easy way to do so.  I will look into it.

In the meantime I observe that the Web Server dies after this call.  It is the first time the DBContext is actually used in the method, and this is the first DBContext to be hit in the Page.

        account = context.Accounts.SingleOrDefault(c => c.UserId.Equals(accountId));

I'm only suggesting it so you can try it in a different environment. If you can determine that it runs fine locally, and runs fine in an AppService, then you can focus more on the setup in your IIS10 web server. I'm just guessing and providing some ideas for troubleshooting. If your app isn't throwing any errors (unless they are being swallowed inside a Task.Run or something), it sounds more like an issue on your IIS10 server to me.

I do not see where I can create a free Azure Appservice.  I have an Azure Account and some familiarity with Azure as I manage an account for a client, but am not aware of where I can create a free Appservice.  Can you point me to this?  Also, how would that differ from testing on a web server on another one of my computers, which is a step I am likely to take this weekend?  I totally get the concept of testing on other systems - I am an Engineer, and that is standard operating procedure which is why I plan to test on another system here, but it could not hurt to have that ability via Azure.  

There are many videos and documentation out there for deploying to an AppService, but here's a video that shows up on YouTube: https://www.youtube.com/watch?v=vjzSzCUBXKo

When creating the AppService, you're able to select a free tier. It has limited resources, but its main purpose is for development and testing.

When you're ready to publish to the AppService, you can do so easily within Visual Studio by clicking "Build" in the top menu, then "Publish". It should launch a screen that you'll walk through to setup the deployment. More details are at this link: https://learn.microsoft.com/en-us/visualstudio/deployment/deploying-applications-services-and-components-resources?view=vs-2022#azure

There are more advanced ways to deploying to an AppService that involve a pipeline that runs tests, builds, etc. first, but this is the quickest and best option for your use-case.

Thanks!  I decided that my next step will be to try to build a fresh sample project with just the bare essentials to test the page I can use to trigger the problem.  Once I have that, if it continues to fail and I am making no further progress the next step will be to do as you suggested and try running it on an AppService.  I will have to either set up a VPN to my local SQL Server or open ports in my firewall - something I prefer not to do but can for a short duration if need be.

I have determined that the App is fine until I make the call to get data from the DBContext, and in my current implementation, the web app dies the moment I execute that line of code.  That is where I am going to be focussing my attention, why does reading the data from the data context kill the web app?