Azure App Service および IIS での ASP.NET Core のトラブルシューティングTroubleshoot ASP.NET Core on Azure App Service and IIS

Luke LathamJustin Kotk kBy Luke Latham and Justin Kotalik

この記事では、アプリの起動時に発生する一般的なエラーと、アプリが Azure App Service または IIS に展開されたときのエラーを診断する手順について説明します。This article provides information on common app startup errors and instructions on how to diagnose errors when an app is deployed to Azure App Service or IIS:

アプリのスタートアップエラーApp startup errors
一般的なスタートアップ HTTP 状態コードのシナリオについて説明します。Explains common startup HTTP status code scenarios.

Azure App Service でのトラブルシューティングTroubleshoot on Azure App Service
Azure App Service に展開されたアプリに関するトラブルシューティングのアドバイスを提供します。Provides troubleshooting advice for apps deployed to Azure App Service.

IIS でのトラブルシューティングTroubleshoot on IIS
IIS に展開されているか IIS Express ローカルで実行されているアプリに関するトラブルシューティングのアドバイスを提供します。Provides troubleshooting advice for apps deployed to IIS or running on IIS Express locally. このガイダンスは、Windows Server と Windows デスクトップの両方の展開に適用されます。The guidance applies to both Windows Server and Windows desktop deployments.

パッケージキャッシュのクリアClear package caches
メジャーアップグレードの実行時またはパッケージバージョンの変更時に統一性パッケージがアプリを中断した場合の対処方法について説明します。Explains what to do when incoherent packages break an app when performing major upgrades or changing package versions.

その他のリソースAdditional resources
トラブルシューティングに関するその他のトピックを示します。Lists additional troubleshooting topics.

アプリ起動時のエラーApp startup errors

Visual Studio では、ASP.NET Core プロジェクトのデバッグ時に IIS Express のホスティングが既定の設定です。In Visual Studio, an ASP.NET Core project defaults to IIS Express hosting during debugging. このトピックのアドバイスを使用してローカルでデバッグすると、 502.5 プロセスエラーまたは500.30 開始エラーが発生します。A 502.5 - Process Failure or a 500.30 - Start Failure that occurs when debugging locally can be diagnosed using the advice in this topic.

403.14 許可されていません403.14 Forbidden

アプリを起動できません。The app fails to start. 次のエラーがログに記録されます。The following error is logged:

The Web server is configured to not list the contents of this directory.

このエラーが発生するのは、通常、ホストシステム上の展開が壊れている場合です。これには、次のようなシナリオが含まれます。The error is usually caused by a broken deployment on the hosting system, which includes any of the following scenarios:

  • アプリがホストシステムの間違ったフォルダーに配置されています。The app is deployed to the wrong folder on the hosting system.
  • 展開プロセスで、アプリのすべてのファイルとフォルダーを、ホスティングシステムの展開フォルダーに移動できませんでした。The deployment process failed to move all of the app's files and folders to the deployment folder on the hosting system.
  • 配置に web.config ファイルがないか、web.configファイルの内容形式が正しくありません。The web.config file is missing from the deployment, or the web.config file contents are malformed.

次の手順に従います。Perform the following steps:

  1. ホストシステム上の展開フォルダーからすべてのファイルとフォルダーを削除します。Delete all of the files and folders from the deployment folder on the hosting system.
  2. Visual Studio、PowerShell、手動デプロイなどの通常のデプロイ方法を使用して、アプリのpublishフォルダーの内容をホスティングシステムに再デプロイします。Redeploy the contents of the app's publish folder to the hosting system using your normal method of deployment, such as Visual Studio, PowerShell, or manual deployment:
    • 配置に web.configファイルが存在し、その内容が正しいことを確認します。Confirm that the web.config file is present in the deployment and that its contents are correct.
    • Azure App Service でホストする場合は、アプリが D:\home\site\wwwroot フォルダーに展開されていることを確認します。When hosting on Azure App Service, confirm that the app is deployed to the D:\home\site\wwwroot folder.
    • アプリが IIS によってホストされている場合は、iisマネージャー[基本設定] に表示されている iis の物理パスにアプリが展開されていることを確認します。When the app is hosted by IIS, confirm that the app is deployed to the IIS Physical path shown in IIS Manager's Basic Settings.
  3. ホスティングシステムの配置をプロジェクトのpublishフォルダーの内容と比較することによって、アプリのすべてのファイルとフォルダーが展開されていることを確認します。Confirm that all of the app's files and folders are deployed by comparing the deployment on the hosting system to the contents of the project's publish folder.

発行された ASP.NET Core アプリのレイアウトの詳細については、「ASP.NET Core のディレクトリ構造」を参照してください。For more information on the layout of a published ASP.NET Core app, see ASP.NET Core のディレクトリ構造. Web.config ファイルの詳細については、「ASP.NET Core モジュール」を参照してください。For more information on the web.config file, see ASP.NET Core モジュール.

500 内部サーバー エラー500 Internal Server Error

アプリは起動しますが、エラーのためにサーバーは要求を実行できません。The app starts, but an error prevents the server from fulfilling the request.

このエラーは、起動時または応答の作成中に、アプリのコード内で発生します。This error occurs within the app's code during startup or while creating a response. 応答にコンテンツが含まれていないか、またはブラウザーに "500 内部サーバー エラー" という応答が表示される可能性があります。The response may contain no content, or the response may appear as a 500 Internal Server Error in the browser. 通常、アプリケーション イベント ログではアプリが正常に起動したことが示されます。The Application Event Log usually states that the app started normally. サーバーから見るとそれは正しいことです。From the server's perspective, that's correct. アプリは起動しましたが、有効な応答を生成できません。The app did start, but it can't generate a valid response. サーバーのコマンドプロンプトでアプリを実行するか、ASP.NET Core モジュールの stdout ログを有効にして問題のトラブルシューティングを行います。Run the app at a command prompt on the server or enable the ASP.NET Core Module stdout log to troubleshoot the problem.

500.0 インプロセス ハンドラーの読み込みエラー500.0 In-Process Handler Load Failure

ワーカー プロセスが失敗します。The worker process fails. アプリは起動しません。The app doesn't start.

ASP.NET Core モジュールコンポーネントの読み込み中に不明なエラーが発生しました。An unknown error occurred loading ASP.NET Core Module components. 次のうちの 1 つの行為を行ってください:Take one of the following actions:

500.30 インプロセス起動エラー500.30 In-Process Startup Failure

ワーカー プロセスが失敗します。The worker process fails. アプリは起動しません。The app doesn't start.

ASP.NET Core モジュールは .NET Core CLR をインプロセスで開始しようとしますが、起動に失敗します。The ASP.NET Core Module attempts to start the .NET Core CLR in-process, but it fails to start. プロセス起動エラーの原因は、通常、アプリケーションイベントログのエントリと、ASP.NET Core モジュールの stdout ログによって決まります。The cause of a process startup failure can usually be determined from entries in the Application Event Log and the ASP.NET Core Module stdout log.

一般的なエラー条件:Common failure conditions:

  • アプリケーションの構成が正しくありません。これは、存在しない ASP.NET Core 共有フレームワークのバージョンをターゲットにしているためです。The app is misconfigured due to targeting a version of the ASP.NET Core shared framework that isn't present. 対象のコンピューターにどのバージョンの ASP.NET Core 共有フレームワークがインストールされているかを確認します。Check which versions of the ASP.NET Core shared framework are installed on the target machine.
  • Azure Key Vault を使用しています。 Key Vault に対する権限がありません。Using Azure Key Vault, lack of permissions to the Key Vault. 対象の Key Vault のアクセスポリシーを確認して、正しいアクセス許可が付与されていることを確認します。Check the access policies in the targeted Key Vault to ensure that the correct permissions are granted.

500.31 ANCM Failed to Find Native Dependencies (500.31 ANCM ネイティブの依存関係を見つけられませんでした)500.31 ANCM Failed to Find Native Dependencies

ワーカー プロセスが失敗します。The worker process fails. アプリは起動しません。The app doesn't start.

ASP.NET Core モジュールは .net Core ランタイムをインプロセスで開始しようとしますが、起動に失敗します。The ASP.NET Core Module attempts to start the .NET Core runtime in-process, but it fails to start. このスタートアップ エラーの最も一般的な原因は、Microsoft.NETCore.App または Microsoft.AspNetCore.App ランタイムがインストールされていない場合です。The most common cause of this startup failure is when the Microsoft.NETCore.App or Microsoft.AspNetCore.App runtime isn't installed. アプリが ASP.NET Core 3.0 をターゲットとして展開されていて、そのバージョンがコンピューターに存在しない場合、このエラーが発生します。If the app is deployed to target ASP.NET Core 3.0 and that version doesn't exist on the machine, this error occurs. エラー メッセージの例は次のとおりです。An example error message follows:

The specified framework 'Microsoft.NETCore.App', version '3.0.0' was not found.
  - The following frameworks were found:
      2.2.1 at [C:\Program Files\dotnet\x64\shared\Microsoft.NETCore.App]
      3.0.0-preview5-27626-15 at [C:\Program Files\dotnet\x64\shared\Microsoft.NETCore.App]
      3.0.0-preview6-27713-13 at [C:\Program Files\dotnet\x64\shared\Microsoft.NETCore.App]
      3.0.0-preview6-27714-15 at [C:\Program Files\dotnet\x64\shared\Microsoft.NETCore.App]
      3.0.0-preview6-27723-08 at [C:\Program Files\dotnet\x64\shared\Microsoft.NETCore.App]

エラー メッセージには、インストールされているすべての .NET Core のバージョンとアプリに必要なバージョンが一覧表示されます。The error message lists all the installed .NET Core versions and the version requested by the app. このエラーを修正するには、次のいずれかを実行します。To fix this error, either:

  • 適切なバージョンの .NET Core をマシンにインストールします。Install the appropriate version of .NET Core on the machine.
  • マシンに存在する .NET Core のバージョンをターゲットにするようにアプリを変更します。Change the app to target a version of .NET Core that's present on the machine.
  • アプリを自己完結型の展開として発行します。Publish the app as a self-contained deployment.

開発環境で実行している場合 (ASPNETCORE_ENVIRONMENT 環境変数が Development に設定されている場合)、特定のエラーが HTTP 応答に書き込まれます。When running in development (the ASPNETCORE_ENVIRONMENT environment variable is set to Development), the specific error is written to the HTTP response. プロセス起動エラーの原因は、アプリケーションイベントログにもあります。The cause of a process startup failure is also found in the Application Event Log.

500.32 ANCM Failed to Load dll (500.32 ANCM DLL を読み込めませんでした)500.32 ANCM Failed to Load dll

ワーカー プロセスが失敗します。The worker process fails. アプリは起動しません。The app doesn't start.

このエラーの最も一般的な原因は、アプリが互換性のないプロセッサ アーキテクチャ用に発行されていることです。The most common cause for this error is that the app is published for an incompatible processor architecture. ワーカー プロセスが 32 ビットアプリとして実行されていて、そのアプリが 64 ビットをターゲットとして発行されている場合、このエラーが発生します。If the worker process is running as a 32-bit app and the app was published to target 64-bit, this error occurs.

このエラーを修正するには、次のいずれかを実行します。To fix this error, either:

500.33 ANCM Request Handler Load Failure (500.33 ANCM 要求ハンドラーの読み込みエラー)500.33 ANCM Request Handler Load Failure

ワーカー プロセスが失敗します。The worker process fails. アプリは起動しません。The app doesn't start.

アプリは Microsoft.AspNetCore.App フレームワークを参照していませんでした。The app didn't reference the Microsoft.AspNetCore.App framework. ASP.NET Core モジュールでホストできるのは、Microsoft.AspNetCore.App framework を対象とするアプリだけです。Only apps targeting the Microsoft.AspNetCore.App framework can be hosted by the ASP.NET Core Module.

このエラーを修正するには、アプリが Microsoft.AspNetCore.App フレームワークをターゲットにしていることを確認します。To fix this error, confirm that the app is targeting the Microsoft.AspNetCore.App framework. アプリがターゲットとしているフレームワークを確認するには、.runtimeconfig.json を確認します。Check the .runtimeconfig.json to verify the framework targeted by the app.

500.34 ANCM Mixed Hosting Models Not Supported (500.34 ANCM 混在ホスティング モデルはサポートされません)500.34 ANCM Mixed Hosting Models Not Supported

ワーカー プロセスでは、インプロセス アプリとアウト プロセス アプリの両方を同じプロセスで実行できません。The worker process can't run both an in-process app and an out-of-process app in the same process.

このエラーを修正するには、別の IIS アプリケーション プールでアプリを実行します。To fix this error, run apps in separate IIS application pools.

500.35 ANCM Multiple In-Process Applications in same Process (500.35 ANCM 同一プロセス内の複数のインプロセス アプリケーション)500.35 ANCM Multiple In-Process Applications in same Process

ワーカープロセスでは、同じプロセスで複数のインプロセスアプリを実行することはできません。The worker process can't run multiple in-process apps in the same process.

このエラーを修正するには、別の IIS アプリケーション プールでアプリを実行します。To fix this error, run apps in separate IIS application pools.

500.36 ANCM Out-Of-Process Handler Load Failure (500.36 ANCM アウト プロセス ハンドラーの読み込みエラー)500.36 ANCM Out-Of-Process Handler Load Failure

アウト プロセス要求ハンドラーの aspnetcorev2_outofprocess.dllaspnetcorev2.dll ファイルの次にありません。The out-of-process request handler, aspnetcorev2_outofprocess.dll, isn't next to the aspnetcorev2.dll file. これは、 ASP.NET Core モジュールのインストールが破損していることを示します。This indicates a corrupted installation of the ASP.NET Core Module.

このエラーを修正するには、.NET Core Hosting Bundle (IIS 用) または Visual Studio (IIS Express 用) のインストールを修復します。To fix this error, repair the installation of the .NET Core Hosting Bundle (for IIS) or Visual Studio (for IIS Express).

500.37 ANCM Failed to Start Within Startup Time Limit (500.37 ANCM スタートアップ時間の制限内に起動できませんでした)500.37 ANCM Failed to Start Within Startup Time Limit

指定されたスタートアップ時間の制限内に ANCM が起動に失敗しました。ANCM failed to start within the provied startup time limit. 既定では、タイムアウトは 120 秒です。By default, the timeout is 120 seconds.

このエラーは、同じマシン上で多数のアプリを起動したときに発生する可能性があります。This error can occur when starting a large number of apps on the same machine. スタートアップ中のサーバー上の CPU/メモリ使用量の急上昇を確認します。Check for CPU/Memory usage spikes on the server during startup. 必要に応じて、複数のアプリのスタートアップ プロセスをずらします。You may need to stagger the startup process of multiple apps.

502.5 処理エラー502.5 Process Failure

ワーカー プロセスが失敗します。The worker process fails. アプリは起動しません。The app doesn't start.

ASP.NET Core モジュールはワーカー プロセスの開始を試みますが、開始に失敗します。The ASP.NET Core Module attempts to start the worker process but it fails to start. プロセス起動エラーの原因は、通常、アプリケーションイベントログのエントリと、ASP.NET Core モジュールの stdout ログによって決まります。The cause of a process startup failure can usually be determined from entries in the Application Event Log and the ASP.NET Core Module stdout log.

一般的なエラー条件は、存在しないバージョンの ASP.NET Core 共有フレームワークが対象にされていて、アプリが正しく構成されていないことです。A common failure condition is the app is misconfigured due to targeting a version of the ASP.NET Core shared framework that isn't present. 対象のコンピューターにどのバージョンの ASP.NET Core 共有フレームワークがインストールされているかを確認します。Check which versions of the ASP.NET Core shared framework are installed on the target machine. 共有フレームワークは、コンピューター上にインストールされたアセンブリ ( .dll ファイル) のセットであり、Microsoft.AspNetCore.App などのメタパッケージによって参照されます。The shared framework is the set of assemblies (.dll files) that are installed on the machine and referenced by a metapackage such as Microsoft.AspNetCore.App. メタパッケージの参照には、必要な最低限のバージョンを指定できます。The metapackage reference can specify a minimum required version. 詳しくは、共有フレームワークに関するページをご覧ください。For more information, see The shared framework.

正しく構成されていないホスティングやアプリが原因でワーカー プロセスが失敗する場合、"502.5 処理エラー" のエラー ページが返されます。The 502.5 Process Failure error page is returned when a hosting or app misconfiguration causes the worker process to fail:

アプリケーションの起動に失敗しました (ErrorCode '0x800700c1')Failed to start application (ErrorCode '0x800700c1')

EventID: 1010
Source: IIS AspNetCore Module V2
Failed to start application '/LM/W3SVC/6/ROOT/', ErrorCode '0x800700c1'.

アプリのアセンブリ ( .dll) を読み込めなかったため、アプリの起動に失敗しました。The app failed to start because the app's assembly (.dll) couldn't be loaded.

このエラーは、公開されたアプリと w3wp/iisexpress プロセスの間でビットの不一致がある場合に発生します。This error occurs when there's a bitness mismatch between the published app and the w3wp/iisexpress process.

