If you have access to the servers, make sure that the utilization of the application pool is actually registered in the event logs
cscript adsutil.vbs get w3svc / AppPools / DefaultAppPool / LogEventOnRecycle
you can configure it to record everything with cscript adsutil.vbs Install w3svc / AppPools / DefaultAppPool / LogEventOnRecycle 255
See here for more details.
Then check if there were any repetitions.
Initializing the application, creating a workflow, threads, loading the application domain and all the DLL links may take some time, which is normal, but this 1 minute delay is something else.
Try pre-compiling the application on the server and see if this helps aspnet_compiler -m / LM / W3SVC / [site ID] / Root / [your application]
If you want to dig deeper, you can check the ETW event trace.
- logman query providers
- Save the IIS / ASP.NET related Guides in a file, for example iisproviders.txt
- logman start ExampleTrace -pf iisproviders.txt -ets -rt
- play
- LogParser "SELECT * FROM ExampleTrace" -i: ETW
- logman stop ExampleTrace -ets
Here you can find more information. Troubleshooting appdomain reloads and other ETW tracing issues
I would also check w3wp.exe with procexp if it has TCP connection time or with Procmon for other tips.
If you have experience with windbg, you can make a request to the application and then quickly attach the debugger to the process
windbg -p [process id of the app pool] .loadby sos mscorwks g
and from there from there. If there are exceptions, process crashes, etc., you should catch it ...
As soon as we had such a strange server problem like this, and reinstalling .NET solved the problem, Iβm still not sure what was the culprit.