We are deploying our new .NET Core Wep Api through TeamCity and Octopus, it runs on Kestrel behind IIS. Everything is fine except that the first request takes about 2 minutes. That is, the first request after deploy and the first request after restarting the site on IIS.
To publish the app we use
dnvm use 1.0.0-rc1-update1 -a x64
dnu publish --configuration release --runtime active --no-source --include-symbols
Older apps on the same IIS Instance take about 15sec to respond to the first request.
Our .NET Core app responds after about 15 seconds when running it purely on Kestrel from the same actual code that is deployed to IIS.
What is happening for the remaining 1m45s - why is it taking so long?
How can we go about to debug this?
Update:
As it turns out, IIS is unable to shut down the Kestrel process (dnx.exe) gracefully. It crashes with the following error:
Unhandled exception at 0x00000000776E298A (ntdll.dll) in w3wp.exe: 0xC000070A: Status 0x (parameters: 0xFFFFFFFFC0000008, 0x0000000000000324, 0x000000000167D930, 0x0000000000277520, 0x000007FEE60388F4).
If I terminate the dnx.exe process manually and then restart the site it starts up quite fast, so my theory is that the Octopus deploy step somehow encounters the same exception and IIS has to wait for the host process to time out before it spawns a new working process.
How can I make IIS shut down the dnx process gracefully? How can I get a more understandable exception from IIS?
The cause of the problem was that IIS was unable to gracefully stop the dnx process running Kestrel, and had to wait for it to timeout in order to get a working one running.
To work around this we added a PowerShell script to stop the dnx process manually as the first step of the Octopus Deploy process:
Stop-Process -processname dnx -ErrorAction SilentlyContinue -Force
As to why IIS is unable to gracefully terminate the worker process and how to fix that I still have no idea.
Related
I have a .NET Core 3.1 console app I have deployed to server and setup as a windows service. I can open cmd window as admin and navigate to the exe and it runs the exe with no errors or issues.
However when I try to start the Windows Service it immediately fails with an error:
Windows could not start the service on the local computer. Error 1053: The Service did not respond to the start or control request in a timely fashion.
We have ServicesPipeTimeout set to 180000
and rebooted server but it still fails immediately. Shouldn't it take time before the timeout error comes up?
I have also ensured we have the Release version of the code as I found posting saying Debug versions of code will cause this issue.
The folder permissions are as follows:
Since the console app runs fine from the command prompt there should not be an issue with the code/framework on the system?
Is there anything else to check?
Is there any special CHMOD or any permission necessary to make an ASP NET MVC under .NET Core 2.0 log? On my windows dev machine the log is generated normally but not on my production machine.
I have an Web App running on a Ubuntu 16.04 DigitalOcean Droplet. Two days after every deploy it starts to throw a NullObjectException that I'm not able to trace properly and stops whenever I restart kestrel, even allowing the developer exception page to be shown (it is not verbose enough cuz I can't see where in my code the last call is made - it only shows native framework calls.
I have deployed my .net core 2.1 application on local IIS but I can't debug my application. I have also tried attaching with w3wp.exe process of my own created "No managed code" application pool but still can't debug my app.
Updated: I had found a solution to run dotnet.exe and my deployed process together and I succeeded one time but after that dotnet.exe disappeared from the process list and I can't find it anywhere but it exists in C:/ProgramFiles/dotnet I have also tried restarting VS but still no luck. So can I get dotnet.exe process back?
Ok, so with the help of Lex Li comments and google, I have found the solution of debugging Asp.net core app deployed on local IIS.
We need to attach with 2 processes to debug the app
dotnet.exe
devenv.exe (the title of devenv.exe would be the
same name by which our app is deployed on IIS.
Note: sometimes we might not find dotnet.exe process in the "Attach to process" list even it would be available in C:\ProgramFiles\dotnet. So we just need to refresh our IIS deployed app on browser and dotnet.exe process will be available in the list then.
I have a small .net core WebAPI service running on kestrel. This is deployed automatically on multiple machines using TFS deployments. After deployment the automation tool runs this kestrel server on each deployed machine.
I can verify that:
the application starts on each machine (dotnet process is present in Task Manager)
the application listens on the correct port (because trying to run it manually on that port throws the error that port is in use)
BUT:
for the automatically started application I cannot access the webapi service in browser (http://localhost:8081) -- says 404
if I close the dotnet process started automatically and run it manually it works ok (WebApi accessible in browser)
Why doesn't it work correctly when started automatically? The only difference between processes seems to be the user under they are executed.
How could I troubleshoot this problem?
I am currently developing a service with wcf 4.0 (visual studio 2010 RC).
When I try my service on the Visual Studio Development Server, it all works perfect.
However, when I tree to run my service on IIS7 on a windows 7 machine, the service doesn't work anymore. (I already changed the framework version on my application pool).
When I call an operation on the service, like the default operation GetData when I create a service, I get an error.
I used the WCF test client to connect to the service.
When I call the operation on the service, the Visual Studio Just-In-Time debugger shows the following message:
An unhandled win32 exception occured in w3wp.exe
The Just-In-Time debugger was launched without necessary security permissions. To debug this proces, the JIT debugger must be run as an administrator. Would you like to debug the proces?
As far as I know, I am running Visual Studio as an administrator and this is probably the process that starts the JIT debugger.
The only option I have is to debug the W3WP process, which is probably not the right thing to do.
What can I do the make the Service to run on IIS7?
I already solved my problem, it was the ApplicationPoolIdentity that was blocking everything.