アプリ プールの 32 ビット設定が正しいことを確認してください。Confirm that the app pool's 32-bit setting is correct:

  1. IIS マネージャーの [アプリケーション プール] でそのアプリ プールを選択します。Select the app pool in IIS Manager's Application Pools.
  2. [アクション] パネルの [アプリケーション プールの編集][詳細設定] を選択します。Select Advanced Settings under Edit Application Pool in the Actions panel.
  3. [32 ビット アプリケーションの有効化] を設定します。Set Enable 32-Bit Applications:
    • 32 ビット (x86) アプリを展開する場合は、この値を True に設定します。If deploying a 32-bit (x86) app, set the value to True.
    • 64 ビット (x64) アプリを展開する場合は、この値を False に設定します。If deploying a 64-bit (x64) app, set the value to False.

プロジェクトファイルの <Platform> MSBuild プロパティとアプリの発行済みビットとの間で競合が発生していないことを確認します。Confirm that there isn't a conflict between a <Platform> MSBuild property in the project file and the published bitness of the app.

接続のリセットConnection reset

ヘッダー送信後にエラーが発生した場合、サーバーが 500 内部サーバー エラーを送信するには遅すぎます。If an error occurs after the headers are sent, it's too late for the server to send a 500 Internal Server Error when an error occurs. このような状況は、応答に対する複雑なオブジェクトのシリアル化中にエラーが起きたときによく発生します。This often happens when an error occurs during the serialization of complex objects for a response. この種のエラーは、クライアントでは "接続リセット" エラーとして表示されます。This type of error appears as a connection reset error on the client. この種のエラーのトラブルシューティングには、アプリケーション ログが役に立つことがあります。Application logging can help troubleshoot these types of errors.

既定の起動制限Default startup limits

ASP.NET Core モジュールは、120秒の既定のstartupTimeLimitを使用して構成されています。The ASP.NET Core Module is configured with a default startupTimeLimit of 120 seconds. 既定値のままにした場合、モジュールで処理エラーが記録されるまでに、アプリは最大で 2 分を起動にかけることができます。When left at the default value, an app may take up to two minutes to start before the module logs a process failure. モジュールの構成の詳細については、「AspNetCore 要素の属性」を参照してください。For information on configuring the module, see Attributes of the aspNetCore element.

Azure App Service でのトラブルシューティングTroubleshoot on Azure App Service

重要

Azure App Service と ASP.NET Core のプレビュー リリースASP.NET Core preview releases with Azure App Service

ASP.NET Core のプレビュー リリースは、既定では Azure App Service に展開されません。ASP.NET Core preview releases aren't deployed to Azure App Service by default. ASP.NET Core プレビュー リリースを使用するアプリをホストするには、「Azure App Service に ASP.NET Core プレビュー リリースを展開する」を参照してください。To host an app that uses an ASP.NET Core preview release, see Deploy ASP.NET Core preview release to Azure App Service.

アプリケーションイベントログ (Azure App Service)Application Event Log (Azure App Service)

アプリケーション イベント ログにアクセスするには、Azure portal の [問題の診断と解決] ブレードを使います。To access the Application Event Log, use the Diagnose and solve problems blade in the Azure portal:

  1. Azure portal の [App Services] でアプリを開きます。In the Azure portal, open the app in App Services.
  2. [Diagnose and solve prolems](問題の診断と解決) を選択します。Select Diagnose and solve problems.
  3. [診断ツール] という見出しを選択します。Select the Diagnostic Tools heading.
  4. [サポート ツール][アプリケーション イベント] ボタンを選択します。Under Support Tools, select the Application Events button.
  5. [Source](ソース) 列で、IIS AspNetCoreModule または IIS AspNetCoreModule V2 によって提供された最新のエラーを調べます。Examine the latest error provided by the IIS AspNetCoreModule or IIS AspNetCoreModule V2 entry in the Source column.

[問題の診断と解決] ブレードを使う代わりに、Kudu を使ってアプリケーション イベント ログ ファイルを直接調べることもできます。An alternative to using the Diagnose and solve problems blade is to examine the Application Event Log file directly using Kudu:

  1. [開発ツール] 領域で [高度なツール] を開きます。Open Advanced Tools in the Development Tools area. [Go→] ボタンを選びます。Select the Go→ button. 新しいブラウザー タブまたはウィンドウで Kudu コンソールが開きます。The Kudu console opens in a new browser tab or window.
  2. ページの上部にあるナビゲーション バーを使って [デバッグ コンソール] を開き、 [CMD] を選びます。Using the navigation bar at the top of the page, open Debug console and select CMD.
  3. LogFiles フォルダーを開きます。Open the LogFiles folder.
  4. eventlog.xml ファイルの横にある鉛筆アイコンを選びます。Select the pencil icon next to the eventlog.xml file.
  5. ログを調べます。Examine the log. ログの末尾までスクロールし、最新のイベントを確認します。Scroll to the bottom of the log to see the most recent events.

Kudu コンソールでアプリを実行します。Run the app in the Kudu console

多くの起動時エラーでは、アプリケーション イベント ログに役に立つ情報が生成されません。Many startup errors don't produce useful information in the Application Event Log. Kudu のリモート実行コンソールでアプリを実行すると、エラーを検出することができます。You can run the app in the Kudu Remote Execution Console to discover the error:

  1. [開発ツール] 領域で [高度なツール] を開きます。Open Advanced Tools in the Development Tools area. [Go→] ボタンを選びます。Select the Go→ button. 新しいブラウザー タブまたはウィンドウで Kudu コンソールが開きます。The Kudu console opens in a new browser tab or window.
  2. ページの上部にあるナビゲーション バーを使って [デバッグ コンソール] を開き、 [CMD] を選びます。Using the navigation bar at the top of the page, open Debug console and select CMD.

32 ビット (x86) アプリをテストするTest a 32-bit (x86) app

現在のリリースCurrent release

  1. cd d:\home\site\wwwroot
  2. 次のようにアプリを実行します。Run the app:

エラーを示すアプリからのコンソール出力はすべて、Kudu コンソールにパイプされます。The console output from the app, showing any errors, is piped to the Kudu console.

プレビューリリースで実行されているフレームワークに依存する配置Framework-dependent deployment running on a preview release

"ASP.NET Core {バージョン} (x86) ランタイムのサイト拡張機能をインストールする必要があります。 "Requires installing the ASP.NET Core {VERSION} (x86) Runtime site extension.

  1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x32 ({X.Y} はランタイム バージョンです)cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x32 ({X.Y} is the runtime version)
  2. アプリを実行します: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dllRun the app: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

エラーを示すアプリからのコンソール出力はすべて、Kudu コンソールにパイプされます。The console output from the app, showing any errors, is piped to the Kudu console.

64 ビット (x64) アプリをテストするTest a 64-bit (x64) app

現在のリリースCurrent release

エラーを示すアプリからのコンソール出力はすべて、Kudu コンソールにパイプされます。The console output from the app, showing any errors, is piped to the Kudu console.

プレビューリリースで実行されているフレームワークに依存する配置Framework-dependent deployment running on a preview release

"ASP.NET Core {バージョン} (x64) ランタイムのサイト拡張機能をインストールする必要があります。 "Requires installing the ASP.NET Core {VERSION} (x64) Runtime site extension.

  1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x64 ({X.Y} はランタイム バージョンです)cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x64 ({X.Y} is the runtime version)
  2. アプリを実行します: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dllRun the app: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

エラーを示すアプリからのコンソール出力はすべて、Kudu コンソールにパイプされます。The console output from the app, showing any errors, is piped to the Kudu console.

ASP.NET Core モジュールの stdout ログ (Azure App Service)ASP.NET Core Module stdout log (Azure App Service)

ASP.NET Core モジュールの stdout には、アプリケーション イベント ログでは見つからない有用なエラー メッセージが記録されることがよくあります。The ASP.NET Core Module stdout log often records useful error messages not found in the Application Event Log. stdout ログを有効にして表示するには:To enable and view stdout logs:

  1. Azure portal で [問題の診断と解決] ブレードに移動します。Navigate to the Diagnose and solve problems blade in the Azure portal.
  2. [SELECT PROBLEM CATEGORY](問題カテゴリの選択) で、 [Web App Down](Web アプリのダウン) ボタンを選びます。Under SELECT PROBLEM CATEGORY, select the Web App Down button.
  3. [提案されたソリューション > Stdout ログリダイレクトを有効にする] で、[] ボタンを選択してKudu コンソールを開き、web.config を編集します。Under Suggested Solutions > Enable Stdout Log Redirection, select the button to Open Kudu Console to edit Web.Config.
  4. Kudu の診断コンソールで、パス site > wwwroot へのフォルダーを開きます。In the Kudu Diagnostic Console, open the folders to the path site > wwwroot. 下にスクロールして、一覧の最後にある web.config ファイルを表示します。Scroll down to reveal the web.config file at the bottom of the list.
  5. web.config ファイルの隣の鉛筆アイコンをクリックします。Click the pencil icon next to the web.config file.
  6. stdoutLogEnabledtrue に設定し、stdoutLogFile パスを \\?\%home%\LogFiles\stdout に変更します。Set stdoutLogEnabled to true and change the stdoutLogFile path to: \\?\%home%\LogFiles\stdout.
  7. [保存] を選んで、更新した web.config ファイルを保存します。Select Save to save the updated web.config file.
  8. アプリに対して要求します。Make a request to the app.
  9. Azure Portal に戻ります。Return to the Azure portal. [開発ツール] 領域で [高度なツール] ブレードを選びます。Select the Advanced Tools blade in the DEVELOPMENT TOOLS area. [Go→] ボタンを選びます。Select the Go→ button. 新しいブラウザー タブまたはウィンドウで Kudu コンソールが開きます。The Kudu console opens in a new browser tab or window.
  10. ページの上部にあるナビゲーション バーを使って [デバッグ コンソール] を開き、 [CMD] を選びます。Using the navigation bar at the top of the page, open Debug console and select CMD.
  11. LogFiles フォルダーを選択します。Select the LogFiles folder.
  12. [Modified](変更日) 列を調べて、変更日が最新の stdout ログの鉛筆アイコンを選んで編集します。Inspect the Modified column and select the pencil icon to edit the stdout log with the latest modification date.
  13. ログ ファイルが開くと、エラーが表示されます。When the log file opens, the error is displayed.

トラブルシューティングが完了したら、stdout ログを無効にします。Disable stdout logging when troubleshooting is complete:

  1. Kudu の診断コンソール で、パス site > wwwroot に戻り、web.config ファイルを表示します。In the Kudu Diagnostic Console, return to the path site > wwwroot to reveal the web.config file. 鉛筆アイコンを選んで web.config ファイルを再び開きます。Open the web.config file again by selecting the pencil icon.
  2. stdoutLogEnabledfalse に設定します。Set stdoutLogEnabled to false.
  3. [保存] を選んでファイルを保存します。Select Save to save the file.

詳細については、ASP.NET Core モジュール を参照してください。For more information, see ASP.NET Core モジュール.

警告

stdout ログを無効にしないと、アプリまたはサーバーで障害が発生する可能性があります。Failure to disable the stdout log can lead to app or server failure. ログ ファイルのサイズまたは作成されるログ ファイルの数に制限はありません。There's no limit on log file size or the number of log files created. stdout ログは、アプリ起動時の問題のトラブルシューティングにのみ使ってください。Only use stdout logging to troubleshoot app startup problems.

起動後の ASP.NET Core アプリでの一般的なログの場合は、ログ ファイルのサイズを制限し、ログをローテーションするログ ライブラリを使います。For general logging in an ASP.NET Core app after startup, use a logging library that limits log file size and rotates logs. 詳しくは、「サードパーティ製のログ プロバイダー」をご覧ください。For more information, see third-party logging providers.

ASP.NET Core モジュールデバッグログ (Azure App Service)ASP.NET Core Module debug log (Azure App Service)

ASP.NET Core モジュール デバッグ ログでは、ASP.NET Core モジュールのさらに詳しいログが提供されます。The ASP.NET Core Module debug log provides additional, deeper logging from the ASP.NET Core Module. stdout ログを有効にして表示するには:To enable and view stdout logs:

  1. 強化された診断ログを有効にするには、次のいずれかを実行します。To enable the enhanced diagnostic log, perform either of the following:
    • 強化された診断ログ」の指示に従い、強化された診断ログをアプリに対して設定します。Follow the instructions in Enhanced diagnostic logs to configure the app for an enhanced diagnostic logging. アプリを再デプロイします。Redeploy the app.
    • Kudu コンソールを利用し、「<handlerSettings>強化された診断ログ」にある をライブ アプリの web.config ファイルに追加します。Add the <handlerSettings> shown in Enhanced diagnostic logs to the live app's web.config file using the Kudu console:
      1. [開発ツール] 領域で [高度なツール] を開きます。Open Advanced Tools in the Development Tools area. [Go→] ボタンを選びます。Select the Go→ button. 新しいブラウザー タブまたはウィンドウで Kudu コンソールが開きます。The Kudu console opens in a new browser tab or window.
      2. ページの上部にあるナビゲーション バーを使って [デバッグ コンソール] を開き、 [CMD] を選びます。Using the navigation bar at the top of the page, open Debug console and select CMD.
      3. パス site > wwwroot へのフォルダーを開きます。Open the folders to the path site > wwwroot. 鉛筆アイコンを選択し、web.config ファイルを編集します。Edit the web.config file by selecting the pencil button. <handlerSettings>強化された診断ログ」にある セクションを追加します。Add the <handlerSettings> section as shown in Enhanced diagnostic logs. [保存] を選択します。Select the Save button.
  2. [開発ツール] 領域で [高度なツール] を開きます。Open Advanced Tools in the Development Tools area. [Go→] ボタンを選びます。Select the Go→ button. 新しいブラウザー タブまたはウィンドウで Kudu コンソールが開きます。The Kudu console opens in a new browser tab or window.
  3. ページの上部にあるナビゲーション バーを使って [デバッグ コンソール] を開き、 [CMD] を選びます。Using the navigation bar at the top of the page, open Debug console and select CMD.
  4. パス site > wwwroot へのフォルダーを開きます。Open the folders to the path site > wwwroot. aspnetcore-debug.log ファイルにパスを指定しなかった場合、ファイルが一覧に表示されます。If you didn't supply a path for the aspnetcore-debug.log file, the file appears in the list. パスを指定した場合、ログ ファイルの場所に移動します。If you supplied a path, navigate to the location of the log file.
  5. ファイル名の隣にある鉛筆アイコンでログ ファイルを開きます。Open the log file with the pencil button next to the file name.

トラブルシューティングが完了したら、debug ログを無効にします。Disable debug logging when troubleshooting is complete:

強化されたデバッグ ログを無効にするには、次のいずれかを実行します。To disable the enhanced debug log, perform either of the following:

  • ローカルの <handlerSettings>web.configファイルから を削除し、アプリを再デプロイします。Remove the <handlerSettings> from the web.config file locally and redeploy the app.
  • Kudu コンソールを使用して web.config ファイルを編集し、<handlerSettings> セクションを削除します。Use the Kudu console to edit the web.config file and remove the <handlerSettings> section. ファイルを保存します。Save the file.

詳細については、ASP.NET Core モジュール を参照してください。For more information, see ASP.NET Core モジュール.

警告

debug ログを無効にしないと、アプリまたはサーバーで障害が発生する可能性があります。Failure to disable the debug log can lead to app or server failure. ログ ファイルのサイズに制限はありません。There's no limit on log file size. debug ログは、アプリ起動時の問題のトラブルシューティングにのみ使ってください。Only use debug logging to troubleshoot app startup problems.

起動後の ASP.NET Core アプリでの一般的なログの場合は、ログ ファイルのサイズを制限し、ログをローテーションするログ ライブラリを使います。For general logging in an ASP.NET Core app after startup, use a logging library that limits log file size and rotates logs. 詳しくは、「サードパーティ製のログ プロバイダー」をご覧ください。For more information, see third-party logging providers.

低速またはハングしているアプリ (Azure App Service)Slow or hanging app (Azure App Service)

要求に対してアプリの反応が遅い場合、またはハングする場合は、次の記事を参照してください。When an app responds slowly or hangs on a request, see the following articles:

監視ブレードMonitoring blades

監視ブレードでは、このトピックでこれまでに説明した方法に代わるトラブルシューティング エクスペリエンスが提供されます。Monitoring blades provide an alternative troubleshooting experience to the methods described earlier in the topic. これらのブレードは、500 番台のエラーの診断に使用できます。These blades can be used to diagnose 500-series errors.

ASP.NET Core 拡張機能がインストールされていることを確認してください。Confirm that the ASP.NET Core Extensions are installed. 拡張機能がインストールされていない場合は、手動でインストールします。If the extensions aren't installed, install them manually:

  1. [開発ツール] ブレード セクションで、 [拡張機能] ブレードを選びます。In the DEVELOPMENT TOOLS blade section, select the Extensions blade.
  2. [ASP.NET Core Extensions](ASP.NET Core 拡張機能) が一覧に表示されます。The ASP.NET Core Extensions should appear in the list.
  3. 拡張機能がインストールされていない場合は、 [追加] ボタンを選びます。If the extensions aren't installed, select the Add button.
  4. 一覧から [ASP.NET Core Extensions](ASP.NET Core 拡張機能) を選びます。Choose the ASP.NET Core Extensions from the list.
  5. [OK] を選んで法的条項に同意します。Select OK to accept the legal terms.
  6. [拡張機能の追加] ブレードで [OK] を選びます。Select OK on the Add extension blade.
  7. 拡張機能が正常にインストールされると、情報ポップアップ メッセージで通知されます。An informational pop-up message indicates when the extensions are successfully installed.

