Azure Function app not after migration to .Net 10, error "dotnet exited with code 150 (0x96)"

[hesekie11]

Description

We are trying to migrate our Azure Function app written in C# from .Net 8 to .Net 10.

The function app builds OK locally.
But once deployed to Azure, there is an error at Azure Function startup:
Microsoft.Azure.WebJobs.Script.Grpc: dotnet exited with code 150 (0x96). https://aka.ms/dotnet/app-launch-failed.

On this page, it states that .Net 10 is a supported version:
https://learn.microsoft.com/en-us/azure/azure-functions/dotnet-isolated-process-guide?tabs=ihostapplicationbuilder%2Ccode%2Cwindows#supported-versions .

We have also seen #3152.

We are on function runtime version 4, in isolated mode, and on a Flex Consumption Plan.

In the Azure Portal, in the function app's Settings > Configuration > Stack settings, we have selected ".Net 10 Isolated".

Our .csproj file:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
	<OutputType>Exe</OutputType>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues" Version="5.5.4" />
	<FrameworkReference Include="Microsoft.AspNetCore.App" />
	<PackageReference Include="Microsoft.Azure.Functions.Worker" Version="2.51.0" />
	<PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="2.0.7" />
	<PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="2.1.0" />
	<PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="3.0.0" />
	<PackageReference Include="Microsoft.Azure.Functions.Worker.ApplicationInsights" Version="2.50.0" />
	<PackageReference Include="Microsoft.Extensions.Configuration.UserSecrets" Version="10.0.5" />
	<PackageReference Include="System.Text.Json" Version="10.0.5" />
  </ItemGroup>
	<ItemGroup>
		<Using Include="System.Threading.ExecutionContext" Alias="ExecutionContext" />
	</ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
</Project>

