I am using Azure App Service hosted on linux to use a .Net Core 6.0 app.
I have a null pointer error that is resulting in a segfault, that in turn is taking down the app service. I have had a few errors that result in segfaults so while I can fix the null pointer I really want to find why the container is crashing.
I can see the the following in AppServiceConsoleLogs:
/opt/startup/startup.sh: line 17: 65 Segmentation fault (core dumped) dotnet xxx.dll
I am hoping if I can find the dumped core I might figure out the segmentation fault.
I have looked around the folders by going into the SSH console, but I cannot find anything that looks like memory dump.
Where to find coredump on Azure App Service using Linux?
I have deployed the .NET Core 6 App to Azure App service.
Navigate to Azure portal => your Deployed App Service => Advanced Tools => Go .
Click on - Site wwwroot.
Deployed files will be compiled into dll files.
Click on the file, you can see the content.
We can also check the files in Bash.
In Bash, Navigate to the Application root directory and run ls.You can see the deployed files.
In Configuration section => General Settings, check the startup command.
It has to be
dotnet YourAppName.dll
Make sure the dll is available in Bash or SSH.
Update:
We can find the core dumps in LogFiles/core folder.
But initially, it is disabled.
To enable it, we need to add the below command in Startup of the deployed app service.
ulimit -c unlimited
Thanks #Sourabh Edake for the command.
Restart the app. Whenever there is an exception, the core dump will be created in the mentioned LogFiles/core folder.
Related
I am trying to run a dotnetcore Console application in a ServiceFabric GuestExecutable Container. While I was adding this GuestExecutable service to my SF application, I cofigured as follows
Code Package Folder -> ..repos\NewDllGuestSF\CoreConsole\bin\Debug\netcoreapp2.0
Program -> CoreConsole.dll
Working Folder -> CodePackage
Here, I know I am trying to host this .dll file as my executable for the GuestExecutable service. This is what I am trying to do but could not somehow. When I tried the same with the treditional .NetFramework app and with an .exe executable, I am able to run it successfully on SF cluster. But I need to do is with dotnetcore application and of course with a dll executable.
So far I have tried is -
I can generate a dll as well as an exe while building my dotnetcore console application and use the generated .exe file in GuestExecutable. But here, I have to configure my console app to target multiple Frameworks as "netcoreapp2.0;net461", that is something I can not do for some reasons.
When I run my dotnetcore Console app with a dll executable in SF cluster, I faced the following error
Here if we see, the GuestExecutable service remains in healthy state but the application doesn't.
Can anyone please help me out on this, all I want to do is to host a .dll file as entry point in a GuestExecutable SF service.
As far as I understand you need to configure CodePackage in ServiceManifest.xml to run your .dll using external executable.
Here is the example how this could be done (please pay attention to IsExternalExecutable="true" attribute):
<CodePackage Name="Code" Version="1.0.0">
<EntryPoint>
<ExeHost IsExternalExecutable="true">
<!-- We are using dotnet cli to launch our Service.dll -->
<Program>dotnet</Program>
<Arguments>Service.dll</Arguments>
<WorkingFolder>CodePackage</WorkingFolder>
</ExeHost>
</EntryPoint>
</CodePackage>
Hope it helps.
I have an ASP.NET 4.6.1 application that I am trying to deploy to a remote web server using TeamCity and MSBuild. Below is the MSBuild build step within TeamCity.
When I run the build in TeamCity, it always fails on this build step with a FILE_IN_USE_ERROR. The DLLs that are being updated before the error are usually the same, but sometimes they are different.
[MSBuild output] Info: Updating file (MyApp\bin\roslyn\Microsoft.VisualBasic.Core.targets).
[10:35:23]
[MSBuild output] Info: Updating file (MyApp\bin\roslyn\System.AppContext.dll).
[10:35:23]
[MSBuild output] Info: Updating file (MyApp\bin\roslyn\System.Collections.Immutable.dll).
[10:35:23]
[MSBuild output] MSDEPLOY : error Code: ERROR_FILE_IN_USE [C:\BuildAgent\work\b89cd3dfa447b\MyApp\MyApp.csproj]
I've already read through many articles (here, here, here, and here) suggesting that I drop an app_offline.htm file before deploying so that the IIS can re-route traffic and the file locking issues will stop. I tried that and it doesn't work. I still get the file in use issues during this build step.
I've also read in plenty of other discussions that another solution is to stop the application pool, deploy the app updates, and start the application pool. This is not a realistic solution because the deployment usually lasts between 15 and 20 minutes. Plus, this doesn't allow me to show a nice message to any current users.
I've been reading about this for a while now and it seems like this is a common use case for deployment to an IIS web server. Shouldn't this just work without locking files? Does anybody know of any other solutions to this problem?
I would try by stopping app pool to see if that`s a root cause of the issue.
But I'm not sure why it fails on .csproj file, because usually you don`t deploy those on server. So either it fails on different file (that is actually in use by web application) or it fails during build, not deploy (than app-pool stop will have no affect).
I have a problem with hosting an ASP.NET RC1 application inside IIS.
I've read through similar issues here on the site, aswell as went through official Microsoft documentation, but to no avail. I simply cannot make the app start inside IIS8 which is a must in this scenario, as I need to use it with an SSL certificate, and no relevant logs are shown unfortunately.
App is packaged under dnx-clr-win-x86.1.0.0-rc1-update2
If I try to start it inside my local VS2015, it works flawlessly. If i run the Web.cmd on the server machine from command line, app starts without any problems. However, when I try to run it through IIS, event log catches the following.
Faulting application name: dnx.exe, version: 1.0.0.20309, time stamp: 0x56e05cbb
Faulting module name: ntdll.dll, version: 6.2.9200.21815, time stamp: 0x56eaff87
Exception code: 0xc0000374
Fault offset: 0x000db583
Faulting process id: 0xae4
Faulting application start time: 0x01d1aba4b38c38e7
Faulting application path: C:\inetpub\wwwroot\approot\runtimes\dnx-clr-win-x86.1.0.0-rc1-update2\bin\dnx.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: f1f534cd-1797-11e6-9404-000d3ab185aa
Faulting package full name:
Faulting package-relative application ID:
It seems to me like it is using a wrong dnx version, but this shouldn't be possible as i published the app with:
dnu publish --runtime active --no-source
First of all thanks Clint for pushing me in the right direction.
Unfortunately I ended up spinning up a new Windows Server 2012 instance, and installing everything from the grounds up, which seems to work great at this moment. I have probably messed something when initially setting up the server, but it was a test one so no harm is done. I have a few observations for DNX to IIS publishing, which could help others with similar problems or at least mitigate at least some of the problems.
Very important steps:
If publishing from command line, publish with dnu publish --runtime active. Add --no-source when you are sure you don't need to make any quick changes to make the app work so it compiles into NuGet packages.
Try to run the app manually by running web.cmd from the publishing folder from command line. If this doesn't work, IIS is least of your problems, and you need to resolve the app startup first.
Install IIS locally on your development machine, and try to make it first work with that one, which will help you understand which issues are happening to you and how to resolve them on the real web server.
Use Event Viewer -> Windows Logs -> Application to catch .NET and HttpPlatformHandler errors during startup
Enable stdout inside wwwroot/web.config for your solution.
Battling different issues:
1. Various http 4xx and 5xx errors.
Ensure that Http Handler 1.2 is installed. If you are not sure, check the add / remove programs section in control panel, where version is clearly visible. If using a x64 system, you need to install x64 runtime
Check that you have unlocked handlers in IIS
Check that Application pool is set to No Managed code (32 bit app support was not required in my case)
2. I'm not sure I published to a good folder
Create a folder for your web app inside your wwwroot folder e.g. C:\inetpub\wwwroot\myApplicationName
Copy publishing files to that folder. Structure should be as follows:
C:\inetpub\wwwroot\myApplicationName
approot
logs
wwwroot
Create a new website in IIS and attach it to your application pool that is set to no managed code
Set the application folder to be C:\inetpub\wwwroot\myApplicationName\wwwroot
3. Event Viewer - DNX Could not write to logs folder
This is an issue with IIS permissions on the logs folder from your publishing artefacts. Right click -> Properties -> Security on the logs folder and Add permissions for the following user.
IIS_IUSRS (permissions: read and execute, list, write)
Once you do this, restart the website, and check if this issue is gone. If Event Viewer is not logging anything, check if there is a file generated in the logs folder where you should get the next troubleshooting hint.
NOTE: If you publish an app update, and you overwrite the logs folder accidentally, you will kill its permissions and this issue will return. After the initial publish, just copy approot and wwwroot, and leave the logs intact to avoid this.
4. Unable to load application or execute command 'Microsoft.AspNet.Server.Kestrel'. Available commands: web
Try to run a dnu restore before publishing manually
Ensure that you have published with --runtime active
First make sure you have httpPlatformHandler v1.2 installed. Then follow the steps and issue resolutions here. If it still is not working, I've heard some people have resolved their issues by adding a Configure1() method in Startup.cs. See the details here.
I got one of my projects working with IIS but it was a struggle. So I decided to wait until the next release. I personally don't think it's worth bothering with right now. Because it relies on dnx which is being replaced in the next release. So whatever you do to get it working, probably won't be relevant after the next release.
I've been struggling while trying to create an automated TFS 2010 team build that uses MSDeploy to deploy the website to one of our local boxes. Aside from not being able to find good documentation, a large part of the problem is that the site uses a native C++ dll. I've managed to get things almost working now and the site will deploy during the build BUT the native dll is typically in use and prevents the deployment if the site has been accessed since the last restart. I would like to have the build force an application pool recycle or restart the site/application just prior to deploying the files to the remote server. I can use the following at the command prompt to achieve this manually:
msdeploy -verb:sync -source:recycleApp -dest:recycleApp="Default Web Site/Application",computerName="MyServer"
How do I hook this into the build process so that it occurs before the publishing pipeline tries to copy files to the server?
You could use the InvokeProcess activity in your workflow. You can then invoke a batch script that would contain your command line above.
You can drag the activity and insert it as the step before publishing (assuming you are using the workflow designer).
If you need the script to run as another user there are plenty of helpful suggestions here and in the linked blog.
I already owe SO and Ewald for getting our TFS build up and running.
I’m trying to use a (VS 2008) Web Deployment project in a TFS solution to deploy the web site to the (TFS 2008) build server to run web based unit tests.
For some reason, that I can't yet figure out, it is failing to create the virtual directory:
Using "CreateVirtualDirectory" task from assembly "C:\Program Files\MSBuild\Microsoft\WebDeployment\v9.0\Microsoft.WebDeployment.Tasks.dll".
Task "CreateVirtualDirectory"
Initializing IIS Web Server...
C:\Program Files\MSBuild\Microsoft\WebDeployment\v9.0\Microsoft.WebDeployment.targets(667,5): error : Access is denied.
C:\Program Files\MSBuild\Microsoft\WebDeployment\v9.0\Microsoft.WebDeployment.targets(667,5): error :
Failed to create virtual directory 'abc'.
Done executing task "CreateVirtualDirectory" -- FAILED.
The TFSService user certainly is in the Administrators group on the TFS Build machine (which is running Windows Server 2008). I don’t know what else could be wrong. I’ve checked the event log an there’s no clues there. I am able to manually create the virtual directory on that machine through the IIS console with no problem.
Any ideas what could be the problem or suggestions for how to diagnose this further?
it has got to be permissions...did you try putting the TFSService in the same Groups you are in?
Is the TFS account running under the same privileges as the account that you use to connect to IIS? Do as Craig suggested and move the TFS account into the groups that you participate in.
You're sure that the build is running under the TFSService id and not under another id set up just for builds, and which may not be in the administrator's group? I haven't done more than just play with automated builds since I do mostly solo development, but I recall setting up a separate build id when I was looking at this.
I have seen this occur when the IIS server wasn't running on the default port. I'd recommend checking IIS to see if it's running on port 80 as a step to diagnose your issue further.
I eventually managed to get deployment working by calling the _CopyWebApplication build target of the web application from my TFS build script (after manually creating the IIS virtual directory).
I had to add an additional target though to get linked files in the project to be copied also as the built in _CopyWebApplication target doesn't include those.