stdout ログが有効になっていない場合は、次の手順のようにします。If stdout logging isn't enabled, follow these steps:

  1. Azure portal の [開発ツール] 領域で [高度なツール] ブレードを選びます。In the Azure portal, select the Advanced Tools blade in the DEVELOPMENT TOOLS area. [Go→] ボタンを選びます。Select the Go→ button. 新しいブラウザー タブまたはウィンドウで Kudu コンソールが開きます。The Kudu console opens in a new browser tab or window.
  2. ページの上部にあるナビゲーション バーを使って [デバッグ コンソール] を開き、 [CMD] を選びます。Using the navigation bar at the top of the page, open Debug console and select CMD.
  3. パスサイトのフォルダー > wwwrootを開き、下にスクロールして、一覧の下部にあるweb.config ファイルを表示します。Open the folders to the path site > wwwroot and scroll down to reveal the web.config file at the bottom of the list.
  4. web.config ファイルの隣の鉛筆アイコンをクリックします。Click the pencil icon next to the web.config file.
  5. stdoutLogEnabledtrue に設定し、stdoutLogFile パスを \\?\%home%\LogFiles\stdout に変更します。Set stdoutLogEnabled to true and change the stdoutLogFile path to: \\?\%home%\LogFiles\stdout.
  6. [保存] を選んで、更新した web.config ファイルを保存します。Select Save to save the updated web.config file.

続けて診断ログをアクティブにします。Proceed to activate diagnostic logging:

  1. Azure portal で [診断ログ] ブレードを選びます。In the Azure portal, select the Diagnostics logs blade.
  2. [アプリケーション ログ (ファイル システム)] および [詳細なエラー メッセージ][オン] スイッチを選びます。Select the On switch for Application Logging (Filesystem) and Detailed error messages. ブレードの上部にある [保存] ボタンを選びます。Select the Save button at the top of the blade.
  3. 失敗した要求イベントのバッファ処理 (FREB) とも呼ばれる失敗した要求のトレースを含めるには、 [失敗した要求のトレース][オン] スイッチを選びます。To include failed request tracing, also known as Failed Request Event Buffering (FREB) logging, select the On switch for Failed request tracing.
  4. ポータルで [診断ログ] ブレードのすぐ下にある [ログ ストリーム] ブレードを選びます。Select the Log stream blade, which is listed immediately under the Diagnostics logs blade in the portal.
  5. アプリに対して要求します。Make a request to the app.
  6. ログ ストリーム データ内で、エラーの原因が示されます。Within the log stream data, the cause of the error is indicated.

トラブルシューティングが完了したら、stdout ログを無効にしてください。Be sure to disable stdout logging when troubleshooting is complete.

失敗した要求のトレース ログ (FREB ログ) を見るには:To view the failed request tracing logs (FREB logs):

  1. Azure portal で [問題の診断と解決] ブレードに移動します。Navigate to the Diagnose and solve problems blade in the Azure portal.
  2. サイド バーの [SUPPORT TOOLS](サポート ツール) 領域で、 [Failed Request Tracing Logs](失敗した要求のトレース ログ) を選びます。Select Failed Request Tracing Logs from the SUPPORT TOOLS area of the sidebar.

詳しくは、「Azure App Service の Web アプリの診断ログの有効化」トピックの「失敗した要求トレース」セクションおよび「Azure での Web アプリのアプリケーションパフォーマンスに関するよくあるご質問」の「失敗した要求トレースをオンにするにはどうすればよいですか?」をご覧ください。See Failed request traces section of the Enable diagnostics logging for web apps in Azure App Service topic and the Application performance FAQs for Web Apps in Azure: How do I turn on failed request tracing? for more information.

詳しくは、「Azure App Service の Web アプリの診断ログの有効化」をご覧ください。For more information, see Enable diagnostics logging for web apps in Azure App Service.

警告

stdout ログを無効にしないと、アプリまたはサーバーで障害が発生する可能性があります。Failure to disable the stdout log can lead to app or server failure. ログ ファイルのサイズまたは作成されるログ ファイルの数に制限はありません。There's no limit on log file size or the number of log files created.

ASP.NET Core アプリでのルーチン ログの場合は、ログ ファイルのサイズを制限し、ログをローテーションするログ ライブラリを使います。For routine logging in an ASP.NET Core app, use a logging library that limits log file size and rotates logs. 詳しくは、「サードパーティ製のログ プロバイダー」をご覧ください。For more information, see third-party logging providers.

IIS でのトラブルシューティングTroubleshoot on IIS

アプリケーションイベントログ (IIS)Application Event Log (IIS)

アプリケーション イベント ログにアクセスします。Access the Application Event Log:

  1. [スタート] メニューを開き、イベント ビューアーを検索し、イベント ビューアー アプリを選択します。Open the Start menu, search for Event Viewer, and select the Event Viewer app.
  2. イベント ビューアー[Windows ログ] ノードを開きます。In Event Viewer, open the Windows Logs node.
  3. [Application] を選択して、アプリケーション イベント ログを開きます。Select Application to open the Application Event Log.
  4. 失敗したアプリに関連するエラーを検索します。Search for errors associated with the failing app. エラーの [ソース] 列には IIS AspNetCore Module または IIS Express AspNetCore Module の値が表示されます。Errors have a value of IIS AspNetCore Module or IIS Express AspNetCore Module in the Source column.

コマンド プロンプトでアプリを実行するRun the app at a command prompt

多くの起動時エラーでは、アプリケーション イベント ログに役に立つ情報が生成されません。Many startup errors don't produce useful information in the Application Event Log. ホスティング システムのコマンド プロンプトでアプリを実行すると、エラーの原因がわかることがあります。You can find the cause of some errors by running the app at a command prompt on the hosting system.

フレームワークに依存する展開Framework-dependent deployment

アプリがフレームワークに依存する展開の場合:If the app is a framework-dependent deployment:

  1. コマンド プロンプトで展開フォルダーに移動し、dotnet.exe 使用してアプリのアセンブリを実行して、アプリを実行します。At a command prompt, navigate to the deployment folder and run the app by executing the app's assembly with dotnet.exe. コマンド < の dotnet .\<assembly_name>.dllassembly_name> にアプリのアセンブリの名前を指定して実行します。In the following command, substitute the name of the app's assembly for <assembly_name>: dotnet .\<assembly_name>.dll.
  2. エラーを示すアプリからのコンソール出力は、すべてコンソール ウィンドウに書き込まれます。The console output from the app, showing any errors, is written to the console window.
  3. アプリへの要求時にエラーが発生した場合は、Kestrel がリッスンしているホストとポートに要求が送信されます。If the errors occur when making a request to the app, make a request to the host and port where Kestrel listens. 既定のホストと post を使用して http://localhost:5000/ に要求を行います。Using the default host and post, make a request to http://localhost:5000/. アプリが Kestrel のエンドポイント アドレスで正常に応答する場合、問題はホスティングの構成に関連している可能性が高く、アプリ内が原因の可能性は低くなります。If the app responds normally at the Kestrel endpoint address, the problem is more likely related to the hosting configuration and less likely within the app.

自己完結型の展開Self-contained deployment

アプリが自己完結型の展開の場合:If the app is a self-contained deployment:

  1. コマンド プロンプトで、展開フォルダーに移動し、アプリの実行可能ファイルを実行します。At a command prompt, navigate to the deployment folder and run the app's executable. コマンド < の <assembly_name>.exeassembly_name> にアプリのアセンブリの名前を指定して実行します。In the following command, substitute the name of the app's assembly for <assembly_name>: <assembly_name>.exe.
  2. エラーを示すアプリからのコンソール出力は、すべてコンソール ウィンドウに書き込まれます。The console output from the app, showing any errors, is written to the console window.
  3. アプリへの要求時にエラーが発生した場合は、Kestrel がリッスンしているホストとポートに要求が送信されます。If the errors occur when making a request to the app, make a request to the host and port where Kestrel listens. 既定のホストと post を使用して http://localhost:5000/ に要求を行います。Using the default host and post, make a request to http://localhost:5000/. アプリが Kestrel のエンドポイント アドレスで正常に応答する場合、問題はホスティングの構成に関連している可能性が高く、アプリ内が原因の可能性は低くなります。If the app responds normally at the Kestrel endpoint address, the problem is more likely related to the hosting configuration and less likely within the app.

ASP.NET Core モジュールの stdout ログ (IIS)ASP.NET Core Module stdout log (IIS)

stdout ログを有効にして表示するには:To enable and view stdout logs:

  1. ホスティング システム上のサイトの展開フォルダーに移動します。Navigate to the site's deployment folder on the hosting system.
  2. logs フォルダーが存在しない場合は、フォルダーを作成します。If the logs folder isn't present, create the folder. MSBuild で展開フォルダーに logs フォルダーを自動的に作成されるようにする手順については、「ディレクトリ構造」のトピックを参照してください。For instructions on how to enable MSBuild to create the logs folder in the deployment automatically, see the Directory structure topic.
  3. web.config ファイルを編集します。Edit the web.config file. stdoutLogEnabledtrue に設定し、stdoutLogFile のパスを logs フォルダー (たとえば .\logs\stdout) を指すように変更します。Set stdoutLogEnabled to true and change the stdoutLogFile path to point to the logs folder (for example, .\logs\stdout). パスの stdout はログ ファイル名のプレフィックスです。stdout in the path is the log file name prefix. ログ ファイルの作成時には、タイムスタンプ、プロセス ID、およびファイルの拡張子が自動的に追加されます。A timestamp, process id, and file extension are added automatically when the log is created. ファイル名のプレフィックスとして stdout を使用すると、一般的なログ ファイルの名前は stdout_20180205184032_5412.log になります。Using stdout as the file name prefix, a typical log file is named stdout_20180205184032_5412.log.
  4. アプリケーション プールの ID に logs フォルダーへの書き込みアクセス許可があることを確認します。Ensure your application pool's identity has write permissions to the logs folder.
  5. 更新した web.config ファイルを保存します。Save the updated web.config file.
  6. アプリに対して要求します。Make a request to the app.
  7. logs フォルダーに移動します。Navigate to the logs folder. 最新の stdout ログを探して開きます。Find and open the most recent stdout log.
  8. ログのエラーを調べます。Study the log for errors.

トラブルシューティングが完了したら、stdout ログを無効にします。Disable stdout logging when troubleshooting is complete:

  1. web.config ファイルを編集します。Edit the web.config file.
  2. stdoutLogEnabledfalse に設定します。Set stdoutLogEnabled to false.
  3. ファイルを保存します。Save the file.

詳細については、ASP.NET Core モジュール を参照してください。For more information, see ASP.NET Core モジュール.

警告

stdout ログを無効にしないと、アプリまたはサーバーで障害が発生する可能性があります。Failure to disable the stdout log can lead to app or server failure. ログ ファイルのサイズまたは作成されるログ ファイルの数に制限はありません。There's no limit on log file size or the number of log files created.

ASP.NET Core アプリでのルーチン ログの場合は、ログ ファイルのサイズを制限し、ログをローテーションするログ ライブラリを使います。For routine logging in an ASP.NET Core app, use a logging library that limits log file size and rotates logs. 詳しくは、「サードパーティ製のログ プロバイダー」をご覧ください。For more information, see third-party logging providers.

ASP.NET Core モジュールデバッグログ (IIS)ASP.NET Core Module debug log (IIS)

次のハンドラー設定をアプリのweb.configファイルに追加して、ASP.NET Core モジュールのデバッグログを有効にします。Add the following handler settings to the app's web.config file to enable ASP.NET Core Module debug log:

<aspNetCore ...>
  <handlerSettings>
    <handlerSetting name="debugLevel" value="file" />
    <handlerSetting name="debugFile" value="c:\temp\ancm.log" />
  </handlerSettings>
</aspNetCore>

ログに指定されたパスが存在することと、アプリ プールの ID にその場所への書き込みアクセス許可があることを確認します。Confirm that the path specified for the log exists and that the app pool's identity has write permissions to the location.

詳細については、ASP.NET Core モジュール を参照してください。For more information, see ASP.NET Core モジュール.

開発者例外ページを有効にするEnable the Developer Exception Page

ASPNETCORE_ENVIRONMENT環境変数を web.config に追加して、開発環境でアプリを実行できます。The ASPNETCORE_ENVIRONMENT environment variable can be added to web.config to run the app in the Development environment. アプリの起動時にホスト ビルダー上で UseEnvironment によって環境がオーバーライドされない限り、環境変数を設定すると、アプリの実行時に開発者例外ページが表示されます。As long as the environment isn't overridden in app startup by UseEnvironment on the host builder, setting the environment variable allows the Developer Exception Page to appear when the app is run.

<aspNetCore processPath="dotnet"
      arguments=".\MyApp.dll"
      stdoutLogEnabled="false"
      stdoutLogFile=".\logs\stdout"
      hostingModel="InProcess">
  <environmentVariables>
    <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Development" />
  </environmentVariables>
</aspNetCore>

ASPNETCORE_ENVIRONMENT の環境変数を設定する方法は、インターネットに公開されないステージング サーバーやテスト用サーバーの場合にのみお勧めされます。Setting the environment variable for ASPNETCORE_ENVIRONMENT is only recommended for use on staging and testing servers that aren't exposed to the Internet. トラブルシューティング後は、必ず web.config ファイルからこの環境変数を削除してください。Remove the environment variable from the web.config file after troubleshooting. web.config で環境変数を設定する方法の詳細については、aspNetCore の environmentVariables 子要素を参照してください。For information on setting environment variables in web.config, see environmentVariables child element of aspNetCore.

アプリからデータを取得するObtain data from an app

アプリが要求に応答できる場合は、ターミナル インライン ミドルウェアを使用して、要求、接続、その他のデータをアプリから取得します。If an app is capable of responding to requests, obtain request, connection, and additional data from the app using terminal inline middleware. 詳細およびサンプル コードについては、「ASP.NET Core プロジェクトのトラブルシューティングとデバッグ」を参照してください。For more information and sample code, see ASP.NET Core プロジェクトのトラブルシューティングとデバッグ.

低速またはハング中のアプリ (IIS)Slow or hanging app (IIS)

"クラッシュ ダンプ" とはシステムのメモリのスナップショットであり、アプリのクラッシュ、起動の失敗、遅いアプリの原因を突き止めるのに役立ちます。A crash dump is a snapshot of the system's memory and can help determine the cause of an app crash, startup failure, or slow app.

アプリのクラッシュまたは例外の発生App crashes or encounters an exception

Windows エラー報告 (WER) からダンプを取得して分析します。Obtain and analyze a dump from Windows Error Reporting (WER):

  1. c:\dumps にクラッシュ ダンプ ファイルを保持するフォルダーを作成します。Create a folder to hold crash dump files at c:\dumps. アプリ プールには、そのフォルダーへの書き込みアクセス権が必要です。The app pool must have write access to the folder.

  2. EnableDumps PowerShell スクリプト を実行します。Run the EnableDumps PowerShell script:

  3. クラッシュが発生する条件の下でアプリを実行します。Run the app under the conditions that cause the crash to occur.

  4. クラッシュが発生した後、DisableDumps PowerShell スクリプトを実行します。After the crash has occurred, run the DisableDumps PowerShell script:

アプリがクラッシュし、ダンプの収集が完了したら、アプリを普通に終了してかまいません。After an app crashes and dump collection is complete, the app is allowed to terminate normally. PowerShell スクリプトにより、アプリごとに最大 5 つのダンプを収集する WER が構成されます。The PowerShell script configures WER to collect up to five dumps per app.

警告

クラッシュ ダンプでは、大量のディスク領域 (1 つにつき最大、数ギガバイト) が使用される場合があります。Crash dumps might take up a large amount of disk space (up to several gigabytes each).

アプリが起動時または正常な実行中にハングまたは失敗するApp hangs, fails during startup, or runs normally