Detailed error from function app logs:
{"prop__operationId":"494b42e5-fee8-4bfe-ad37-c7b0308458f3","ProcessId":"438","HostInstanceId":"febc40b6-dc88-4f0f-8a01-f287b2aa3873","prop__{OriginalFormat}":"A host error has occurred during startup operation '{operationId}'.","LogLevel":"Error","EventId":"515","Category":"Host.Startup","EventName":"ErrorOccurredDuringStartupOpe...

List of traces from startup:

[treveshan]

We hit the exact same issue migrating our Azure Function app (.NET 8 -> .NET 10, isolated mode, Flex Consumption Plan, Linux). Here's what fixed it:

The Root Cause
The Flex Consumption Plan host runtime on Linux still uses .NET 8 internally (System.Private.CoreLib, Version=8.0.0.0). Even though the portal shows ".NET 10 Isolated" in Stack Settings, the host doesn't have the .NET 10 runtime pre-installed. So when it tries to launch your .NET 10 worker process, it fails with exit code 150 (0x96). That is my gut feel.

The Fix
Publish as self-contained for linux-x64 so the .NET 10 runtime is bundled into the deployment package and doesn't depend on what's installed on the host.

[hesekie11]

Thanks you for the tip Treveshan Naidoo (@treveshan). How exactly are you publishing your function as self-contained?

To try that, we did these 2 changes:

1
Added these to our function .csproj file:

<RuntimeIdentifier>linux-x64</RuntimeIdentifier>
<SelfContained>true</SelfContained>	  

2
Changed our Azure DevOps pipeline (which builds and deploys the function app code) to include " -r linux-x64 --self-contained true" in the build arguments:

- task: DotNetCoreCLI@2
  displayName: "Building ${{ variables.artifactName }}"
  inputs:
    command: publish
    publishWebProjects: False
    projects: "${{ variables.projectPath }}/*.csproj"
    arguments: "--configuration ${{ variables.buildConfiguration }} --output $(Build.ArtifactStagingDirectory) -r linux-x64 --self-contained true"
    zipAfterPublish: True

Now, when looking at the function in Azure Portal, it no longer shows the original error "dotnet exited with code 150 (0x96)".
But, in the function list it says "We were not able to load some functions in the list due to errors.", and instead of our functions it lists a function called "Warmup" which we haven't implemented (probably related to the warmup extension listed in the logs). Logs again show startup errors:

[treveshan]

We’re using GitHub Actions, but the key for us was explicitly using dotnet publish (not just build) and making it self-contained:

dotnet publish --configuration Release --output ./output \
  --runtime linux-x64 \
  --self-contained true

Also worth mentioning we actually saw the exact same behaviour where only the Warmup function showed up and none of our actual functions loaded.

In our case, that was still part of the same root issue (runtime mismatch on the host). Once we switched to a self-contained publish via dotnet publish, everything loaded correctly and the Warmup-only issue disappeared.

So I’d lean towards this still being runtime/startup related rather than a Warmup-specific problem.

If it helps, here’s the equivalent Azure DevOps setup that should work:

- task: DotNetCoreCLI@2
  displayName: 'Publish Azure Function (self-contained)'
  inputs:
    command: 'publish'
    publishWebProjects: false
    projects: '$(Build.SourcesDirectory)/src/YourFunctionApp/YourFunctionApp.csproj'
    arguments: >
      --configuration Release
      --output $(Build.ArtifactStagingDirectory)/functionapp
      --runtime linux-x64
      --self-contained true
    zipAfterPublish: true

[hesekie11]

This is the yml we have been attempting already earlier, so it is practically the same as yours (the important part being "--runtime linux-x64 --self-contained true").

      - task: DotNetCoreCLI@2
        displayName: "Building ${{ variables.artifactName }}"
        inputs:
          command: publish
          publishWebProjects: False
          projects: "${{ variables.projectPath }}/*.csproj"
          arguments: "--configuration ${{ variables.buildConfiguration }} --output $(Build.ArtifactStagingDirectory) --runtime linux-x64 --self-contained true"
          zipAfterPublish: True

With this, still seeing "We were not able to load some functions in the list due to errors", and only the Warmup function is listed.

We have tried both with and without this in .csproj file:

<RuntimeIdentifier>linux-x64</RuntimeIdentifier>
<SelfContained>true</SelfContained>	  

[hesekie11]

Got this solved now with the following changes:

1
In Azure DevOps pipeline, use --runtime linux-x64 --self-contained true in publish task arguments (see above).

2
In Azure DevOps pipeline, use:

pool:
        vmImage: ubuntu-latest

instead of:

pool:
        vmimage: windows-latest

3
In .csproj, use:
<PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.23.0" />
instead of:
<PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="3.0.0" />
See microsoft/ApplicationInsights-dotnet#3106.

This way you prevent these issues:

• Function page in Azure portal shows: "dotnet exited with code 150 (0x96)".
• Function page in Azure portal shows: "System.Diagnostics.Process: An error occurred trying to start process '/home/site/wwwroot/Hela.Idp.Citizen.AccountCheck' with working directory '/home/site/wwwroot'. Permission denied".
• Function page in Azure portal shows: "Could not load type 'Microsoft.ApplicationInsights.Extensibility.ITelemetryInitializer' from assembly 'Microsoft.ApplicationInsights, Version=3.0.0.1, Culture=neutral, PublicKeyToken=31bf3856ad364e35'".
• Function page in Azure portal does not list your functions, only lists unknown function called Warmup.

[gabbsmo]

I thought that .NET 8 was approaching end-of-life and I should start moving to .NET 10, but it looks like I should reconsider. I am also using Flex Consumption.

[gabbsmo]

Matthew Henderson (@mattchenderson) Sorry to bother you. I saw your tracking thread on .NET 10 support (#3152) and was wondering if .NET 10 is confirmed to be available in new and existing Flex Consumption plans?

[kshyju]

You do not need to do self-contained publishing as the images are expected have the .NET10 runtime bits in it.

hesekie11 , Treveshan Naidoo (@treveshan) If you can share information about your app, I can take a quick look and provide guidance on next steps. See Sharing Your Function App name privately

[VegaMarinkovicAleksa]

I am experiencing the same exact issue.
Function app runtime 4, isolated, flex consumption, switched from .net9 ->.net10.
I tried following Shyju Krishnankutty (@kshyju) suggestion for sharing information about the app but cannot seem to do it. Log stream doesn't have anything in it other than "Connected" and the /api/guid method doesn't work, presumably because my function app is not running as it has crashed due to this issue.
I did manage to pick up this though, not sure if that is enough to share information about the function app privately.

[administersoftware]

Having the same issue as hesekie11.

Have reverted back to .NET 8 and Microsoft.ApplicationInsights.WorkerService 2.23.0.

[mirokauppinen]

Have similar problems. Flex consumption with vnet and private endpoint. Some functions work after deployment, some don't. Some started working after deleting the function and creating it again from the beginning. But I cannot find any way to confirm a trustworthy way to continue. Usually when deploying the updated .net 10 package, there is some sync trigger issues in activity monitor and only function visible is the "warmup" function.
I'm near to end testing the flex functions as I cannot trust that this works.