アプリがハングした (応答が停止してもクラッシュしない) 場合、起動時に失敗した場合、または正常に実行された場合は、「ユーザーモードのダンプファイル:ダンプを生成する適切なツールを選択する最適なツールを選択する」を参照してください。When an app hangs (stops responding but doesn't crash), fails during startup, or runs normally, see User-Mode Dump Files: Choosing the Best Tool to select an appropriate tool to produce the dump.

ダンプを分析するAnalyze the dump

ダンプはいくつかの方法で分析できます。A dump can be analyzed using several approaches. 詳細については、「Analyzing a User-Mode Dump File」(ユーザー モード ダンプ ファイルの分析) を参照してください。For more information, see Analyzing a User-Mode Dump File.

パッケージ キャッシュをクリアするClear package caches

開発マシンで .NET Core SDK をアップグレードしたり、アプリ内のパッケージ バージョンを変更したりした直後に、機能しているアプリが失敗することがあります。A functioning app may fail immediately after upgrading either the .NET Core SDK on the development machine or changing package versions within the app. 場合によっては、パッケージに統一性がないと、メジャー アップグレード実行時にアプリが破壊されることがあります。In some cases, incoherent packages may break an app when performing major upgrades. これらの問題のほとんどは、次の手順で解決できます。Most of these issues can be fixed by following these instructions:

  1. bin フォルダーと obj フォルダーを削除します。Delete the bin and obj folders.

  2. コマンド シェルから dotnet nuget locals all --clear を実行して、パッケージ キャッシュをクリアします。Clear the package caches by executing dotnet nuget locals all --clear from a command shell.

    パッケージ キャッシュをクリアするには、nuget.exe ツールを使用して nuget locals all -clear コマンドを実行する方法もあります。Clearing package caches can also be accomplished with the nuget.exe tool and executing the command nuget locals all -clear. nuget.exe は、Windows デスクトップ オペレーティング システムにバンドルされているインストールではなく、NuGet Web サイトから別に入手する必要があります。nuget.exe isn't a bundled install with the Windows desktop operating system and must be obtained separately from the NuGet website.

  3. プロジェクトを復元してリビルドします。Restore and rebuild the project.

  4. アプリを再展開する前に、サーバー上の展開フォルダー内のすべてのファイルを削除します。Delete all of the files in the deployment folder on the server prior to redeploying the app.

その他のリソースAdditional resources

Azure のドキュメントAzure documentation

Visual Studio ドキュメントVisual Studio documentation

Visual Studio Code のドキュメントVisual Studio Code documentation

この記事では、アプリの起動時に発生する一般的なエラーと、アプリが Azure App Service または IIS に展開されたときのエラーを診断する手順について説明します。This article provides information on common app startup errors and instructions on how to diagnose errors when an app is deployed to Azure App Service or IIS:

アプリのスタートアップエラーApp startup errors
一般的なスタートアップ HTTP 状態コードのシナリオについて説明します。Explains common startup HTTP status code scenarios.

Azure App Service でのトラブルシューティングTroubleshoot on Azure App Service
Azure App Service に展開されたアプリに関するトラブルシューティングのアドバイスを提供します。Provides troubleshooting advice for apps deployed to Azure App Service.

IIS でのトラブルシューティングTroubleshoot on IIS
IIS に展開されているか IIS Express ローカルで実行されているアプリに関するトラブルシューティングのアドバイスを提供します。Provides troubleshooting advice for apps deployed to IIS or running on IIS Express locally. このガイダンスは、Windows Server と Windows デスクトップの両方の展開に適用されます。The guidance applies to both Windows Server and Windows desktop deployments.

パッケージキャッシュのクリアClear package caches
メジャーアップグレードの実行時またはパッケージバージョンの変更時に統一性パッケージがアプリを中断した場合の対処方法について説明します。Explains what to do when incoherent packages break an app when performing major upgrades or changing package versions.

その他のリソースAdditional resources
トラブルシューティングに関するその他のトピックを示します。Lists additional troubleshooting topics.

アプリ起動時のエラーApp startup errors

Visual Studio では、ASP.NET Core プロジェクトのデバッグ時に IIS Express のホスティングが既定の設定です。In Visual Studio, an ASP.NET Core project defaults to IIS Express hosting during debugging. このトピックのアドバイスを使用してローカルでデバッグすると、 502.5 プロセスエラーまたは500.30 開始エラーが発生します。A 502.5 - Process Failure or a 500.30 - Start Failure that occurs when debugging locally can be diagnosed using the advice in this topic.

403.14 許可されていません403.14 Forbidden

アプリを起動できません。The app fails to start. 次のエラーがログに記録されます。The following error is logged:

The Web server is configured to not list the contents of this directory.

このエラーが発生するのは、通常、ホストシステム上の展開が壊れている場合です。これには、次のようなシナリオが含まれます。The error is usually caused by a broken deployment on the hosting system, which includes any of the following scenarios:

  • アプリがホストシステムの間違ったフォルダーに配置されています。The app is deployed to the wrong folder on the hosting system.
  • 展開プロセスで、アプリのすべてのファイルとフォルダーを、ホスティングシステムの展開フォルダーに移動できませんでした。The deployment process failed to move all of the app's files and folders to the deployment folder on the hosting system.
  • 配置に web.config ファイルがないか、web.configファイルの内容形式が正しくありません。The web.config file is missing from the deployment, or the web.config file contents are malformed.

次の手順に従います。Perform the following steps:

  1. ホストシステム上の展開フォルダーからすべてのファイルとフォルダーを削除します。Delete all of the files and folders from the deployment folder on the hosting system.
  2. Visual Studio、PowerShell、手動デプロイなどの通常のデプロイ方法を使用して、アプリのpublishフォルダーの内容をホスティングシステムに再デプロイします。Redeploy the contents of the app's publish folder to the hosting system using your normal method of deployment, such as Visual Studio, PowerShell, or manual deployment:
    • 配置に web.configファイルが存在し、その内容が正しいことを確認します。Confirm that the web.config file is present in the deployment and that its contents are correct.
    • Azure App Service でホストする場合は、アプリが D:\home\site\wwwroot フォルダーに展開されていることを確認します。When hosting on Azure App Service, confirm that the app is deployed to the D:\home\site\wwwroot folder.
    • アプリが IIS によってホストされている場合は、iisマネージャー[基本設定] に表示されている iis の物理パスにアプリが展開されていることを確認します。When the app is hosted by IIS, confirm that the app is deployed to the IIS Physical path shown in IIS Manager's Basic Settings.
  3. ホスティングシステムの配置をプロジェクトのpublishフォルダーの内容と比較することによって、アプリのすべてのファイルとフォルダーが展開されていることを確認します。Confirm that all of the app's files and folders are deployed by comparing the deployment on the hosting system to the contents of the project's publish folder.

発行された ASP.NET Core アプリのレイアウトの詳細については、「ASP.NET Core のディレクトリ構造」を参照してください。For more information on the layout of a published ASP.NET Core app, see ASP.NET Core のディレクトリ構造. Web.config ファイルの詳細については、「ASP.NET Core モジュール」を参照してください。For more information on the web.config file, see ASP.NET Core モジュール.

500 内部サーバー エラー500 Internal Server Error

アプリは起動しますが、エラーのためにサーバーは要求を実行できません。The app starts, but an error prevents the server from fulfilling the request.

このエラーは、起動時または応答の作成中に、アプリのコード内で発生します。This error occurs within the app's code during startup or while creating a response. 応答にコンテンツが含まれていないか、またはブラウザーに "500 内部サーバー エラー" という応答が表示される可能性があります。The response may contain no content, or the response may appear as a 500 Internal Server Error in the browser. 通常、アプリケーション イベント ログではアプリが正常に起動したことが示されます。The Application Event Log usually states that the app started normally. サーバーから見るとそれは正しいことです。From the server's perspective, that's correct. アプリは起動しましたが、有効な応答を生成できません。The app did start, but it can't generate a valid response. サーバーのコマンドプロンプトでアプリを実行するか、ASP.NET Core モジュールの stdout ログを有効にして問題のトラブルシューティングを行います。Run the app at a command prompt on the server or enable the ASP.NET Core Module stdout log to troubleshoot the problem.

500.0 インプロセス ハンドラーの読み込みエラー500.0 In-Process Handler Load Failure

ワーカー プロセスが失敗します。The worker process fails. アプリは起動しません。The app doesn't start.

ASP.NET Core モジュールが .NET Core CLR を見つけられず、インプロセス要求ハンドラー (aspnetcorev2_inprocess) を検索できません。The ASP.NET Core Module fails to find the .NET Core CLR and find the in-process request handler (aspnetcorev2_inprocess.dll). 以下を確認します。Check that:

500.0 アウト プロセス ハンドラーの読み込みエラー500.0 Out-Of-Process Handler Load Failure

ワーカー プロセスが失敗します。The worker process fails. アプリは起動しません。The app doesn't start.

ASP.NET Core モジュールは、アウトプロセスホスティング要求ハンドラーを見つけることができません。The ASP.NET Core Module fails to find the out-of-process hosting request handler. aspnetcorev2_outofprocess.dllaspnetcorev2.dll の隣のサブフォルダーにあることを確認してください。Make sure the aspnetcorev2_outofprocess.dll is present in a subfolder next to aspnetcorev2.dll.

502.5 処理エラー502.5 Process Failure

ワーカー プロセスが失敗します。The worker process fails. アプリは起動しません。The app doesn't start.

ASP.NET Core モジュールはワーカー プロセスの開始を試みますが、開始に失敗します。The ASP.NET Core Module attempts to start the worker process but it fails to start. プロセス起動エラーの原因は、通常、アプリケーションイベントログのエントリと、ASP.NET Core モジュールの stdout ログによって決まります。The cause of a process startup failure can usually be determined from entries in the Application Event Log and the ASP.NET Core Module stdout log.

一般的なエラー条件は、存在しないバージョンの ASP.NET Core 共有フレームワークが対象にされていて、アプリが正しく構成されていないことです。A common failure condition is the app is misconfigured due to targeting a version of the ASP.NET Core shared framework that isn't present. 対象のコンピューターにどのバージョンの ASP.NET Core 共有フレームワークがインストールされているかを確認します。Check which versions of the ASP.NET Core shared framework are installed on the target machine. 共有フレームワークは、コンピューター上にインストールされたアセンブリ ( .dll ファイル) のセットであり、Microsoft.AspNetCore.App などのメタパッケージによって参照されます。The shared framework is the set of assemblies (.dll files) that are installed on the machine and referenced by a metapackage such as Microsoft.AspNetCore.App. メタパッケージの参照には、必要な最低限のバージョンを指定できます。The metapackage reference can specify a minimum required version. 詳しくは、共有フレームワークに関するページをご覧ください。For more information, see The shared framework.

正しく構成されていないホスティングやアプリが原因でワーカー プロセスが失敗する場合、"502.5 処理エラー" のエラー ページが返されます。The 502.5 Process Failure error page is returned when a hosting or app misconfiguration causes the worker process to fail:

アプリケーションの起動に失敗しました (ErrorCode '0x800700c1')Failed to start application (ErrorCode '0x800700c1')

EventID: 1010
Source: IIS AspNetCore Module V2
Failed to start application '/LM/W3SVC/6/ROOT/', ErrorCode '0x800700c1'.

アプリのアセンブリ ( .dll) を読み込めなかったため、アプリの起動に失敗しました。The app failed to start because the app's assembly (.dll) couldn't be loaded.

このエラーは、公開されたアプリと w3wp/iisexpress プロセスの間でビットの不一致がある場合に発生します。This error occurs when there's a bitness mismatch between the published app and the w3wp/iisexpress process.

アプリ プールの 32 ビット設定が正しいことを確認してください。Confirm that the app pool's 32-bit setting is correct:

  1. IIS マネージャーの [アプリケーション プール] でそのアプリ プールを選択します。Select the app pool in IIS Manager's Application Pools.
  2. [アクション] パネルの [アプリケーション プールの編集][詳細設定] を選択します。Select Advanced Settings under Edit Application Pool in the Actions panel.
  3. [32 ビット アプリケーションの有効化] を設定します。Set Enable 32-Bit Applications:
    • 32 ビット (x86) アプリを展開する場合は、この値を True に設定します。If deploying a 32-bit (x86) app, set the value to True.
    • 64 ビット (x64) アプリを展開する場合は、この値を False に設定します。If deploying a 64-bit (x64) app, set the value to False.

プロジェクトファイルの <Platform> MSBuild プロパティとアプリの発行済みビットとの間で競合が発生していないことを確認します。Confirm that there isn't a conflict between a <Platform> MSBuild property in the project file and the published bitness of the app.

接続のリセットConnection reset

ヘッダー送信後にエラーが発生した場合、サーバーが 500 内部サーバー エラーを送信するには遅すぎます。If an error occurs after the headers are sent, it's too late for the server to send a 500 Internal Server Error when an error occurs. このような状況は、応答に対する複雑なオブジェクトのシリアル化中にエラーが起きたときによく発生します。This often happens when an error occurs during the serialization of complex objects for a response. この種のエラーは、クライアントでは "接続リセット" エラーとして表示されます。This type of error appears as a connection reset error on the client. この種のエラーのトラブルシューティングには、アプリケーション ログが役に立つことがあります。Application logging can help troubleshoot these types of errors.

既定の起動制限Default startup limits

ASP.NET Core モジュールは、120秒の既定のstartupTimeLimitを使用して構成されています。The ASP.NET Core Module is configured with a default startupTimeLimit of 120 seconds. 既定値のままにした場合、モジュールで処理エラーが記録されるまでに、アプリは最大で 2 分を起動にかけることができます。When left at the default value, an app may take up to two minutes to start before the module logs a process failure. モジュールの構成の詳細については、「AspNetCore 要素の属性」を参照してください。For information on configuring the module, see Attributes of the aspNetCore element.

Azure App Service でのトラブルシューティングTroubleshoot on Azure App Service

重要

Azure App Service と ASP.NET Core のプレビュー リリースASP.NET Core preview releases with Azure App Service

ASP.NET Core のプレビュー リリースは、既定では Azure App Service に展開されません。ASP.NET Core preview releases aren't deployed to Azure App Service by default. ASP.NET Core プレビュー リリースを使用するアプリをホストするには、「Azure App Service に ASP.NET Core プレビュー リリースを展開する」を参照してください。To host an app that uses an ASP.NET Core preview release, see Deploy ASP.NET Core preview release to Azure App Service.

アプリケーションイベントログ (Azure App Service)Application Event Log (Azure App Service)

アプリケーション イベント ログにアクセスするには、Azure portal の [問題の診断と解決] ブレードを使います。To access the Application Event Log, use the Diagnose and solve problems blade in the Azure portal:

  1. Azure portal の [App Services] でアプリを開きます。In the Azure portal, open the app in App Services.
  2. [Diagnose and solve prolems](問題の診断と解決) を選択します。Select Diagnose and solve problems.
  3. [診断ツール] という見出しを選択します。Select the Diagnostic Tools heading.
  4. [サポート ツール][アプリケーション イベント] ボタンを選択します。Under Support Tools, select the Application Events button.
  5. [Source](ソース) 列で、IIS AspNetCoreModule または IIS AspNetCoreModule V2 によって提供された最新のエラーを調べます。Examine the latest error provided by the IIS AspNetCoreModule or IIS AspNetCoreModule V2 entry in the Source column.

[問題の診断と解決] ブレードを使う代わりに、Kudu を使ってアプリケーション イベント ログ ファイルを直接調べることもできます。An alternative to using the Diagnose and solve problems blade is to examine the Application Event Log file directly using Kudu:

  1. [開発ツール] 領域で [高度なツール] を開きます。Open Advanced Tools in the Development Tools area. [Go→] ボタンを選びます。Select the Go→ button. 新しいブラウザー タブまたはウィンドウで Kudu コンソールが開きます。The Kudu console opens in a new browser tab or window.
  2. ページの上部にあるナビゲーション バーを使って [デバッグ コンソール] を開き、 [CMD] を選びます。Using the navigation bar at the top of the page, open Debug console and select CMD.
  3. LogFiles フォルダーを開きます。Open the LogFiles folder.
  4. eventlog.xml ファイルの横にある鉛筆アイコンを選びます。Select the pencil icon next to the eventlog.xml file.
  5. ログを調べます。Examine the log. ログの末尾までスクロールし、最新のイベントを確認します。Scroll to the bottom of the log to see the most recent events.

Kudu コンソールでアプリを実行します。Run the app in the Kudu console

多くの起動時エラーでは、アプリケーション イベント ログに役に立つ情報が生成されません。Many startup errors don't produce useful information in the Application Event Log. Kudu のリモート実行コンソールでアプリを実行すると、エラーを検出することができます。You can run the app in the Kudu Remote Execution Console to discover the error:

  1. [開発ツール] 領域で [高度なツール] を開きます。Open Advanced Tools in the Development Tools area. [Go→] ボタンを選びます。Select the Go→ button. 新しいブラウザー タブまたはウィンドウで Kudu コンソールが開きます。The Kudu console opens in a new browser tab or window.
  2. ページの上部にあるナビゲーション バーを使って [デバッグ コンソール] を開き、 [CMD] を選びます。Using the navigation bar at the top of the page, open Debug console and select CMD.

32 ビット (x86) アプリをテストするTest a 32-bit (x86) app

現在のリリースCurrent release

  1. cd d:\home\site\wwwroot
  2. 次のようにアプリを実行します。Run the app:

エラーを示すアプリからのコンソール出力はすべて、Kudu コンソールにパイプされます。The console output from the app, showing any errors, is piped to the Kudu console.

プレビューリリースで実行されているフレームワークに依存する配置Framework-dependent deployment running on a preview release

"ASP.NET Core {バージョン} (x86) ランタイムのサイト拡張機能をインストールする必要があります。 "Requires installing the ASP.NET Core {VERSION} (x86) Runtime site extension.

  1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x32 ({X.Y} はランタイム バージョンです)cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x32 ({X.Y} is the runtime version)
  2. アプリを実行します: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dllRun the app: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

エラーを示すアプリからのコンソール出力はすべて、Kudu コンソールにパイプされます。The console output from the app, showing any errors, is piped to the Kudu console.

64 ビット (x64) アプリをテストするTest a 64-bit (x64) app

現在のリリースCurrent release

エラーを示すアプリからのコンソール出力はすべて、Kudu コンソールにパイプされます。The console output from the app, showing any errors, is piped to the Kudu console.

プレビューリリースで実行されているフレームワークに依存する配置Framework-dependent deployment running on a preview release

"ASP.NET Core {バージョン} (x64) ランタイムのサイト拡張機能をインストールする必要があります。 "Requires installing the ASP.NET Core {VERSION} (x64) Runtime site extension.

  1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x64 ({X.Y} はランタイム バージョンです)cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x64 ({X.Y} is the runtime version)
  2. アプリを実行します: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dllRun the app: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

エラーを示すアプリからのコンソール出力はすべて、Kudu コンソールにパイプされます。The console output from the app, showing any errors, is piped to the Kudu console.

ASP.NET Core モジュールの stdout ログ (Azure App Service)ASP.NET Core Module stdout log (Azure App Service)

ASP.NET Core モジュールの stdout には、アプリケーション イベント ログでは見つからない有用なエラー メッセージが記録されることがよくあります。The ASP.NET Core Module stdout log often records useful error messages not found in the Application Event Log. stdout ログを有効にして表示するには:To enable and view stdout logs:

  1. Azure portal で [問題の診断と解決] ブレードに移動します。Navigate to the Diagnose and solve problems blade in the Azure portal.
  2. [SELECT PROBLEM CATEGORY](問題カテゴリの選択) で、 [Web App Down](Web アプリのダウン) ボタンを選びます。Under SELECT PROBLEM CATEGORY, select the Web App Down button.
  3. [提案されたソリューション > Stdout ログリダイレクトを有効にする] で、[] ボタンを選択してKudu コンソールを開き、web.config を編集します。Under Suggested Solutions > Enable Stdout Log Redirection, select the button to Open Kudu Console to edit Web.Config.
  4. Kudu の診断コンソールで、パス site > wwwroot へのフォルダーを開きます。In the Kudu Diagnostic Console, open the folders to the path site > wwwroot. 下にスクロールして、一覧の最後にある web.config ファイルを表示します。Scroll down to reveal the web.config file at the bottom of the list.
  5. web.config ファイルの隣の鉛筆アイコンをクリックします。Click the pencil icon next to the web.config file.
  6. stdoutLogEnabledtrue に設定し、stdoutLogFile パスを \\?\%home%\LogFiles\stdout に変更します。Set stdoutLogEnabled to true and change the stdoutLogFile path to: \\?\%home%\LogFiles\stdout.
  7. [保存] を選んで、更新した web.config ファイルを保存します。Select Save to save the updated web.config file.
  8. アプリに対して要求します。Make a request to the app.
  9. Azure Portal に戻ります。Return to the Azure portal. [開発ツール] 領域で [高度なツール] ブレードを選びます。Select the Advanced Tools blade in the DEVELOPMENT TOOLS area. [Go→] ボタンを選びます。Select the Go→ button. 新しいブラウザー タブまたはウィンドウで Kudu コンソールが開きます。The Kudu console opens in a new browser tab or window.
  10. ページの上部にあるナビゲーション バーを使って [デバッグ コンソール] を開き、 [CMD] を選びます。Using the navigation bar at the top of the page, open Debug console and select CMD.
  11. LogFiles フォルダーを選択します。Select the LogFiles folder.
  12. [Modified](変更日) 列を調べて、変更日が最新の stdout ログの鉛筆アイコンを選んで編集します。Inspect the Modified column and select the pencil icon to edit the stdout log with the latest modification date.
  13. ログ ファイルが開くと、エラーが表示されます。When the log file opens, the error is displayed.

トラブルシューティングが完了したら、stdout ログを無効にします。Disable stdout logging when troubleshooting is complete:

  1. Kudu の診断コンソール で、パス site > wwwroot に戻り、web.config ファイルを表示します。In the Kudu Diagnostic Console, return to the path site > wwwroot to reveal the web.config file. 鉛筆アイコンを選んで web.config ファイルを再び開きます。Open the web.config file again by selecting the pencil icon.
  2. stdoutLogEnabledfalse に設定します。Set stdoutLogEnabled to false.
  3. [保存] を選んでファイルを保存します。Select Save to save the file.

詳細については、ASP.NET Core モジュール を参照してください。For more information, see ASP.NET Core モジュール.

警告

stdout ログを無効にしないと、アプリまたはサーバーで障害が発生する可能性があります。Failure to disable the stdout log can lead to app or server failure. ログ ファイルのサイズまたは作成されるログ ファイルの数に制限はありません。There's no limit on log file size or the number of log files created. stdout ログは、アプリ起動時の問題のトラブルシューティングにのみ使ってください。Only use stdout logging to troubleshoot app startup problems.

起動後の ASP.NET Core アプリでの一般的なログの場合は、ログ ファイルのサイズを制限し、ログをローテーションするログ ライブラリを使います。For general logging in an ASP.NET Core app after startup, use a logging library that limits log file size and rotates logs. 詳しくは、「サードパーティ製のログ プロバイダー」をご覧ください。For more information, see third-party logging providers.

ASP.NET Core モジュールデバッグログ (Azure App Service)ASP.NET Core Module debug log (Azure App Service)

ASP.NET Core モジュール デバッグ ログでは、ASP.NET Core モジュールのさらに詳しいログが提供されます。The ASP.NET Core Module debug log provides additional, deeper logging from the ASP.NET Core Module. stdout ログを有効にして表示するには:To enable and view stdout logs:

  1. 強化された診断ログを有効にするには、次のいずれかを実行します。To enable the enhanced diagnostic log, perform either of the following:
    • 強化された診断ログ」の指示に従い、強化された診断ログをアプリに対して設定します。Follow the instructions in Enhanced diagnostic logs to configure the app for an enhanced diagnostic logging. アプリを再デプロイします。Redeploy the app.
    • Kudu コンソールを利用し、「<handlerSettings>強化された診断ログ」にある をライブ アプリの web.config ファイルに追加します。Add the <handlerSettings> shown in Enhanced diagnostic logs to the live app's web.config file using the Kudu console:
      1. [開発ツール] 領域で [高度なツール] を開きます。Open Advanced Tools in the Development Tools area. [Go→] ボタンを選びます。Select the Go→ button. 新しいブラウザー タブまたはウィンドウで Kudu コンソールが開きます。The Kudu console opens in a new browser tab or window.
      2. ページの上部にあるナビゲーション バーを使って [デバッグ コンソール] を開き、 [CMD] を選びます。Using the navigation bar at the top of the page, open Debug console and select CMD.
      3. パス site > wwwroot へのフォルダーを開きます。Open the folders to the path site > wwwroot. 鉛筆アイコンを選択し、web.config ファイルを編集します。Edit the web.config file by selecting the pencil button. <handlerSettings>強化された診断ログ」にある セクションを追加します。Add the <handlerSettings> section as shown in Enhanced diagnostic logs. [保存] を選択します。Select the Save button.
  2. [開発ツール] 領域で [高度なツール] を開きます。Open Advanced Tools in the Development Tools area. [Go→] ボタンを選びます。Select the Go→ button. 新しいブラウザー タブまたはウィンドウで Kudu コンソールが開きます。The Kudu console opens in a new browser tab or window.
  3. ページの上部にあるナビゲーション バーを使って [デバッグ コンソール] を開き、 [CMD] を選びます。Using the navigation bar at the top of the page, open Debug console and select CMD.
  4. パス site > wwwroot へのフォルダーを開きます。Open the folders to the path site > wwwroot. aspnetcore-debug.log ファイルにパスを指定しなかった場合、ファイルが一覧に表示されます。If you didn't supply a path for the aspnetcore-debug.log file, the file appears in the list. パスを指定した場合、ログ ファイルの場所に移動します。If you supplied a path, navigate to the location of the log file.
  5. ファイル名の隣にある鉛筆アイコンでログ ファイルを開きます。Open the log file with the pencil button next to the file name.

トラブルシューティングが完了したら、debug ログを無効にします。Disable debug logging when troubleshooting is complete:

強化されたデバッグ ログを無効にするには、次のいずれかを実行します。To disable the enhanced debug log, perform either of the following:

  • ローカルの <handlerSettings>web.configファイルから を削除し、アプリを再デプロイします。Remove the <handlerSettings> from the web.config file locally and redeploy the app.
  • Kudu コンソールを使用して web.config ファイルを編集し、<handlerSettings> セクションを削除します。Use the Kudu console to edit the web.config file and remove the <handlerSettings> section. ファイルを保存します。Save the file.

詳細については、ASP.NET Core モジュール を参照してください。For more information, see ASP.NET Core モジュール.

警告

debug ログを無効にしないと、アプリまたはサーバーで障害が発生する可能性があります。Failure to disable the debug log can lead to app or server failure. ログ ファイルのサイズに制限はありません。There's no limit on log file size. debug ログは、アプリ起動時の問題のトラブルシューティングにのみ使ってください。Only use debug logging to troubleshoot app startup problems.

起動後の ASP.NET Core アプリでの一般的なログの場合は、ログ ファイルのサイズを制限し、ログをローテーションするログ ライブラリを使います。For general logging in an ASP.NET Core app after startup, use a logging library that limits log file size and rotates logs. 詳しくは、「サードパーティ製のログ プロバイダー」をご覧ください。For more information, see third-party logging providers.

低速またはハングしているアプリ (Azure App Service)Slow or hanging app (Azure App Service)

要求に対してアプリの反応が遅い場合、またはハングする場合は、次の記事を参照してください。When an app responds slowly or hangs on a request, see the following articles:

監視ブレードMonitoring blades

監視ブレードでは、このトピックでこれまでに説明した方法に代わるトラブルシューティング エクスペリエンスが提供されます。Monitoring blades provide an alternative troubleshooting experience to the methods described earlier in the topic. これらのブレードは、500 番台のエラーの診断に使用できます。These blades can be used to diagnose 500-series errors.

ASP.NET Core 拡張機能がインストールされていることを確認してください。Confirm that the ASP.NET Core Extensions are installed. 拡張機能がインストールされていない場合は、手動でインストールします。If the extensions aren't installed, install them manually:

  1. [開発ツール] ブレード セクションで、 [拡張機能] ブレードを選びます。In the DEVELOPMENT TOOLS blade section, select the Extensions blade.
  2. [ASP.NET Core Extensions](ASP.NET Core 拡張機能) が一覧に表示されます。The ASP.NET Core Extensions should appear in the list.
  3. 拡張機能がインストールされていない場合は、 [追加] ボタンを選びます。If the extensions aren't installed, select the Add button.
  4. 一覧から [ASP.NET Core Extensions](ASP.NET Core 拡張機能) を選びます。Choose the ASP.NET Core Extensions from the list.
  5. [OK] を選んで法的条項に同意します。Select OK to accept the legal terms.
  6. [拡張機能の追加] ブレードで [OK] を選びます。Select OK on the Add extension blade.
  7. 拡張機能が正常にインストールされると、情報ポップアップ メッセージで通知されます。An informational pop-up message indicates when the extensions are successfully installed.

stdout ログが有効になっていない場合は、次の手順のようにします。If stdout logging isn't enabled, follow these steps:

  1. Azure portal の [開発ツール] 領域で [高度なツール] ブレードを選びます。In the Azure portal, select the Advanced Tools blade in the DEVELOPMENT TOOLS area. [Go→] ボタンを選びます。Select the Go→ button. 新しいブラウザー タブまたはウィンドウで Kudu コンソールが開きます。The Kudu console opens in a new browser tab or window.
  2. ページの上部にあるナビゲーション バーを使って [デバッグ コンソール] を開き、 [CMD] を選びます。Using the navigation bar at the top of the page, open Debug console and select CMD.
  3. パスサイトのフォルダー > wwwrootを開き、下にスクロールして、一覧の下部にあるweb.config ファイルを表示します。Open the folders to the path site > wwwroot and scroll down to reveal the web.config file at the bottom of the list.
  4. web.config ファイルの隣の鉛筆アイコンをクリックします。Click the pencil icon next to the web.config file.
  5. stdoutLogEnabledtrue に設定し、stdoutLogFile パスを \\?\%home%\LogFiles\stdout に変更します。Set stdoutLogEnabled to true and change the stdoutLogFile path to: \\?\%home%\LogFiles\stdout.
  6. [保存] を選んで、更新した web.config ファイルを保存します。Select Save to save the updated web.config file.

続けて診断ログをアクティブにします。Proceed to activate diagnostic logging:

  1. Azure portal で [診断ログ] ブレードを選びます。In the Azure portal, select the Diagnostics logs blade.
  2. [アプリケーション ログ (ファイル システム)] および [詳細なエラー メッセージ][オン] スイッチを選びます。Select the On switch for Application Logging (Filesystem) and Detailed error messages. ブレードの上部にある [保存] ボタンを選びます。Select the Save button at the top of the blade.
  3. 失敗した要求イベントのバッファ処理 (FREB) とも呼ばれる失敗した要求のトレースを含めるには、 [失敗した要求のトレース][オン] スイッチを選びます。To include failed request tracing, also known as Failed Request Event Buffering (FREB) logging, select the On switch for Failed request tracing.
  4. ポータルで [診断ログ] ブレードのすぐ下にある [ログ ストリーム] ブレードを選びます。Select the Log stream blade, which is listed immediately under the Diagnostics logs blade in the portal.
  5. アプリに対して要求します。Make a request to the app.
  6. ログ ストリーム データ内で、エラーの原因が示されます。Within the log stream data, the cause of the error is indicated.

トラブルシューティングが完了したら、stdout ログを無効にしてください。Be sure to disable stdout logging when troubleshooting is complete.

失敗した要求のトレース ログ (FREB ログ) を見るには:To view the failed request tracing logs (FREB logs):

  1. Azure portal で [問題の診断と解決] ブレードに移動します。Navigate to the Diagnose and solve problems blade in the Azure portal.
  2. サイド バーの [SUPPORT TOOLS](サポート ツール) 領域で、 [Failed Request Tracing Logs](失敗した要求のトレース ログ) を選びます。Select Failed Request Tracing Logs from the SUPPORT TOOLS area of the sidebar.

詳しくは、「Azure App Service の Web アプリの診断ログの有効化」トピックの「失敗した要求トレース」セクションおよび「Azure での Web アプリのアプリケーションパフォーマンスに関するよくあるご質問」の「失敗した要求トレースをオンにするにはどうすればよいですか?」をご覧ください。See Failed request traces section of the Enable diagnostics logging for web apps in Azure App Service topic and the Application performance FAQs for Web Apps in Azure: How do I turn on failed request tracing? for more information.

詳しくは、「Azure App Service の Web アプリの診断ログの有効化」をご覧ください。For more information, see Enable diagnostics logging for web apps in Azure App Service.

警告

stdout ログを無効にしないと、アプリまたはサーバーで障害が発生する可能性があります。Failure to disable the stdout log can lead to app or server failure. ログ ファイルのサイズまたは作成されるログ ファイルの数に制限はありません。There's no limit on log file size or the number of log files created.

ASP.NET Core アプリでのルーチン ログの場合は、ログ ファイルのサイズを制限し、ログをローテーションするログ ライブラリを使います。For routine logging in an ASP.NET Core app, use a logging library that limits log file size and rotates logs. 詳しくは、「サードパーティ製のログ プロバイダー」をご覧ください。For more information, see third-party logging providers.

IIS でのトラブルシューティングTroubleshoot on IIS

アプリケーションイベントログ (IIS)Application Event Log (IIS)

アプリケーション イベント ログにアクセスします。Access the Application Event Log:

  1. [スタート] メニューを開き、イベント ビューアーを検索し、イベント ビューアー アプリを選択します。Open the Start menu, search for Event Viewer, and select the Event Viewer app.
  2. イベント ビューアー[Windows ログ] ノードを開きます。In Event Viewer, open the Windows Logs node.
  3. [Application] を選択して、アプリケーション イベント ログを開きます。Select Application to open the Application Event Log.
  4. 失敗したアプリに関連するエラーを検索します。Search for errors associated with the failing app. エラーの [ソース] 列には IIS AspNetCore Module または IIS Express AspNetCore Module の値が表示されます。Errors have a value of IIS AspNetCore Module or IIS Express AspNetCore Module in the Source column.

コマンド プロンプトでアプリを実行するRun the app at a command prompt

多くの起動時エラーでは、アプリケーション イベント ログに役に立つ情報が生成されません。Many startup errors don't produce useful information in the Application Event Log. ホスティング システムのコマンド プロンプトでアプリを実行すると、エラーの原因がわかることがあります。You can find the cause of some errors by running the app at a command prompt on the hosting system.

フレームワークに依存する展開Framework-dependent deployment

アプリがフレームワークに依存する展開の場合:If the app is a framework-dependent deployment:

  1. コマンド プロンプトで展開フォルダーに移動し、dotnet.exe 使用してアプリのアセンブリを実行して、アプリを実行します。At a command prompt, navigate to the deployment folder and run the app by executing the app's assembly with dotnet.exe. コマンド < の dotnet .\<assembly_name>.dllassembly_name> にアプリのアセンブリの名前を指定して実行します。In the following command, substitute the name of the app's assembly for <assembly_name>: dotnet .\<assembly_name>.dll.
  2. エラーを示すアプリからのコンソール出力は、すべてコンソール ウィンドウに書き込まれます。The console output from the app, showing any errors, is written to the console window.
  3. アプリへの要求時にエラーが発生した場合は、Kestrel がリッスンしているホストとポートに要求が送信されます。If the errors occur when making a request to the app, make a request to the host and port where Kestrel listens. 既定のホストと post を使用して http://localhost:5000/ に要求を行います。Using the default host and post, make a request to http://localhost:5000/. アプリが Kestrel のエンドポイント アドレスで正常に応答する場合、問題はホスティングの構成に関連している可能性が高く、アプリ内が原因の可能性は低くなります。If the app responds normally at the Kestrel endpoint address, the problem is more likely related to the hosting configuration and less likely within the app.

自己完結型の展開Self-contained deployment

アプリが自己完結型の展開の場合:If the app is a self-contained deployment:

  1. コマンド プロンプトで、展開フォルダーに移動し、アプリの実行可能ファイルを実行します。At a command prompt, navigate to the deployment folder and run the app's executable. コマンド < の <assembly_name>.exeassembly_name> にアプリのアセンブリの名前を指定して実行します。In the following command, substitute the name of the app's assembly for <assembly_name>: <assembly_name>.exe.
  2. エラーを示すアプリからのコンソール出力は、すべてコンソール ウィンドウに書き込まれます。The console output from the app, showing any errors, is written to the console window.
  3. アプリへの要求時にエラーが発生した場合は、Kestrel がリッスンしているホストとポートに要求が送信されます。If the errors occur when making a request to the app, make a request to the host and port where Kestrel listens. 既定のホストと post を使用して http://localhost:5000/ に要求を行います。Using the default host and post, make a request to http://localhost:5000/. アプリが Kestrel のエンドポイント アドレスで正常に応答する場合、問題はホスティングの構成に関連している可能性が高く、アプリ内が原因の可能性は低くなります。If the app responds normally at the Kestrel endpoint address, the problem is more likely related to the hosting configuration and less likely within the app.

ASP.NET Core モジュールの stdout ログ (IIS)ASP.NET Core Module stdout log (IIS)

stdout ログを有効にして表示するには:To enable and view stdout logs:

  1. ホスティング システム上のサイトの展開フォルダーに移動します。Navigate to the site's deployment folder on the hosting system.
  2. logs フォルダーが存在しない場合は、フォルダーを作成します。If the logs folder isn't present, create the folder. MSBuild で展開フォルダーに logs フォルダーを自動的に作成されるようにする手順については、「ディレクトリ構造」のトピックを参照してください。For instructions on how to enable MSBuild to create the logs folder in the deployment automatically, see the Directory structure topic.
  3. web.config ファイルを編集します。Edit the web.config file. stdoutLogEnabledtrue に設定し、stdoutLogFile のパスを logs フォルダー (たとえば .\logs\stdout) を指すように変更します。Set stdoutLogEnabled to true and change the stdoutLogFile path to point to the logs folder (for example, .\logs\stdout). パスの stdout はログ ファイル名のプレフィックスです。stdout in the path is the log file name prefix. ログ ファイルの作成時には、タイムスタンプ、プロセス ID、およびファイルの拡張子が自動的に追加されます。A timestamp, process id, and file extension are added automatically when the log is created. ファイル名のプレフィックスとして stdout を使用すると、一般的なログ ファイルの名前は stdout_20180205184032_5412.log になります。Using stdout as the file name prefix, a typical log file is named stdout_20180205184032_5412.log.
  4. アプリケーション プールの ID に logs フォルダーへの書き込みアクセス許可があることを確認します。Ensure your application pool's identity has write permissions to the logs folder.
  5. 更新した web.config ファイルを保存します。Save the updated web.config file.
  6. アプリに対して要求します。Make a request to the app.
  7. logs フォルダーに移動します。Navigate to the logs folder. 最新の stdout ログを探して開きます。Find and open the most recent stdout log.
  8. ログのエラーを調べます。Study the log for errors.

トラブルシューティングが完了したら、stdout ログを無効にします。Disable stdout logging when troubleshooting is complete:

  1. web.config ファイルを編集します。Edit the web.config file.
  2. stdoutLogEnabledfalse に設定します。Set stdoutLogEnabled to false.
  3. ファイルを保存します。Save the file.

詳細については、ASP.NET Core モジュール を参照してください。For more information, see ASP.NET Core モジュール.

警告

stdout ログを無効にしないと、アプリまたはサーバーで障害が発生する可能性があります。Failure to disable the stdout log can lead to app or server failure. ログ ファイルのサイズまたは作成されるログ ファイルの数に制限はありません。There's no limit on log file size or the number of log files created.

ASP.NET Core アプリでのルーチン ログの場合は、ログ ファイルのサイズを制限し、ログをローテーションするログ ライブラリを使います。For routine logging in an ASP.NET Core app, use a logging library that limits log file size and rotates logs. 詳しくは、「サードパーティ製のログ プロバイダー」をご覧ください。For more information, see third-party logging providers.

ASP.NET Core モジュールデバッグログ (IIS)ASP.NET Core Module debug log (IIS)

次のハンドラー設定をアプリのweb.configファイルに追加して、ASP.NET Core モジュールのデバッグログを有効にします。Add the following handler settings to the app's web.config file to enable ASP.NET Core Module debug log:

<aspNetCore ...>
  <handlerSettings>
    <handlerSetting name="debugLevel" value="file" />
    <handlerSetting name="debugFile" value="c:\temp\ancm.log" />
  </handlerSettings>
</aspNetCore>

ログに指定されたパスが存在することと、アプリ プールの ID にその場所への書き込みアクセス許可があることを確認します。Confirm that the path specified for the log exists and that the app pool's identity has write permissions to the location.

詳細については、ASP.NET Core モジュール を参照してください。For more information, see ASP.NET Core モジュール.

開発者例外ページを有効にするEnable the Developer Exception Page

ASPNETCORE_ENVIRONMENT環境変数を web.config に追加して、開発環境でアプリを実行できます。The ASPNETCORE_ENVIRONMENT environment variable can be added to web.config to run the app in the Development environment. アプリの起動時にホスト ビルダー上で UseEnvironment によって環境がオーバーライドされない限り、環境変数を設定すると、アプリの実行時に開発者例外ページが表示されます。As long as the environment isn't overridden in app startup by UseEnvironment on the host builder, setting the environment variable allows the Developer Exception Page to appear when the app is run.

<aspNetCore processPath="dotnet"
      arguments=".\MyApp.dll"
      stdoutLogEnabled="false"
      stdoutLogFile=".\logs\stdout"
      hostingModel="InProcess">
  <environmentVariables>
    <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Development" />
  </environmentVariables>
</aspNetCore>

ASPNETCORE_ENVIRONMENT の環境変数を設定する方法は、インターネットに公開されないステージング サーバーやテスト用サーバーの場合にのみお勧めされます。Setting the environment variable for ASPNETCORE_ENVIRONMENT is only recommended for use on staging and testing servers that aren't exposed to the Internet. トラブルシューティング後は、必ず web.config ファイルからこの環境変数を削除してください。Remove the environment variable from the web.config file after troubleshooting. web.config で環境変数を設定する方法の詳細については、aspNetCore の environmentVariables 子要素を参照してください。For information on setting environment variables in web.config, see environmentVariables child element of aspNetCore.

アプリからデータを取得するObtain data from an app

アプリが要求に応答できる場合は、ターミナル インライン ミドルウェアを使用して、要求、接続、その他のデータをアプリから取得します。If an app is capable of responding to requests, obtain request, connection, and additional data from the app using terminal inline middleware. 詳細およびサンプル コードについては、「ASP.NET Core プロジェクトのトラブルシューティングとデバッグ」を参照してください。For more information and sample code, see ASP.NET Core プロジェクトのトラブルシューティングとデバッグ.

低速またはハング中のアプリ (IIS)Slow or hanging app (IIS)

"クラッシュ ダンプ" とはシステムのメモリのスナップショットであり、アプリのクラッシュ、起動の失敗、遅いアプリの原因を突き止めるのに役立ちます。A crash dump is a snapshot of the system's memory and can help determine the cause of an app crash, startup failure, or slow app.

アプリのクラッシュまたは例外の発生App crashes or encounters an exception

Windows エラー報告 (WER) からダンプを取得して分析します。Obtain and analyze a dump from Windows Error Reporting (WER):

  1. c:\dumps にクラッシュ ダンプ ファイルを保持するフォルダーを作成します。Create a folder to hold crash dump files at c:\dumps. アプリ プールには、そのフォルダーへの書き込みアクセス権が必要です。The app pool must have write access to the folder.

  2. EnableDumps PowerShell スクリプト を実行します。Run the EnableDumps PowerShell script:

  3. クラッシュが発生する条件の下でアプリを実行します。Run the app under the conditions that cause the crash to occur.

  4. クラッシュが発生した後、DisableDumps PowerShell スクリプトを実行します。After the crash has occurred, run the DisableDumps PowerShell script:

アプリがクラッシュし、ダンプの収集が完了したら、アプリを普通に終了してかまいません。After an app crashes and dump collection is complete, the app is allowed to terminate normally. PowerShell スクリプトにより、アプリごとに最大 5 つのダンプを収集する WER が構成されます。The PowerShell script configures WER to collect up to five dumps per app.

警告

クラッシュ ダンプでは、大量のディスク領域 (1 つにつき最大、数ギガバイト) が使用される場合があります。Crash dumps might take up a large amount of disk space (up to several gigabytes each).

アプリが起動時または正常な実行中にハングまたは失敗するApp hangs, fails during startup, or runs normally

アプリがハングした (応答が停止してもクラッシュしない) 場合、起動時に失敗した場合、または正常に実行された場合は、「ユーザーモードのダンプファイル:ダンプを生成する適切なツールを選択する最適なツールを選択する」を参照してください。When an app hangs (stops responding but doesn't crash), fails during startup, or runs normally, see User-Mode Dump Files: Choosing the Best Tool to select an appropriate tool to produce the dump.

ダンプを分析するAnalyze the dump

ダンプはいくつかの方法で分析できます。A dump can be analyzed using several approaches. 詳細については、「Analyzing a User-Mode Dump File」(ユーザー モード ダンプ ファイルの分析) を参照してください。For more information, see Analyzing a User-Mode Dump File.

パッケージ キャッシュをクリアするClear package caches

開発マシンで .NET Core SDK をアップグレードしたり、アプリ内のパッケージ バージョンを変更したりした直後に、機能しているアプリが失敗することがあります。A functioning app may fail immediately after upgrading either the .NET Core SDK on the development machine or changing package versions within the app. 場合によっては、パッケージに統一性がないと、メジャー アップグレード実行時にアプリが破壊されることがあります。In some cases, incoherent packages may break an app when performing major upgrades. これらの問題のほとんどは、次の手順で解決できます。Most of these issues can be fixed by following these instructions:

  1. bin フォルダーと obj フォルダーを削除します。Delete the bin and obj folders.

  2. コマンド シェルから dotnet nuget locals all --clear を実行して、パッケージ キャッシュをクリアします。Clear the package caches by executing dotnet nuget locals all --clear from a command shell.

    パッケージ キャッシュをクリアするには、nuget.exe ツールを使用して nuget locals all -clear コマンドを実行する方法もあります。Clearing package caches can also be accomplished with the nuget.exe tool and executing the command nuget locals all -clear. nuget.exe は、Windows デスクトップ オペレーティング システムにバンドルされているインストールではなく、NuGet Web サイトから別に入手する必要があります。nuget.exe isn't a bundled install with the Windows desktop operating system and must be obtained separately from the NuGet website.

  3. プロジェクトを復元してリビルドします。Restore and rebuild the project.

  4. アプリを再展開する前に、サーバー上の展開フォルダー内のすべてのファイルを削除します。Delete all of the files in the deployment folder on the server prior to redeploying the app.

その他のリソースAdditional resources

Azure のドキュメントAzure documentation

Visual Studio ドキュメントVisual Studio documentation

Visual Studio Code のドキュメントVisual Studio Code documentation

この記事では、アプリの起動時に発生する一般的なエラーと、アプリが Azure App Service または IIS に展開されたときのエラーを診断する手順について説明します。This article provides information on common app startup errors and instructions on how to diagnose errors when an app is deployed to Azure App Service or IIS:

アプリのスタートアップエラーApp startup errors
一般的なスタートアップ HTTP 状態コードのシナリオについて説明します。Explains common startup HTTP status code scenarios.

Azure App Service でのトラブルシューティングTroubleshoot on Azure App Service
Azure App Service に展開されたアプリに関するトラブルシューティングのアドバイスを提供します。Provides troubleshooting advice for apps deployed to Azure App Service.

IIS でのトラブルシューティングTroubleshoot on IIS
IIS に展開されているか IIS Express ローカルで実行されているアプリに関するトラブルシューティングのアドバイスを提供します。Provides troubleshooting advice for apps deployed to IIS or running on IIS Express locally. このガイダンスは、Windows Server と Windows デスクトップの両方の展開に適用されます。The guidance applies to both Windows Server and Windows desktop deployments.

パッケージキャッシュのクリアClear package caches
メジャーアップグレードの実行時またはパッケージバージョンの変更時に統一性パッケージがアプリを中断した場合の対処方法について説明します。Explains what to do when incoherent packages break an app when performing major upgrades or changing package versions.

その他のリソースAdditional resources
トラブルシューティングに関するその他のトピックを示します。Lists additional troubleshooting topics.

アプリ起動時のエラーApp startup errors

Visual Studio では、ASP.NET Core プロジェクトのデバッグ時に IIS Express のホスティングが既定の設定です。In Visual Studio, an ASP.NET Core project defaults to IIS Express hosting during debugging. ローカルでデバッグするときに502.5 プロセスエラーが発生した場合は、このトピックのアドバイスを使用して診断できます。A 502.5 Process Failure that occurs when debugging locally can be diagnosed using the advice in this topic.

403.14 許可されていません403.14 Forbidden

アプリを起動できません。The app fails to start. 次のエラーがログに記録されます。The following error is logged:

The Web server is configured to not list the contents of this directory.

このエラーが発生するのは、通常、ホストシステム上の展開が壊れている場合です。これには、次のようなシナリオが含まれます。The error is usually caused by a broken deployment on the hosting system, which includes any of the following scenarios:

  • アプリがホストシステムの間違ったフォルダーに配置されています。The app is deployed to the wrong folder on the hosting system.
  • 展開プロセスで、アプリのすべてのファイルとフォルダーを、ホスティングシステムの展開フォルダーに移動できませんでした。The deployment process failed to move all of the app's files and folders to the deployment folder on the hosting system.
  • 配置に web.config ファイルがないか、web.configファイルの内容形式が正しくありません。The web.config file is missing from the deployment, or the web.config file contents are malformed.

次の手順に従います。Perform the following steps:

  1. ホストシステム上の展開フォルダーからすべてのファイルとフォルダーを削除します。Delete all of the files and folders from the deployment folder on the hosting system.
  2. Visual Studio、PowerShell、手動デプロイなどの通常のデプロイ方法を使用して、アプリのpublishフォルダーの内容をホスティングシステムに再デプロイします。Redeploy the contents of the app's publish folder to the hosting system using your normal method of deployment, such as Visual Studio, PowerShell, or manual deployment:
    • 配置に web.configファイルが存在し、その内容が正しいことを確認します。Confirm that the web.config file is present in the deployment and that its contents are correct.
    • Azure App Service でホストする場合は、アプリが D:\home\site\wwwroot フォルダーに展開されていることを確認します。When hosting on Azure App Service, confirm that the app is deployed to the D:\home\site\wwwroot folder.
    • アプリが IIS によってホストされている場合は、iisマネージャー[基本設定] に表示されている iis の物理パスにアプリが展開されていることを確認します。When the app is hosted by IIS, confirm that the app is deployed to the IIS Physical path shown in IIS Manager's Basic Settings.
  3. ホスティングシステムの配置をプロジェクトのpublishフォルダーの内容と比較することによって、アプリのすべてのファイルとフォルダーが展開されていることを確認します。Confirm that all of the app's files and folders are deployed by comparing the deployment on the hosting system to the contents of the project's publish folder.

発行された ASP.NET Core アプリのレイアウトの詳細については、「ASP.NET Core のディレクトリ構造」を参照してください。For more information on the layout of a published ASP.NET Core app, see ASP.NET Core のディレクトリ構造. Web.config ファイルの詳細については、「ASP.NET Core モジュール」を参照してください。For more information on the web.config file, see ASP.NET Core モジュール.

500 内部サーバー エラー500 Internal Server Error

アプリは起動しますが、エラーのためにサーバーは要求を実行できません。The app starts, but an error prevents the server from fulfilling the request.

このエラーは、起動時または応答の作成中に、アプリのコード内で発生します。This error occurs within the app's code during startup or while creating a response. 応答にコンテンツが含まれていないか、またはブラウザーに "500 内部サーバー エラー" という応答が表示される可能性があります。The response may contain no content, or the response may appear as a 500 Internal Server Error in the browser. 通常、アプリケーション イベント ログではアプリが正常に起動したことが示されます。The Application Event Log usually states that the app started normally. サーバーから見るとそれは正しいことです。From the server's perspective, that's correct. アプリは起動しましたが、有効な応答を生成できません。The app did start, but it can't generate a valid response. サーバーのコマンドプロンプトでアプリを実行するか、ASP.NET Core モジュールの stdout ログを有効にして問題のトラブルシューティングを行います。Run the app at a command prompt on the server or enable the ASP.NET Core Module stdout log to troubleshoot the problem.

502.5 処理エラー502.5 Process Failure

ワーカー プロセスが失敗します。The worker process fails. アプリは起動しません。The app doesn't start.

ASP.NET Core モジュールはワーカー プロセスの開始を試みますが、開始に失敗します。The ASP.NET Core Module attempts to start the worker process but it fails to start. プロセス起動エラーの原因は、通常、アプリケーションイベントログのエントリと、ASP.NET Core モジュールの stdout ログによって決まります。The cause of a process startup failure can usually be determined from entries in the Application Event Log and the ASP.NET Core Module stdout log.

一般的なエラー条件は、存在しないバージョンの ASP.NET Core 共有フレームワークが対象にされていて、アプリが正しく構成されていないことです。A common failure condition is the app is misconfigured due to targeting a version of the ASP.NET Core shared framework that isn't present. 対象のコンピューターにどのバージョンの ASP.NET Core 共有フレームワークがインストールされているかを確認します。Check which versions of the ASP.NET Core shared framework are installed on the target machine. 共有フレームワークは、コンピューター上にインストールされたアセンブリ ( .dll ファイル) のセットであり、Microsoft.AspNetCore.App などのメタパッケージによって参照されます。The shared framework is the set of assemblies (.dll files) that are installed on the machine and referenced by a metapackage such as Microsoft.AspNetCore.App. メタパッケージの参照には、必要な最低限のバージョンを指定できます。The metapackage reference can specify a minimum required version. 詳しくは、共有フレームワークに関するページをご覧ください。For more information, see The shared framework.

正しく構成されていないホスティングやアプリが原因でワーカー プロセスが失敗する場合、"502.5 処理エラー" のエラー ページが返されます。The 502.5 Process Failure error page is returned when a hosting or app misconfiguration causes the worker process to fail:

アプリケーションの起動に失敗しました (ErrorCode '0x800700c1')Failed to start application (ErrorCode '0x800700c1')

EventID: 1010
Source: IIS AspNetCore Module V2
Failed to start application '/LM/W3SVC/6/ROOT/', ErrorCode '0x800700c1'.

アプリのアセンブリ ( .dll) を読み込めなかったため、アプリの起動に失敗しました。The app failed to start because the app's assembly (.dll) couldn't be loaded.

このエラーは、公開されたアプリと w3wp/iisexpress プロセスの間でビットの不一致がある場合に発生します。This error occurs when there's a bitness mismatch between the published app and the w3wp/iisexpress process.

アプリ プールの 32 ビット設定が正しいことを確認してください。Confirm that the app pool's 32-bit setting is correct:

  1. IIS マネージャーの [アプリケーション プール] でそのアプリ プールを選択します。Select the app pool in IIS Manager's Application Pools.
  2. [アクション] パネルの [アプリケーション プールの編集][詳細設定] を選択します。Select Advanced Settings under Edit Application Pool in the Actions panel.
  3. [32 ビット アプリケーションの有効化] を設定します。Set Enable 32-Bit Applications:
    • 32 ビット (x86) アプリを展開する場合は、この値を True に設定します。If deploying a 32-bit (x86) app, set the value to True.
    • 64 ビット (x64) アプリを展開する場合は、この値を False に設定します。If deploying a 64-bit (x64) app, set the value to False.

プロジェクトファイルの <Platform> MSBuild プロパティとアプリの発行済みビットとの間で競合が発生していないことを確認します。Confirm that there isn't a conflict between a <Platform> MSBuild property in the project file and the published bitness of the app.

接続のリセットConnection reset

ヘッダー送信後にエラーが発生した場合、サーバーが 500 内部サーバー エラーを送信するには遅すぎます。If an error occurs after the headers are sent, it's too late for the server to send a 500 Internal Server Error when an error occurs. このような状況は、応答に対する複雑なオブジェクトのシリアル化中にエラーが起きたときによく発生します。This often happens when an error occurs during the serialization of complex objects for a response. この種のエラーは、クライアントでは "接続リセット" エラーとして表示されます。This type of error appears as a connection reset error on the client. この種のエラーのトラブルシューティングには、アプリケーション ログが役に立つことがあります。Application logging can help troubleshoot these types of errors.

既定の起動制限Default startup limits

ASP.NET Core モジュールは、120秒の既定のstartupTimeLimitを使用して構成されています。The ASP.NET Core Module is configured with a default startupTimeLimit of 120 seconds. 既定値のままにした場合、モジュールで処理エラーが記録されるまでに、アプリは最大で 2 分を起動にかけることができます。When left at the default value, an app may take up to two minutes to start before the module logs a process failure. モジュールの構成の詳細については、「AspNetCore 要素の属性」を参照してください。For information on configuring the module, see Attributes of the aspNetCore element.

Azure App Service でのトラブルシューティングTroubleshoot on Azure App Service

重要

Azure App Service と ASP.NET Core のプレビュー リリースASP.NET Core preview releases with Azure App Service

ASP.NET Core のプレビュー リリースは、既定では Azure App Service に展開されません。ASP.NET Core preview releases aren't deployed to Azure App Service by default. ASP.NET Core プレビュー リリースを使用するアプリをホストするには、「Azure App Service に ASP.NET Core プレビュー リリースを展開する」を参照してください。To host an app that uses an ASP.NET Core preview release, see Deploy ASP.NET Core preview release to Azure App Service.

アプリケーションイベントログ (Azure App Service)Application Event Log (Azure App Service)

アプリケーション イベント ログにアクセスするには、Azure portal の [問題の診断と解決] ブレードを使います。To access the Application Event Log, use the Diagnose and solve problems blade in the Azure portal:

  1. Azure portal の [App Services] でアプリを開きます。In the Azure portal, open the app in App Services.
  2. [Diagnose and solve prolems](問題の診断と解決) を選択します。Select Diagnose and solve problems.
  3. [診断ツール] という見出しを選択します。Select the Diagnostic Tools heading.
  4. [サポート ツール][アプリケーション イベント] ボタンを選択します。Under Support Tools, select the Application Events button.
  5. [Source](ソース) 列で、IIS AspNetCoreModule または IIS AspNetCoreModule V2 によって提供された最新のエラーを調べます。Examine the latest error provided by the IIS AspNetCoreModule or IIS AspNetCoreModule V2 entry in the Source column.

[問題の診断と解決] ブレードを使う代わりに、Kudu を使ってアプリケーション イベント ログ ファイルを直接調べることもできます。An alternative to using the Diagnose and solve problems blade is to examine the Application Event Log file directly using Kudu:

  1. [開発ツール] 領域で [高度なツール] を開きます。Open Advanced Tools in the Development Tools area. [Go→] ボタンを選びます。Select the Go→ button. 新しいブラウザー タブまたはウィンドウで Kudu コンソールが開きます。The Kudu console opens in a new browser tab or window.
  2. ページの上部にあるナビゲーション バーを使って [デバッグ コンソール] を開き、 [CMD] を選びます。Using the navigation bar at the top of the page, open Debug console and select CMD.
  3. LogFiles フォルダーを開きます。Open the LogFiles folder.
  4. eventlog.xml ファイルの横にある鉛筆アイコンを選びます。Select the pencil icon next to the eventlog.xml file.
  5. ログを調べます。Examine the log. ログの末尾までスクロールし、最新のイベントを確認します。Scroll to the bottom of the log to see the most recent events.

Kudu コンソールでアプリを実行します。Run the app in the Kudu console

多くの起動時エラーでは、アプリケーション イベント ログに役に立つ情報が生成されません。Many startup errors don't produce useful information in the Application Event Log. Kudu のリモート実行コンソールでアプリを実行すると、エラーを検出することができます。You can run the app in the Kudu Remote Execution Console to discover the error:

  1. [開発ツール] 領域で [高度なツール] を開きます。Open Advanced Tools in the Development Tools area. [Go→] ボタンを選びます。Select the Go→ button. 新しいブラウザー タブまたはウィンドウで Kudu コンソールが開きます。The Kudu console opens in a new browser tab or window.
  2. ページの上部にあるナビゲーション バーを使って [デバッグ コンソール] を開き、 [CMD] を選びます。Using the navigation bar at the top of the page, open Debug console and select CMD.

32 ビット (x86) アプリをテストするTest a 32-bit (x86) app

現在のリリースCurrent release

  1. cd d:\home\site\wwwroot
  2. 次のようにアプリを実行します。Run the app:

エラーを示すアプリからのコンソール出力はすべて、Kudu コンソールにパイプされます。The console output from the app, showing any errors, is piped to the Kudu console.

プレビューリリースで実行されているフレームワークに依存する配置Framework-dependent deployment running on a preview release

"ASP.NET Core {バージョン} (x86) ランタイムのサイト拡張機能をインストールする必要があります。 "Requires installing the ASP.NET Core {VERSION} (x86) Runtime site extension.

  1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x32 ({X.Y} はランタイム バージョンです)cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x32 ({X.Y} is the runtime version)
  2. アプリを実行します: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dllRun the app: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

エラーを示すアプリからのコンソール出力はすべて、Kudu コンソールにパイプされます。The console output from the app, showing any errors, is piped to the Kudu console.

64 ビット (x64) アプリをテストするTest a 64-bit (x64) app

現在のリリースCurrent release

エラーを示すアプリからのコンソール出力はすべて、Kudu コンソールにパイプされます。The console output from the app, showing any errors, is piped to the Kudu console.

プレビューリリースで実行されているフレームワークに依存する配置Framework-dependent deployment running on a preview release

"ASP.NET Core {バージョン} (x64) ランタイムのサイト拡張機能をインストールする必要があります。 "Requires installing the ASP.NET Core {VERSION} (x64) Runtime site extension.

  1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x64 ({X.Y} はランタイム バージョンです)cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x64 ({X.Y} is the runtime version)
  2. アプリを実行します: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dllRun the app: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

エラーを示すアプリからのコンソール出力はすべて、Kudu コンソールにパイプされます。The console output from the app, showing any errors, is piped to the Kudu console.

ASP.NET Core モジュールの stdout ログ (Azure App Service)ASP.NET Core Module stdout log (Azure App Service)

ASP.NET Core モジュールの stdout には、アプリケーション イベント ログでは見つからない有用なエラー メッセージが記録されることがよくあります。The ASP.NET Core Module stdout log often records useful error messages not found in the Application Event Log. stdout ログを有効にして表示するには:To enable and view stdout logs:

  1. Azure portal で [問題の診断と解決] ブレードに移動します。Navigate to the Diagnose and solve problems blade in the Azure portal.
  2. [SELECT PROBLEM CATEGORY](問題カテゴリの選択) で、 [Web App Down](Web アプリのダウン) ボタンを選びます。Under SELECT PROBLEM CATEGORY, select the Web App Down button.
  3. [提案されたソリューション > Stdout ログリダイレクトを有効にする] で、[] ボタンを選択してKudu コンソールを開き、web.config を編集します。Under Suggested Solutions > Enable Stdout Log Redirection, select the button to Open Kudu Console to edit Web.Config.
  4. Kudu の診断コンソールで、パス site > wwwroot へのフォルダーを開きます。In the Kudu Diagnostic Console, open the folders to the path site > wwwroot. 下にスクロールして、一覧の最後にある web.config ファイルを表示します。Scroll down to reveal the web.config file at the bottom of the list.
  5. web.config ファイルの隣の鉛筆アイコンをクリックします。Click the pencil icon next to the web.config file.
  6. stdoutLogEnabledtrue に設定し、stdoutLogFile パスを \\?\%home%\LogFiles\stdout に変更します。Set stdoutLogEnabled to true and change the stdoutLogFile path to: \\?\%home%\LogFiles\stdout.
  7. [保存] を選んで、更新した web.config ファイルを保存します。Select Save to save the updated web.config file.
  8. アプリに対して要求します。Make a request to the app.
  9. Azure Portal に戻ります。Return to the Azure portal. [開発ツール] 領域で [高度なツール] ブレードを選びます。Select the Advanced Tools blade in the DEVELOPMENT TOOLS area. [Go→] ボタンを選びます。Select the Go→ button. 新しいブラウザー タブまたはウィンドウで Kudu コンソールが開きます。The Kudu console opens in a new browser tab or window.
  10. ページの上部にあるナビゲーション バーを使って [デバッグ コンソール] を開き、 [CMD] を選びます。Using the navigation bar at the top of the page, open Debug console and select CMD.
  11. LogFiles フォルダーを選択します。Select the LogFiles folder.
  12. [Modified](変更日) 列を調べて、変更日が最新の stdout ログの鉛筆アイコンを選んで編集します。Inspect the Modified column and select the pencil icon to edit the stdout log with the latest modification date.
  13. ログ ファイルが開くと、エラーが表示されます。When the log file opens, the error is displayed.

トラブルシューティングが完了したら、stdout ログを無効にします。Disable stdout logging when troubleshooting is complete:

  1. Kudu の診断コンソール で、パス site > wwwroot に戻り、web.config ファイルを表示します。In the Kudu Diagnostic Console, return to the path site > wwwroot to reveal the web.config file. 鉛筆アイコンを選んで web.config ファイルを再び開きます。Open the web.config file again by selecting the pencil icon.
  2. stdoutLogEnabledfalse に設定します。Set stdoutLogEnabled to false.
  3. [保存] を選んでファイルを保存します。Select Save to save the file.

詳細については、ASP.NET Core モジュール を参照してください。For more information, see ASP.NET Core モジュール.

警告

stdout ログを無効にしないと、アプリまたはサーバーで障害が発生する可能性があります。Failure to disable the stdout log can lead to app or server failure. ログ ファイルのサイズまたは作成されるログ ファイルの数に制限はありません。There's no limit on log file size or the number of log files created. stdout ログは、アプリ起動時の問題のトラブルシューティングにのみ使ってください。Only use stdout logging to troubleshoot app startup problems.

起動後の ASP.NET Core アプリでの一般的なログの場合は、ログ ファイルのサイズを制限し、ログをローテーションするログ ライブラリを使います。For general logging in an ASP.NET Core app after startup, use a logging library that limits log file size and rotates logs. 詳しくは、「サードパーティ製のログ プロバイダー」をご覧ください。For more information, see third-party logging providers.

低速またはハングしているアプリ (Azure App Service)Slow or hanging app (Azure App Service)

要求に対してアプリの反応が遅い場合、またはハングする場合は、次の記事を参照してください。When an app responds slowly or hangs on a request, see the following articles:

監視ブレードMonitoring blades

監視ブレードでは、このトピックでこれまでに説明した方法に代わるトラブルシューティング エクスペリエンスが提供されます。Monitoring blades provide an alternative troubleshooting experience to the methods described earlier in the topic. これらのブレードは、500 番台のエラーの診断に使用できます。These blades can be used to diagnose 500-series errors.

ASP.NET Core 拡張機能がインストールされていることを確認してください。Confirm that the ASP.NET Core Extensions are installed. 拡張機能がインストールされていない場合は、手動でインストールします。If the extensions aren't installed, install them manually:

  1. [開発ツール] ブレード セクションで、 [拡張機能] ブレードを選びます。In the DEVELOPMENT TOOLS blade section, select the Extensions blade.
  2. [ASP.NET Core Extensions](ASP.NET Core 拡張機能) が一覧に表示されます。The ASP.NET Core Extensions should appear in the list.
  3. 拡張機能がインストールされていない場合は、 [追加] ボタンを選びます。If the extensions aren't installed, select the Add button.
  4. 一覧から [ASP.NET Core Extensions](ASP.NET Core 拡張機能) を選びます。Choose the ASP.NET Core Extensions from the list.
  5. [OK] を選んで法的条項に同意します。Select OK to accept the legal terms.
  6. [拡張機能の追加] ブレードで [OK] を選びます。Select OK on the Add extension blade.
  7. 拡張機能が正常にインストールされると、情報ポップアップ メッセージで通知されます。An informational pop-up message indicates when the extensions are successfully installed.

stdout ログが有効になっていない場合は、次の手順のようにします。If stdout logging isn't enabled, follow these steps:

  1. Azure portal の [開発ツール] 領域で [高度なツール] ブレードを選びます。In the Azure portal, select the Advanced Tools blade in the DEVELOPMENT TOOLS area. [Go→] ボタンを選びます。Select the Go→ button. 新しいブラウザー タブまたはウィンドウで Kudu コンソールが開きます。The Kudu console opens in a new browser tab or window.
  2. ページの上部にあるナビゲーション バーを使って [デバッグ コンソール] を開き、 [CMD] を選びます。Using the navigation bar at the top of the page, open Debug console and select CMD.
  3. パスサイトのフォルダー > wwwrootを開き、下にスクロールして、一覧の下部にあるweb.config ファイルを表示します。Open the folders to the path site > wwwroot and scroll down to reveal the web.config file at the bottom of the list.
  4. web.config ファイルの隣の鉛筆アイコンをクリックします。Click the pencil icon next to the web.config file.
  5. stdoutLogEnabledtrue に設定し、stdoutLogFile パスを \\?\%home%\LogFiles\stdout に変更します。Set stdoutLogEnabled to true and change the stdoutLogFile path to: \\?\%home%\LogFiles\stdout.
  6. [保存] を選んで、更新した web.config ファイルを保存します。Select Save to save the updated web.config file.

続けて診断ログをアクティブにします。Proceed to activate diagnostic logging:

  1. Azure portal で [診断ログ] ブレードを選びます。In the Azure portal, select the Diagnostics logs blade.
  2. [アプリケーション ログ (ファイル システム)] および [詳細なエラー メッセージ][オン] スイッチを選びます。Select the On switch for Application Logging (Filesystem) and Detailed error messages. ブレードの上部にある [保存] ボタンを選びます。Select the Save button at the top of the blade.
  3. 失敗した要求イベントのバッファ処理 (FREB) とも呼ばれる失敗した要求のトレースを含めるには、 [失敗した要求のトレース][オン] スイッチを選びます。To include failed request tracing, also known as Failed Request Event Buffering (FREB) logging, select the On switch for Failed request tracing.
  4. ポータルで [診断ログ] ブレードのすぐ下にある [ログ ストリーム] ブレードを選びます。Select the Log stream blade, which is listed immediately under the Diagnostics logs blade in the portal.
  5. アプリに対して要求します。Make a request to the app.
  6. ログ ストリーム データ内で、エラーの原因が示されます。Within the log stream data, the cause of the error is indicated.

トラブルシューティングが完了したら、stdout ログを無効にしてください。Be sure to disable stdout logging when troubleshooting is complete.

失敗した要求のトレース ログ (FREB ログ) を見るには:To view the failed request tracing logs (FREB logs):

  1. Azure portal で [問題の診断と解決] ブレードに移動します。Navigate to the Diagnose and solve problems blade in the Azure portal.
  2. サイド バーの [SUPPORT TOOLS](サポート ツール) 領域で、 [Failed Request Tracing Logs](失敗した要求のトレース ログ) を選びます。Select Failed Request Tracing Logs from the SUPPORT TOOLS area of the sidebar.

詳しくは、「Azure App Service の Web アプリの診断ログの有効化」トピックの「失敗した要求トレース」セクションおよび「Azure での Web アプリのアプリケーションパフォーマンスに関するよくあるご質問」の「失敗した要求トレースをオンにするにはどうすればよいですか?」をご覧ください。See Failed request traces section of the Enable diagnostics logging for web apps in Azure App Service topic and the Application performance FAQs for Web Apps in Azure: How do I turn on failed request tracing? for more information.

詳しくは、「Azure App Service の Web アプリの診断ログの有効化」をご覧ください。For more information, see Enable diagnostics logging for web apps in Azure App Service.

警告

stdout ログを無効にしないと、アプリまたはサーバーで障害が発生する可能性があります。Failure to disable the stdout log can lead to app or server failure. ログ ファイルのサイズまたは作成されるログ ファイルの数に制限はありません。There's no limit on log file size or the number of log files created.

ASP.NET Core アプリでのルーチン ログの場合は、ログ ファイルのサイズを制限し、ログをローテーションするログ ライブラリを使います。For routine logging in an ASP.NET Core app, use a logging library that limits log file size and rotates logs. 詳しくは、「サードパーティ製のログ プロバイダー」をご覧ください。For more information, see third-party logging providers.

IIS でのトラブルシューティングTroubleshoot on IIS

アプリケーションイベントログ (IIS)Application Event Log (IIS)

アプリケーション イベント ログにアクセスします。Access the Application Event Log:

  1. [スタート] メニューを開き、イベント ビューアーを検索し、イベント ビューアー アプリを選択します。Open the Start menu, search for Event Viewer, and select the Event Viewer app.
  2. イベント ビューアー[Windows ログ] ノードを開きます。In Event Viewer, open the Windows Logs node.
  3. [Application] を選択して、アプリケーション イベント ログを開きます。Select Application to open the Application Event Log.
  4. 失敗したアプリに関連するエラーを検索します。Search for errors associated with the failing app. エラーの [ソース] 列には IIS AspNetCore Module または IIS Express AspNetCore Module の値が表示されます。Errors have a value of IIS AspNetCore Module or IIS Express AspNetCore Module in the Source column.

コマンド プロンプトでアプリを実行するRun the app at a command prompt

多くの起動時エラーでは、アプリケーション イベント ログに役に立つ情報が生成されません。Many startup errors don't produce useful information in the Application Event Log. ホスティング システムのコマンド プロンプトでアプリを実行すると、エラーの原因がわかることがあります。You can find the cause of some errors by running the app at a command prompt on the hosting system.

フレームワークに依存する展開Framework-dependent deployment

アプリがフレームワークに依存する展開の場合:If the app is a framework-dependent deployment:

  1. コマンド プロンプトで展開フォルダーに移動し、dotnet.exe 使用してアプリのアセンブリを実行して、アプリを実行します。At a command prompt, navigate to the deployment folder and run the app by executing the app's assembly with dotnet.exe. コマンド < の dotnet .\<assembly_name>.dllassembly_name> にアプリのアセンブリの名前を指定して実行します。In the following command, substitute the name of the app's assembly for <assembly_name>: dotnet .\<assembly_name>.dll.
  2. エラーを示すアプリからのコンソール出力は、すべてコンソール ウィンドウに書き込まれます。The console output from the app, showing any errors, is written to the console window.
  3. アプリへの要求時にエラーが発生した場合は、Kestrel がリッスンしているホストとポートに要求が送信されます。If the errors occur when making a request to the app, make a request to the host and port where Kestrel listens. 既定のホストと post を使用して http://localhost:5000/ に要求を行います。Using the default host and post, make a request to http://localhost:5000/. アプリが Kestrel のエンドポイント アドレスで正常に応答する場合、問題はホスティングの構成に関連している可能性が高く、アプリ内が原因の可能性は低くなります。If the app responds normally at the Kestrel endpoint address, the problem is more likely related to the hosting configuration and less likely within the app.

自己完結型の展開Self-contained deployment

アプリが自己完結型の展開の場合:If the app is a self-contained deployment:

  1. コマンド プロンプトで、展開フォルダーに移動し、アプリの実行可能ファイルを実行します。At a command prompt, navigate to the deployment folder and run the app's executable. コマンド < の <assembly_name>.exeassembly_name> にアプリのアセンブリの名前を指定して実行します。In the following command, substitute the name of the app's assembly for <assembly_name>: <assembly_name>.exe.
  2. エラーを示すアプリからのコンソール出力は、すべてコンソール ウィンドウに書き込まれます。The console output from the app, showing any errors, is written to the console window.
  3. アプリへの要求時にエラーが発生した場合は、Kestrel がリッスンしているホストとポートに要求が送信されます。If the errors occur when making a request to the app, make a request to the host and port where Kestrel listens. 既定のホストと post を使用して http://localhost:5000/ に要求を行います。Using the default host and post, make a request to http://localhost:5000/. アプリが Kestrel のエンドポイント アドレスで正常に応答する場合、問題はホスティングの構成に関連している可能性が高く、アプリ内が原因の可能性は低くなります。If the app responds normally at the Kestrel endpoint address, the problem is more likely related to the hosting configuration and less likely within the app.

ASP.NET Core モジュールの stdout ログ (IIS)ASP.NET Core Module stdout log (IIS)

stdout ログを有効にして表示するには:To enable and view stdout logs:

  1. ホスティング システム上のサイトの展開フォルダーに移動します。Navigate to the site's deployment folder on the hosting system.
  2. logs フォルダーが存在しない場合は、フォルダーを作成します。If the logs folder isn't present, create the folder. MSBuild で展開フォルダーに logs フォルダーを自動的に作成されるようにする手順については、「ディレクトリ構造」のトピックを参照してください。For instructions on how to enable MSBuild to create the logs folder in the deployment automatically, see the Directory structure topic.
  3. web.config ファイルを編集します。Edit the web.config file. stdoutLogEnabledtrue に設定し、stdoutLogFile のパスを logs フォルダー (たとえば .\logs\stdout) を指すように変更します。Set stdoutLogEnabled to true and change the stdoutLogFile path to point to the logs folder (for example, .\logs\stdout). パスの stdout はログ ファイル名のプレフィックスです。stdout in the path is the log file name prefix. ログ ファイルの作成時には、タイムスタンプ、プロセス ID、およびファイルの拡張子が自動的に追加されます。A timestamp, process id, and file extension are added automatically when the log is created. ファイル名のプレフィックスとして stdout を使用すると、一般的なログ ファイルの名前は stdout_20180205184032_5412.log になります。Using stdout as the file name prefix, a typical log file is named stdout_20180205184032_5412.log.
  4. アプリケーション プールの ID に logs フォルダーへの書き込みアクセス許可があることを確認します。Ensure your application pool's identity has write permissions to the logs folder.
  5. 更新した web.config ファイルを保存します。Save the updated web.config file.
  6. アプリに対して要求します。Make a request to the app.
  7. logs フォルダーに移動します。Navigate to the logs folder. 最新の stdout ログを探して開きます。Find and open the most recent stdout log.
  8. ログのエラーを調べます。Study the log for errors.

トラブルシューティングが完了したら、stdout ログを無効にします。Disable stdout logging when troubleshooting is complete:

  1. web.config ファイルを編集します。Edit the web.config file.
  2. stdoutLogEnabledfalse に設定します。Set stdoutLogEnabled to false.
  3. ファイルを保存します。Save the file.

詳細については、ASP.NET Core モジュール を参照してください。For more information, see ASP.NET Core モジュール.

警告

stdout ログを無効にしないと、アプリまたはサーバーで障害が発生する可能性があります。Failure to disable the stdout log can lead to app or server failure. ログ ファイルのサイズまたは作成されるログ ファイルの数に制限はありません。There's no limit on log file size or the number of log files created.

ASP.NET Core アプリでのルーチン ログの場合は、ログ ファイルのサイズを制限し、ログをローテーションするログ ライブラリを使います。For routine logging in an ASP.NET Core app, use a logging library that limits log file size and rotates logs. 詳しくは、「サードパーティ製のログ プロバイダー」をご覧ください。For more information, see third-party logging providers.

開発者例外ページを有効にするEnable the Developer Exception Page

ASPNETCORE_ENVIRONMENT環境変数を web.config に追加して、開発環境でアプリを実行できます。The ASPNETCORE_ENVIRONMENT environment variable can be added to web.config to run the app in the Development environment. アプリの起動時にホスト ビルダー上で UseEnvironment によって環境がオーバーライドされない限り、環境変数を設定すると、アプリの実行時に開発者例外ページが表示されます。As long as the environment isn't overridden in app startup by UseEnvironment on the host builder, setting the environment variable allows the Developer Exception Page to appear when the app is run.

<aspNetCore processPath="dotnet"
      arguments=".\MyApp.dll"
      stdoutLogEnabled="false"
      stdoutLogFile=".\logs\stdout">
  <environmentVariables>
    <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Development" />
  </environmentVariables>
</aspNetCore>

ASPNETCORE_ENVIRONMENT の環境変数を設定する方法は、インターネットに公開されないステージング サーバーやテスト用サーバーの場合にのみお勧めされます。Setting the environment variable for ASPNETCORE_ENVIRONMENT is only recommended for use on staging and testing servers that aren't exposed to the Internet. トラブルシューティング後は、必ず web.config ファイルからこの環境変数を削除してください。Remove the environment variable from the web.config file after troubleshooting. web.config で環境変数を設定する方法の詳細については、aspNetCore の environmentVariables 子要素を参照してください。For information on setting environment variables in web.config, see environmentVariables child element of aspNetCore.

アプリからデータを取得するObtain data from an app

アプリが要求に応答できる場合は、ターミナル インライン ミドルウェアを使用して、要求、接続、その他のデータをアプリから取得します。If an app is capable of responding to requests, obtain request, connection, and additional data from the app using terminal inline middleware. 詳細およびサンプル コードについては、「ASP.NET Core プロジェクトのトラブルシューティングとデバッグ」を参照してください。For more information and sample code, see ASP.NET Core プロジェクトのトラブルシューティングとデバッグ.

低速またはハング中のアプリ (IIS)Slow or hanging app (IIS)

"クラッシュ ダンプ" とはシステムのメモリのスナップショットであり、アプリのクラッシュ、起動の失敗、遅いアプリの原因を突き止めるのに役立ちます。A crash dump is a snapshot of the system's memory and can help determine the cause of an app crash, startup failure, or slow app.

アプリのクラッシュまたは例外の発生App crashes or encounters an exception

Windows エラー報告 (WER) からダンプを取得して分析します。Obtain and analyze a dump from Windows Error Reporting (WER):

  1. c:\dumps にクラッシュ ダンプ ファイルを保持するフォルダーを作成します。Create a folder to hold crash dump files at c:\dumps. アプリ プールには、そのフォルダーへの書き込みアクセス権が必要です。The app pool must have write access to the folder.

  2. EnableDumps PowerShell スクリプト を実行します。Run the EnableDumps PowerShell script:

  3. クラッシュが発生する条件の下でアプリを実行します。Run the app under the conditions that cause the crash to occur.

  4. クラッシュが発生した後、DisableDumps PowerShell スクリプトを実行します。After the crash has occurred, run the DisableDumps PowerShell script:

アプリがクラッシュし、ダンプの収集が完了したら、アプリを普通に終了してかまいません。After an app crashes and dump collection is complete, the app is allowed to terminate normally. PowerShell スクリプトにより、アプリごとに最大 5 つのダンプを収集する WER が構成されます。The PowerShell script configures WER to collect up to five dumps per app.

警告

クラッシュ ダンプでは、大量のディスク領域 (1 つにつき最大、数ギガバイト) が使用される場合があります。Crash dumps might take up a large amount of disk space (up to several gigabytes each).

アプリが起動時または正常な実行中にハングまたは失敗するApp hangs, fails during startup, or runs normally

アプリがハングした (応答が停止してもクラッシュしない) 場合、起動時に失敗した場合、または正常に実行された場合は、「ユーザーモードのダンプファイル:ダンプを生成する適切なツールを選択する最適なツールを選択する」を参照してください。When an app hangs (stops responding but doesn't crash), fails during startup, or runs normally, see User-Mode Dump Files: Choosing the Best Tool to select an appropriate tool to produce the dump.

ダンプを分析するAnalyze the dump

ダンプはいくつかの方法で分析できます。A dump can be analyzed using several approaches. 詳細については、「Analyzing a User-Mode Dump File」(ユーザー モード ダンプ ファイルの分析) を参照してください。For more information, see Analyzing a User-Mode Dump File.

パッケージ キャッシュをクリアするClear package caches

開発マシンで .NET Core SDK をアップグレードしたり、アプリ内のパッケージ バージョンを変更したりした直後に、機能しているアプリが失敗することがあります。A functioning app may fail immediately after upgrading either the .NET Core SDK on the development machine or changing package versions within the app. 場合によっては、パッケージに統一性がないと、メジャー アップグレード実行時にアプリが破壊されることがあります。In some cases, incoherent packages may break an app when performing major upgrades. これらの問題のほとんどは、次の手順で解決できます。Most of these issues can be fixed by following these instructions:

  1. bin フォルダーと obj フォルダーを削除します。Delete the bin and obj folders.

  2. コマンド シェルから dotnet nuget locals all --clear を実行して、パッケージ キャッシュをクリアします。Clear the package caches by executing dotnet nuget locals all --clear from a command shell.

    パッケージ キャッシュをクリアするには、nuget.exe ツールを使用して nuget locals all -clear コマンドを実行する方法もあります。Clearing package caches can also be accomplished with the nuget.exe tool and executing the command nuget locals all -clear. nuget.exe は、Windows デスクトップ オペレーティング システムにバンドルされているインストールではなく、NuGet Web サイトから別に入手する必要があります。nuget.exe isn't a bundled install with the Windows desktop operating system and must be obtained separately from the NuGet website.

  3. プロジェクトを復元してリビルドします。Restore and rebuild the project.

  4. アプリを再展開する前に、サーバー上の展開フォルダー内のすべてのファイルを削除します。Delete all of the files in the deployment folder on the server prior to redeploying the app.

その他のリソースAdditional resources

Azure のドキュメントAzure documentation

Visual Studio ドキュメントVisual Studio documentation

Visual Studio Code のドキュメントVisual Studio Code documentation