Azure App Service および IIS での ASP.NET Core のトラブルシューティング
作成者: Justin Kotalik
この記事では、アプリの起動時に発生する一般的なエラーに関する情報と、アプリが Azure App Service または IIS にデプロイされるときのエラーを診断する手順を提供します。
アプリ起動時のエラー
一般的な起動時の HTTP 状態コードのシナリオについて説明します。
Azure App Service でのトラブルシューティング
Azure App Service にデプロイされたアプリに関するトラブルシューティングのアドバイスを提供します。
IIS でのトラブルシューティング
IIS にデプロイされているアプリまたは IIS Express でローカルに実行されているアプリに関するトラブルシューティングのアドバイスを提供します。 このガイダンスは、Windows Server と Windows デスクトップの両方の配置に適用されます。
パッケージ キャッシュをクリアする
統一性のないパッケージにより、メジャー アップグレードの実行時またはパッケージ バージョンの変更時に、アプリが中断したときの対処方法について説明します。
その他のリソース
その他のトラブルシューティングのトピックを一覧表示します。
アプリ起動時のエラー
Visual Studio では、ASP.NET Core プロジェクトの既定のサーバーは Kestrel です。 Visual Studio は、IIS Express を使用するように構成することができます。 このトピックのアドバイスを使用すると、IIS Express を使用したローカルでのデバッグ時に発生する "502.5 - 処理エラー" または "500.30 - 開始エラー" を診断できます。
403.14 禁止
アプリの開始に失敗しました。 次のエラーがログに記録されます。
The Web server is configured to not list the contents of this directory.
このエラーが発生するのは、通常、ホスト システム上の配置が壊れている場合です。これには、次のようなシナリオが含まれます。
- アプリがホスト システム上の不適切なフォルダーに配置されています。
- 配置プロセスで、アプリのすべてのファイルとフォルダーを、ホスティング システムの配置フォルダーに移動できませんでした。
- 配置に web.config ファイルがありません。または、web.config ファイルの内容の形式が正しくありません。
次の手順に従います。
- ホスト システム上の配置フォルダーからすべてのファイルとフォルダーを削除します。
- Visual Studio、PowerShell、手動配置など、通常の配置方法を使用して、アプリの "公開" フォルダーの内容をホスティング システムに再配置します。
- web.config ファイルがそのデプロイに存在し、その内容が正しいことを確認します。
- Azure App Service でホストする場合は、アプリが
D:\home\site\wwwrootフォルダーにデプロイされていることを確認します。 - アプリが IIS によってホストされている場合は、アプリが IIS マネージャーの [基本設定] に表示されている IIS の物理パスに配置されていることを確認します。
- ホスティング システムの配置をプロジェクトの "公開" フォルダーの内容と比較して、アプリのすべてのファイルとフォルダーが配置されていることを確認します。
公開された ASP.NET Core アプリのレイアウトの詳細については、「ASP.NET Core のディレクトリ構造」を参照してください。 web.config ファイルの詳細については、IIS の ASP.NET Core モジュール (ANCM) に関するページを参照してください。
500 内部サーバー エラー
アプリは起動しますが、エラーのためにサーバーは要求を実行できません。
このエラーは、起動時または応答の作成中に、アプリのコード内で発生します。 応答にコンテンツが含まれていないか、またはブラウザーに "500 内部サーバー エラー" という応答が表示される可能性があります。 通常、アプリケーション イベント ログではアプリが正常に起動したことが示されます。 サーバーから見るとそれは正しいことです。 アプリは起動しましたが、有効な応答を生成できません。 問題を解決するには、サーバー上のコマンド プロンプトでアプリを実行するか、ASP.NET Core モジュールの stdout ログを有効にします。
このエラーは、.NET Core ホスティング バンドルがインストールされていないか、破損している場合にも発生する可能性があります。 .NET Core ホスティング バンドル (IIS 用) または Visual Studio (IIS Express 用) をインストールするか、インストールを修復すると、問題が解決する場合があります。
500.0 インプロセス ハンドラーの読み込みエラー
ワーカー プロセスが失敗します。 アプリは起動しません。
ASP.NET Core モジュール コンポーネントの読み込み中に不明なエラーが発生しました。 次のいずれかのアクションを実行します。
- Microsoft サポートに問い合わせます ( [開発者ツール] 、 [ASP.NET Core] の順に選択します)。
- Stack Overflow について質問します。
- GitHub リポジトリで問題を報告します。
500.30 インプロセス起動エラー
ワーカー プロセスが失敗します。 アプリは起動しません。
ASP.NET Core モジュールは .NET Core CLR の開始をインプロセスで試みますが、開始に失敗します。 プロセス起動時のエラーの原因は、通常、アプリケーション イベント ログと ASP.NET Core モジュールの stdout ログのエントリから判断できます。
一般的なエラー条件:
- 存在しないバージョンの ASP.NET Core 共有フレームワークが対象にされていて、アプリが正しく構成されていません。 対象のコンピューターにどのバージョンの ASP.NET Core 共有フレームワークがインストールされているかを確認します。
- Azure Key Vault を使用している場合、Key Vault へのアクセス許可がありません。 対象の Key Vault のアクセス ポリシーを確認して、正しいアクセス許可が付与されていることを確実にします。
500.31 ANCM Failed to Find Native Dependencies (500.31 ANCM ネイティブの依存関係を見つけられませんでした)
ワーカー プロセスが失敗します。 アプリは起動しません。
ASP.NET Core モジュールで .NET Core ランタイムの開始がインプロセスで試行されますが、開始に失敗します。 このスタートアップ エラーの最も一般的な原因は、Microsoft.NETCore.App または Microsoft.AspNetCore.App ランタイムがインストールされていない場合です。 アプリが ASP.NET Core 3.0 をターゲットとして展開されていて、そのバージョンがコンピューターに存在しない場合、このエラーが発生します。 エラー メッセージの例は次のとおりです。
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 のバージョンとアプリに必要なバージョンが一覧表示されます。 このエラーを修正するには、次のいずれかを実行します。
- 適切なバージョンの .NET Core をマシンにインストールします。
- マシンに存在する .NET Core のバージョンをターゲットにするようにアプリを変更します。
- アプリを自己完結型の展開として発行します。
開発環境で実行している場合 (ASPNETCORE_ENVIRONMENT 環境変数が Development に設定されている場合)、特定のエラーが HTTP 応答に書き込まれます。 プロセスのスタートアップ エラーの原因は、アプリケーション イベント ログでも見つかります。
500.32 ANCM Failed to Load dll (500.32 ANCM DLL を読み込めませんでした)
ワーカー プロセスが失敗します。 アプリは起動しません。
このエラーの最も一般的な原因は、アプリが互換性のないプロセッサ アーキテクチャ用に発行されていることです。 ワーカー プロセスが 32 ビットアプリとして実行されていて、そのアプリが 64 ビットをターゲットとして発行されている場合、このエラーが発生します。
このエラーを修正するには、次のいずれかを実行します。
- ワーカー プロセスと同じプロセッサ アーキテクチャ用にアプリを再発行します。
- アプリをフレームワークに依存する展開として発行します。
500.33 ANCM Request Handler Load Failure (500.33 ANCM 要求ハンドラーの読み込みエラー)
ワーカー プロセスが失敗します。 アプリは起動しません。
アプリは Microsoft.AspNetCore.App フレームワークを参照していませんでした。 ASP.NET Core モジュールでホストできるのは、Microsoft.AspNetCore.App フレームワークをターゲットとしているアプリのみです。
このエラーを修正するには、アプリが Microsoft.AspNetCore.App フレームワークをターゲットにしていることを確認します。 アプリがターゲットとしているフレームワークを確認するには、.runtimeconfig.json を確認します。
500.34 ANCM Mixed Hosting Models Not Supported (500.34 ANCM 混在ホスティング モデルはサポートされません)
ワーカー プロセスでは、インプロセス アプリとアウト プロセス アプリの両方を同じプロセスで実行できません。
このエラーを修正するには、別の IIS アプリケーション プールでアプリを実行します。
500.35 ANCM Multiple In-Process Applications in same Process (500.35 ANCM 同一プロセス内の複数のインプロセス アプリケーション)
ワーカー プロセスによって、同じプロセスで複数のインプロセス アプリを実行することはできません。
このエラーを修正するには、別の IIS アプリケーション プールでアプリを実行します。
500.36 ANCM Out-Of-Process Handler Load Failure (500.36 ANCM アウト プロセス ハンドラーの読み込みエラー)
アウト プロセス要求ハンドラーの aspnetcorev2_outofprocess.dll が aspnetcorev2.dll ファイルの次にありません。 これは、ASP.NET Core モジュールのインストールが破損していることを示しています。
このエラーを修正するには、.NET Core Hosting Bundle (IIS 用) または Visual Studio (IIS Express 用) のインストールを修復します。
500.37 ANCM Failed to Start Within Startup Time Limit (500.37 ANCM スタートアップ時間の制限内に起動できませんでした)
指定されたスタートアップ時間の制限内に ANCM が起動に失敗しました。 既定では、タイムアウトは 120 秒です。
このエラーは、同じマシン上で多数のアプリを起動したときに発生する可能性があります。 スタートアップ中のサーバー上の CPU/メモリ使用量の急上昇を確認します。 必要に応じて、複数のアプリのスタートアップ プロセスをずらします。
500.38 ANCM アプリケーション DLL が見つかりません
ANCM は、実行可能ファイルの横にあるアプリケーション DLL を見つけることができませんでした。
このエラーは、インプロセス ホスティング モデルを使用して単一ファイルの実行可能ファイルとしてパッケージ化されたアプリをホストするときに発生します。 インプロセス モデルでは、ANCM によって既存の IIS プロセスに .NET Core アプリが読み込まれることが必要です。 このシナリオは、単一ファイル展開モデルではサポートされていません。 このエラーを修正するには、アプリのプロジェクト ファイルで、次のうち 1 つを使用します。
PublishSingleFileMSBuild プロパティをfalseに設定して、単一ファイルの公開を無効にします。AspNetCoreHostingModelMSBuild プロパティをOutOfProcessに設定して、アウトプロセス ホスティング モデルに切り替えます。
502.5 処理エラー
ワーカー プロセスが失敗します。 アプリは起動しません。
ASP.NET Core モジュールはワーカー プロセスの開始を試みますが、開始に失敗します。 プロセス起動時のエラーの原因は、通常、アプリケーション イベント ログと ASP.NET Core モジュールの stdout ログのエントリから判断できます。
一般的なエラー条件は、存在しないバージョンの ASP.NET Core 共有フレームワークが対象にされていて、アプリが正しく構成されていないことです。 対象のコンピューターにどのバージョンの ASP.NET Core 共有フレームワークがインストールされているかを確認します。 共有フレームワークは、コンピューター上にインストールされたアセンブリ ( .dll ファイル) のセットであり、Microsoft.AspNetCore.App などのメタパッケージによって参照されます。 メタパッケージの参照には、必要な最低限のバージョンを指定できます。 詳しくは、共有フレームワークに関するページをご覧ください。
正しく構成されていないホスティングやアプリが原因でワーカー プロセスが失敗する場合、"502.5 処理エラー" のエラー ページが返されます。
アプリケーションの起動に失敗しました (ErrorCode '0x800700c1')
EventID: 1010
Source: IIS AspNetCore Module V2
Failed to start application '/LM/W3SVC/6/ROOT/', ErrorCode '0x800700c1'.
アプリのアセンブリ ( .dll) を読み込めなかったため、アプリの起動に失敗しました。
このエラーは、公開されたアプリと w3wp/iisexpress プロセスの間でビットの不一致がある場合に発生します。
アプリ プールの 32 ビット設定が正しいことを確認してください。
- IIS マネージャーの [アプリケーション プール] でそのアプリ プールを選択します。
- [アクション] パネルの [アプリケーション プールの編集] で [詳細設定] を選択します。
- [32 ビット アプリケーションの有効化] を設定します。
- 32 ビット (x86) アプリを展開する場合は、この値を
Trueに設定します。 - 64 ビット (x64) アプリを展開する場合は、この値を
Falseに設定します。
- 32 ビット (x86) アプリを展開する場合は、この値を
プロジェクト ファイルの <Platform> MSBuild プロパティと公開されたアプリのビット数との間で競合が発生していないことを確認します。
アプリケーションの起動に失敗しました (ErrorCode '0x800701b1')
EventID: 1010
Source: IIS AspNetCore Module V2
Failed to start application '/LM/W3SVC/3/ROOT', ErrorCode '0x800701b1'.
Windows サービスの読み込みに失敗したため、アプリの起動に失敗しました。
有効にする必要がある一般的なサービスの 1 つは、"null 値" サービスです。
次のコマンドは null Windows サービスを有効にします。
sc.exe start null
接続のリセット
ヘッダー送信後にエラーが発生した場合、サーバーが 500 内部サーバー エラーを送信するには遅すぎます。 このような状況は、応答に対する複雑なオブジェクトのシリアル化中にエラーが起きたときによく発生します。 この種のエラーは、クライアントでは "接続リセット" エラーとして表示されます。 この種のエラーのトラブルシューティングには、アプリケーション ログが役に立つことがあります。
既定の起動制限
ASP.NET Core モジュールの startupTimeLimit は、既定では 120 秒に構成されます。 既定値のままにした場合、モジュールで処理エラーが記録されるまでに、アプリは最大で 2 分を起動にかけることができます。 モジュールの構成の詳細については、「AspNetCore 要素の属性」を参照してください。
Azure App Service でのトラブルシューティング
重要
Azure App Service と ASP.NET Core のプレビュー リリース
ASP.NET Core のプレビュー リリースは、既定では Azure App Service に展開されません。 ASP.NET Core プレビュー リリースを使用するアプリをホストするには、「Azure App Service に ASP.NET Core プレビュー リリースを展開する」を参照してください。
Azure App Services ログ ストリーム
Azure App Services ログは、発生したログ情報をストリーミングします。 ストリーミング ログを表示するには、次のようにします。
- Azure portal の [App Services] でアプリを開きます。
- 左側のペインで、[監視]>[App Service ログ] に移動します。
- [Web サーバーのログ記録] の [ファイル システム] を選択します。 必要に応じて、[アプリケーションのログ記録] を有効にします。
- 左側のペインで、[監視]>[ログ ストリーム] に移動し、[アプリケーション ログ] または [Web サーバー ログ] を選択します。
次の画像は、アプリケーション ログの出力を示しています。
ストリーミング ログにはある程度の待機時間があり、すぐには表示されない場合があります。
アプリケーション イベント ログ (Azure App Service)
アプリケーション イベント ログにアクセスするには、Azure portal の [問題の診断と解決] ブレードを使います。
- Azure portal の [App Services] でアプリを開きます。
- [問題の診断と解決] を選択します。
- [診断ツール] という見出しを選択します。
- [サポート ツール] で [アプリケーション イベント] ボタンを選択します。
- [Source](ソース) 列で、IIS AspNetCoreModule または IIS AspNetCoreModule V2 によって提供された最新のエラーを調べます。
[問題の診断と解決] ブレードを使う代わりに、Kudu を使ってアプリケーション イベント ログ ファイルを直接調べることもできます。
- [開発ツール] 領域で [高度なツール] を開きます。 [Go→] ボタンを選択します。 新しいブラウザー タブまたはウィンドウで Kudu コンソールが開きます。
- ページの上部にあるナビゲーション バーを使って [デバッグ コンソール] を開き、 [CMD] を選びます。
- LogFiles フォルダーを開きます。
eventlog.xmlファイルの横にある鉛筆アイコンを選択します。- ログを調べます。 ログの末尾までスクロールし、最新のイベントを確認します。
Kudu コンソールでアプリを実行します。
多くの起動時エラーでは、アプリケーション イベント ログに役に立つ情報が生成されません。 Kudu のリモート実行コンソールでアプリを実行すると、エラーを検出することができます。
- [開発ツール] 領域で [高度なツール] を開きます。 [Go→] ボタンを選択します。 新しいブラウザー タブまたはウィンドウで Kudu コンソールが開きます。
- ページの上部にあるナビゲーション バーを使って [デバッグ コンソール] を開き、 [CMD] を選びます。
32 ビット (x86) アプリをテストする
現在のリリース
cd d:\home\site\wwwroot- アプリを実行します:
アプリがフレームワークに依存する展開の場合:
dotnet .\{ASSEMBLY NAME}.dllアプリが自己完結型の展開の場合:
{ASSEMBLY NAME}.exe
エラーを示すアプリからのコンソール出力はすべて、Kudu コンソールにパイプされます。
プレビュー リリース上で実行されているフレームワークに依存するデプロイ
"ASP.NET Core {バージョン} (x86) ランタイムのサイト拡張機能をインストールする必要があります。 "
cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x32({X.Y}はランタイム バージョンです)- アプリを実行します:
dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll
エラーを示すアプリからのコンソール出力はすべて、Kudu コンソールにパイプされます。
64 ビット (x64) アプリをテストする
現在のリリース
- アプリが 64 ビット (x64) のフレームワークに依存する展開の場合:
cd D:\Program Files\dotnet- アプリを実行します:
dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll
- アプリが自己完結型の展開の場合:
cd D:\home\site\wwwroot- アプリを実行します:
{ASSEMBLY NAME}.exe
エラーを示すアプリからのコンソール出力はすべて、Kudu コンソールにパイプされます。
プレビュー リリース上で実行されているフレームワークに依存するデプロイ
"ASP.NET Core {バージョン} (x64) ランタイムのサイト拡張機能をインストールする必要があります。 "
cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x64({X.Y}はランタイム バージョンです)- アプリを実行します:
dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll
エラーを示すアプリからのコンソール出力はすべて、Kudu コンソールにパイプされます。
ASP.NET Core モジュールの stdout ログ (Azure App Service)
警告
stdout ログを無効にしないと、アプリまたはサーバーで障害が発生する可能性があります。 ログ ファイルのサイズまたは作成されるログ ファイルの数に制限はありません。 stdout ログは、アプリ起動時の問題のトラブルシューティングにのみ使ってください。
起動後の ASP.NET Core アプリでの一般的なログの場合は、ログ ファイルのサイズを制限し、ログをローテーションするログ ライブラリを使います。 詳細については、「サードパーティ製のログ プロバイダー」を参照してください。
ASP.NET Core モジュールの stdout には、アプリケーション イベント ログでは見つからない有用なエラー メッセージが記録されることがよくあります。 stdout ログを有効にして表示するには:
- Azure portal で Web アプリに移動します。
- [App Service] ブレードで、検索ボックスに「kudu」と入力します。
- [高度なツール]>[Go] の順に選択します。
- [デバッグ コンソール] > [CMD] の順に選択します。
- site/wwwroot に移動します
- 鉛筆アイコンを選択し、web.config ファイルを編集します。
<aspNetCore />要素でstdoutLogEnabled="true"を設定し、 [保存] を選択します。
トラブルシューティングが完了したら、stdoutLogEnabled="false" を設定して stdout ログを無効にします。
詳細については、IIS の ASP.NET Core モジュール (ANCM) に関するページを参照してください。
ASP.NET Core モジュールのデバッグ ログ (Azure App Service)
ASP.NET Core モジュール デバッグ ログでは、ASP.NET Core モジュールのさらに詳しいログが提供されます。 stdout ログを有効にして表示するには:
- 強化された診断ログを有効にするには、次のいずれかを実行します。
- 「強化された診断ログ」の指示に従い、強化された診断ログをアプリに対して設定します。 アプリを再デプロイします。
- Kudu コンソールを利用し、「
<handlerSettings>強化された診断ログ」にある をライブ アプリの web.config ファイルに追加します。- [開発ツール] 領域で [高度なツール] を開きます。 [Go→] ボタンを選択します。 新しいブラウザー タブまたはウィンドウで Kudu コンソールが開きます。
- ページの上部にあるナビゲーション バーを使って [デバッグ コンソール] を開き、 [CMD] を選びます。
- パス site>wwwroot へのフォルダーを開きます。 鉛筆アイコンを選択し、web.config ファイルを編集します。 「強化された診断ログ」にある
<handlerSettings>セクションを追加します。 [保存] ボタンを選択します。
- [開発ツール] 領域で [高度なツール] を開きます。 [Go→] ボタンを選択します。 新しいブラウザー タブまたはウィンドウで Kudu コンソールが開きます。
- ページの上部にあるナビゲーション バーを使って [デバッグ コンソール] を開き、 [CMD] を選びます。
- パス site>wwwroot へのフォルダーを開きます。 aspnetcore-debug.log ファイルにパスを指定しなかった場合、ファイルが一覧に表示されます。 パスを指定した場合、ログ ファイルの場所に移動します。
- ファイル名の隣にある鉛筆アイコンでログ ファイルを開きます。
トラブルシューティングが完了したら、debug ログを無効にします。
強化されたデバッグ ログを無効にするには、次のいずれかを実行します。
- ローカルの web.config ファイルから
<handlerSettings>を削除し、アプリを再デプロイします。 - Kudu コンソールを使用して web.config ファイルを編集し、
<handlerSettings>セクションを削除します。 ファイルを保存します。
詳細については、ASP.NET Core モジュールを使用したログの作成とリダイレクトに関する記事を参照してください。
警告
debug ログを無効にしないと、アプリまたはサーバーで障害が発生する可能性があります。 ログ ファイルのサイズに制限はありません。 debug ログは、アプリ起動時の問題のトラブルシューティングにのみ使ってください。
起動後の ASP.NET Core アプリでの一般的なログの場合は、ログ ファイルのサイズを制限し、ログをローテーションするログ ライブラリを使います。 詳細については、「サードパーティ製のログ プロバイダー」を参照してください。
遅いアプリまたはハングしているアプリ (Azure App Service)
要求に対してアプリの応答が遅いとき、またはアプリがハングするときは、「Azure App Service での Web アプリのパフォーマンス低下に関する問題のトラブルシューティング」をご覧ください。
監視ブレード
監視ブレードでは、このトピックでこれまでに説明した方法に代わるトラブルシューティング エクスペリエンスが提供されます。 これらのブレードは、500 番台のエラーの診断に使用できます。
ASP.NET Core 拡張機能がインストールされていることを確認してください。 拡張機能がインストールされていない場合は、手動でインストールします。
- [開発ツール] ブレード セクションで、 [拡張機能] ブレードを選びます。
- [ASP.NET Core Extensions](ASP.NET Core 拡張機能) が一覧に表示されます。
- 拡張機能がインストールされていない場合は、 [追加] ボタンを選びます。
- 一覧から [ASP.NET Core Extensions](ASP.NET Core 拡張機能) を選びます。
- [OK] を選んで法的条項に同意します。
- [拡張機能の追加] ブレードで [OK] を選びます。
- 拡張機能が正常にインストールされると、情報ポップアップ メッセージで通知されます。
stdout ログが有効になっていない場合は、次の手順のようにします。
- Azure portal の [開発ツール] 領域で [高度なツール] ブレードを選びます。 [Go→] ボタンを選択します。 新しいブラウザー タブまたはウィンドウで Kudu コンソールが開きます。
- ページの上部にあるナビゲーション バーを使って [デバッグ コンソール] を開き、 [CMD] を選びます。
- パス site>wwwroot へのフォルダーを開き、下にスクロールして、一覧の最後にある web.config ファイルを表示します。
- web.config ファイルの隣の鉛筆アイコンをクリックします。
- stdoutLogEnabled を
trueに設定し、stdoutLogFile パスを\\?\%home%\LogFiles\stdoutに変更します。 - [保存] を選んで、更新した web.config ファイルを保存します。
続けて診断ログをアクティブにします。
- Azure portal で [診断ログ] ブレードを選びます。
- [アプリケーション ログ (ファイル システム)] および [詳細なエラー メッセージ] の [オン] スイッチを選びます。 ブレードの上部にある [保存] ボタンを選びます。
- 失敗した要求イベントのバッファ処理 (FREB) とも呼ばれる失敗した要求のトレースを含めるには、 [失敗した要求のトレース] で [オン] スイッチを選びます。
- ポータルで [診断ログ] ブレードのすぐ下にある [ログ ストリーム] ブレードを選びます。
- アプリに対して要求します。
- ログ ストリーム データ内で、エラーの原因が示されます。
トラブルシューティングが完了したら、stdout ログを無効にしてください。
失敗した要求のトレース ログ (FREB ログ) を見るには:
- Azure portal で [問題の診断と解決] ブレードに移動します。
- サイド バーの [SUPPORT TOOLS](サポート ツール) 領域で、 [Failed Request Tracing Logs](失敗した要求のトレース ログ) を選びます。
詳しくは、「Azure App Service の Web アプリの診断ログの有効化」トピックの「失敗した要求トレース」セクションおよび「Azure での Web アプリのアプリケーション パフォーマンスに関するよくあるご質問」の「失敗した要求トレースをオンにするにはどうすればよいですか?」をご覧ください。
詳しくは、「Azure App Service の Web アプリの診断ログの有効化」をご覧ください。
警告
stdout ログを無効にしないと、アプリまたはサーバーで障害が発生する可能性があります。 ログ ファイルのサイズまたは作成されるログ ファイルの数に制限はありません。
ASP.NET Core アプリでのルーチン ログの場合は、ログ ファイルのサイズを制限し、ログをローテーションするログ ライブラリを使います。 詳細については、「サードパーティ製のログ プロバイダー」を参照してください。
IIS でのトラブルシューティング
アプリケーション イベント ログ (IIS)
アプリケーション イベント ログにアクセスします。
- [スタート] メニューを開き、イベント ビューアーを検索し、イベント ビューアー アプリを選択します。
- イベント ビューアーで [Windows ログ] ノードを開きます。
- [Application] を選択して、アプリケーション イベント ログを開きます。
- 失敗したアプリに関連するエラーを検索します。 エラーの [ソース] 列には IIS AspNetCore Module または IIS Express AspNetCore Module の値が表示されます。
コマンド プロンプトでアプリを実行する
多くの起動時エラーでは、アプリケーション イベント ログに役に立つ情報が生成されません。 ホスティング システムのコマンド プロンプトでアプリを実行すると、エラーの原因がわかることがあります。
フレームワークに依存する展開
アプリがフレームワークに依存する展開の場合:
- コマンド プロンプトで展開フォルダーに移動し、dotnet.exe 使用してアプリのアセンブリを実行して、アプリを実行します。
dotnet .\<assembly_name>.dllコマンドの <assembly_name> を、アプリのアセンブリの名前に置き換えます。 - エラーを示すアプリからのコンソール出力は、すべてコンソール ウィンドウに書き込まれます。
- アプリへの要求時にエラーが発生した場合は、Kestrel がリッスンしているホストとポートに要求が送信されます。 既定のホストと post を使用して
http://localhost:5000/に要求を行います。 アプリが Kestrel のエンドポイント アドレスで正常に応答する場合、問題はホスティングの構成に関連している可能性が高く、アプリ内が原因の可能性は低くなります。
自己完結型の展開
アプリが自己完結型の展開の場合:
- コマンド プロンプトで、展開フォルダーに移動し、アプリの実行可能ファイルを実行します。
<assembly_name>.exeコマンドの <assembly_name> を、アプリのアセンブリの名前に置き換えます。 - エラーを示すアプリからのコンソール出力は、すべてコンソール ウィンドウに書き込まれます。
- アプリへの要求時にエラーが発生した場合は、Kestrel がリッスンしているホストとポートに要求が送信されます。 既定のホストと post を使用して
http://localhost:5000/に要求を行います。 アプリが Kestrel のエンドポイント アドレスで正常に応答する場合、問題はホスティングの構成に関連している可能性が高く、アプリ内が原因の可能性は低くなります。
ASP.NET Core モジュールの stdout ログ (IIS)
stdout ログを有効にして表示するには:
- ホスティング システム上のサイトの展開フォルダーに移動します。
- logs フォルダーが存在しない場合は、フォルダーを作成します。 MSBuild で展開フォルダーに logs フォルダーを自動的に作成されるようにする手順については、「ディレクトリ構造」のトピックを参照してください。
- web.config ファイルを編集します。 stdoutLogEnabled を
trueに設定し、stdoutLogFile のパスを logs フォルダー (たとえば.\logs\stdout) を指すように変更します。 パスのstdoutはログ ファイル名のプレフィックスです。 ログ ファイルの作成時には、タイムスタンプ、プロセス ID、およびファイルの拡張子が自動的に追加されます。 ファイル名のプレフィックスとしてstdoutを使用すると、一般的なログ ファイルの名前は stdout_20180205184032_5412.log になります。 - アプリケーション プールの ID に logs フォルダーへの書き込みアクセス許可があることを確認します。
- 更新した web.config ファイルを保存します。
- アプリに対して要求します。
- logs フォルダーに移動します。 最新の stdout ログを探して開きます。
- ログのエラーを調べます。
トラブルシューティングが完了したら、stdout ログを無効にします。
- web.config ファイルを編集します。
- stdoutLogEnabled を
falseに設定します。 - ファイルを保存します。
詳細については、IIS の ASP.NET Core モジュール (ANCM) に関するページを参照してください。
警告
stdout ログを無効にしないと、アプリまたはサーバーで障害が発生する可能性があります。 ログ ファイルのサイズまたは作成されるログ ファイルの数に制限はありません。
ASP.NET Core アプリでのルーチン ログの場合は、ログ ファイルのサイズを制限し、ログをローテーションするログ ライブラリを使います。 詳細については、「サードパーティ製のログ プロバイダー」を参照してください。
ASP.NET Core モジュールのデバッグ ログ (IIS)
ASP.NET Core モジュールのデバッグ ログを有効にするには、次のハンドラー設定をアプリの web.config ファイルに追加します。
<aspNetCore ...>
<handlerSettings>
<handlerSetting name="debugLevel" value="file" />
<handlerSetting name="debugFile" value="c:\temp\ancm.log" />
</handlerSettings>
</aspNetCore>
ログに指定されたパスが存在することと、アプリ プールの ID にその場所への書き込みアクセス許可があることを確認します。
詳細については、ASP.NET Core モジュールを使用したログの作成とリダイレクトに関する記事を参照してください。
開発者例外ページを有効にする
開発環境でアプリを実行するには、ASPNETCORE_ENVIRONMENT環境変数を web.config に追加することができます。 アプリの起動時にホスト ビルダー上で UseEnvironment によって環境がオーバーライドされない限り、環境変数を設定すると、アプリの実行時に開発者例外ページが表示されます。
<aspNetCore processPath="dotnet"
arguments=".\MyApp.dll"
stdoutLogEnabled="false"
stdoutLogFile=".\logs\stdout"
hostingModel="InProcess">
<environmentVariables>
<environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Development" />
</environmentVariables>
</aspNetCore>
ASPNETCORE_ENVIRONMENT の環境変数を設定する方法は、インターネットに公開されないステージング サーバーやテスト用サーバーの場合にのみお勧めされます。 トラブルシューティング後は、必ず web.config ファイルからこの環境変数を削除してください。 web.config で環境変数を設定する方法の詳細については、aspNetCore の environmentVariables 子要素を参照してください。
アプリからデータを取得する
アプリが要求に応答できる場合は、ターミナル インライン ミドルウェアを使用して、要求、接続、その他のデータをアプリから取得します。 詳細とサンプル コードについては、「ASP.NET Core プロジェクトのトラブルシューティングとデバッグ」を参照してください。
遅いアプリまたはハングしているアプリ (IIS)
"クラッシュ ダンプ" とはシステムのメモリのスナップショットであり、アプリのクラッシュ、起動の失敗、遅いアプリの原因を突き止めるのに役立ちます。
アプリのクラッシュまたは例外の発生
Windows エラー報告 (WER) からダンプを取得して分析します。
c:\dumpsにクラッシュ ダンプ ファイルを保持するフォルダーを作成します。 アプリ プールには、そのフォルダーへの書き込みアクセス権が必要です。EnableDumps PowerShell スクリプト を実行します。
アプリでインプロセス ホスティング モデルが使われている場合は、w3wp.exe に対するスクリプトを実行します。
.\EnableDumps w3wp.exe c:\dumpsアプリでアウト プロセス ホスティング モデルが使われている場合は、dotnet.exe に対するスクリプトを実行します。
.\EnableDumps dotnet.exe c:\dumps
クラッシュが発生する条件の下でアプリを実行します。
クラッシュが発生した後、DisableDumps PowerShell スクリプトを実行します。
アプリでインプロセス ホスティング モデルが使われている場合は、w3wp.exe に対するスクリプトを実行します。
.\DisableDumps w3wp.exeアプリでアウト プロセス ホスティング モデルが使われている場合は、dotnet.exe に対するスクリプトを実行します。
.\DisableDumps dotnet.exe
アプリがクラッシュし、ダンプの収集が完了したら、アプリを普通に終了してかまいません。 PowerShell スクリプトにより、アプリごとに最大 5 つのダンプを収集する WER が構成されます。
警告
クラッシュ ダンプでは、大量のディスク領域 (1 つにつき最大、数ギガバイト) が使用される場合があります。
アプリが起動時または正常な実行中にハングまたは失敗する
アプリが起動時または正常な実行中に "ハング" (応答を停止するがクラッシュしない) または失敗するときは、「User-Mode Dump Files:Choosing the Best Tool」(ユーザー モード ダンプ ファイル: 最適なツールの選択) を参照し、適切なツールを選択してダンプを生成します。
ダンプを分析する
ダンプはいくつかの方法で分析できます。 詳細については、「Analyzing a User-Mode Dump File」(ユーザー モード ダンプ ファイルの分析) を参照してください。
パッケージ キャッシュをクリアする
開発マシンで .NET Core SDK をアップグレードしたり、アプリ内のパッケージ バージョンを変更したりした直後に、機能しているアプリが失敗することがあります。 場合によっては、パッケージに統一性がないと、メジャー アップグレード実行時にアプリが破壊されることがあります。 これらの問題のほとんどは、次の手順で解決できます。
bin フォルダーと obj フォルダーを削除します。
コマンド シェルから dotnet nuget locals all --clear を実行して、パッケージ キャッシュをクリアします。
パッケージ キャッシュをクリアするには、nuget.exe ツールを使用して
nuget locals all -clearコマンドを実行する方法もあります。 nuget.exe は、Windows デスクトップ オペレーティング システムにバンドルされているインストールではなく、NuGet Web サイトから別に入手する必要があります。プロジェクトを復元してリビルドします。
アプリを再展開する前に、サーバー上の展開フォルダー内のすべてのファイルを削除します。
状態コードとログ エントリを収集する
IIS で実行されている ASP.NET Core アプリでエラーが発生した場合は、情報を収集し問題の診断に役立てます。 次の情報は、トラブルシューティングに役立ちます。次の情報を収集します。
- ブラウザーの動作 (状態コードやエラー メッセージなど)。
- アプリケーション イベント ログのエントリ
- Azure App Service: 「Azure App Service および IIS での ASP.NET Core のトラブルシューティング」を参照してください。
- IIS
- [Windows] メニューで [スタート] を選択し、「Event Viewer」と入力し、Enter を押します。
- イベント ビューアーが開いたら、サイドバーで [Windows ログ]、[アプリケーション] の順に展開します。
- ASP.NET Core モジュールの stdout ログ エントリと debug ログ エントリ
- Azure App Service: 「Azure App Service および IIS での ASP.NET Core のトラブルシューティング」を参照してください。
- IIS:ASP.NET Core モジュール トピックの「ログの作成とリダイレクト」と「強化された診断ログ」のセクションの指示に従います。
エラー情報を次の一般的なエラーと比較します。 一致が見つかった場合は、トラブルシューティングのアドバイスに従います。
このトピックではすべてのエラーを網羅しているわけではありません。 ここに記載されていないエラーに遭遇した場合、このトピックの一番下にある [コンテンツ フィードバック] ボタンで新しい問題を登録してください。その際、エラーを再現する方法を詳しく教えてください。
重要
Azure App Service と ASP.NET Core のプレビュー リリース
ASP.NET Core のプレビュー リリースは、既定では Azure App Service に展開されません。 ASP.NET Core プレビュー リリースを使用するアプリをホストするには、「Azure App Service に ASP.NET Core プレビュー リリースを展開する」を参照してください。
OS のアップグレードによって 32 ビット ASP.NET Core モジュールが削除された
アプリケーション ログ: モジュール DLL C:\WINDOWS\system32\inetsrv\aspnetcore.dll を読み込めませんでした。 このデータはエラーです。
トラブルシューティング:
C:\Windows\SysWOW64\inetsrv ディレクトリにある OS ファイルでないファイルは、OS アップグレード時に保持されません。 OS アップグレードより前に ASP.NET Core モジュールをインストールしていた場合、OS アップグレード後に 32 ビット モードでアプリ プールを実行しようとすると、この問題が発生します。 OS アップグレード後に ASP.NET Core モジュールを修復してください。 「.NET Core ホスティング バンドルのインストール」をご覧ください。 インストーラーを実行するときに [修復] を選択します。
サイト拡張機能の不足、32 ビット (x86) および 64 ビット (x64) サイト拡張機能がインストールされている、または間違ったプロセス ビットが設定されている
"Azure App Services でホストしているアプリに適用されます。 "
ブラウザー: HTTP エラー 500.0 - ANCM インプロセス ハンドラーの読み込みエラー
アプリケーション ログ: hostfxr を呼び出し、インプロセス要求ハンドラーを見つけようとすると、ネイティブの依存関係が見つからず、失敗しました。 インプロセス要求ハンドラーが見つかりませんでした。 hostfxr の呼び出し時にキャプチャされた出力:互換性のあるフレームワーク バージョンが見つかりませんでした。 指定したフレームワーク 'Microsoft.AspNetCore.App'、バージョン '{VERSION}-preview-*' が見つかりませんでした。 アプリケーション '/LM/W3SVC/1416782824/ROOT' を起動できませんでした、エラー コード '0x8000ffff'。
ASP.NET Core モジュールの stdout ログ: 互換性のあるフレームワーク バージョンが見つかりませんでした。 指定したフレームワーク 'Microsoft.AspNetCore.App'、バージョン '{VERSION}-preview-*' が見つかりませんでした。
ASP.NET Core モジュール デバッグ ログ: hostfxr を呼び出し、インプロセス要求ハンドラーを見つけようとすると、ネイティブの依存関係が見つからず、失敗しました。 これが意味するところは、ほとんどの場合、アプリが正しく設定されていないということです。アプリケーションの対象であり、コンピューターにインストールされている Microsoft.NetCore.App と Microsoft.AspNetCore.App のバージョンを確認してください。 HRESULT が失敗し、次が返されました:0x8000ffff。 インプロセス要求ハンドラーが見つかりませんでした。 互換性のあるフレームワーク バージョンが見つかりませんでした。 指定したフレームワーク 'Microsoft.AspNetCore.App'、バージョン '{VERSION}-preview-*' が見つかりませんでした。
トラブルシューティング:
プレビュー ランタイムでアプリを実行している場合、アプリのビットとアプリのランタイム バージョンに一致する、32 ビット (x86) または 64 ビット (x64) のいずれかのサイト拡張機能をインストールします。 両方の拡張機能や、拡張機能の複数のランタイム バージョンをインストールしないでください。
- ASP.NET Core {ランタイム バージョン} (x86) ランタイム
- ASP.NET Core {ランタイム バージョン} (x64) ランタイム
アプリを再起動します。 アプリが再起動するまで数秒待ちます。
プレビュー ランタイムでアプリを実行していて、32 ビット (x86)、64 ビット (x64) 両方のサイト拡張機能がインストールされている場合、アプリのビットと一致しないサイト拡張機能をアンインストールします。 サイト拡張機能を削除した後、アプリを再起動します。 アプリが再起動するまで数秒待ちます。
プレビュー ランタイムでアプリを実行していて、サイト拡張機能とアプリのビットが一致している場合、プレビュー サイト拡張機能の "ランタイム バージョン" がアプリのランタイム バージョンと一致していることを確認します。
[アプリケーション設定] のアプリの [プラットフォーム] がアプリのビットと一致していることを確認します。
詳細については、「Azure App Service に ASP.NET Core アプリを展開する」を参照してください。
x86 アプリが展開されますが、32 ビット アプリに対してアプリ プールは有効になりません。
ブラウザー: HTTP エラー 500.30 - ANCM インプロセス起動失敗
アプリケーション ログ: 物理ルートが '{PATH}' のアプリケーション '/LM/W3SVC/5/ROOT' に予想外のマネージド例外が発生しました、例外コード = '0xe0434352'。 詳細については、stderr ログを確認してください。 物理ルートが '{PATH}' のアプリケーション '/LM/W3SVC/5/ROOT' で clr とマネージド アプリケーションを読み込めませんでした。 CLR ワーカー スレッドが途中で終了しました
ASP.NET Core モジュールの stdout ログ: ログ ファイルが作成されましたが、空です。
ASP.NET Core モジュール デバッグ ログ: HRESULT が失敗し、次が返されました:0x8007023e
このシナリオは、自己完結型アプリの公開時、SDK によってトラップされます。 RID がプラットフォーム ターゲットに一致しない場合 (win10-x64 RID とプロジェクト ファイルの <PlatformTarget>x86</PlatformTarget> など)、SDK からエラーが生成されます。
トラブルシューティング:
x86 フレームワークに依存する展開の場合 (<PlatformTarget>x86</PlatformTarget>)、32 ビット アプリに対して IIS アプリ プールを有効にします。 IIS Manager でアプリ プールの [詳細設定] を開き、 [32 ビット アプリケーションの有効化] を [True] に設定します。
プラットフォームが RID と競合している
ブラウザー: HTTP エラー 502.5 - 処理エラー
アプリケーション ログ: 物理ルートが 'C:{PATH}' のアプリケーション 'MACHINE/WEBROOT/APPHOST/{ASSEMBLY}' は、コマンドライン '"C:{PATH}{ASSEMBLY}.{exe|dll}" ' でプロセスを開始できませんでした。ErrorCode = '0x80004005 : ff。
ASP.NET Core モジュールの stdout ログ: 未処理の例外:System.BadImageFormatException:ファイルまたはアセンブリ '{ASSEMBLY}.dll' を読み込めませんでした。 正しくない形式のプログラムを読み込もうとしました。
トラブルシューティング:
Kestrel でアプリをローカルに実行できることを確認します。 プロセスのエラーは、アプリ内の問題の結果である可能性があります。 詳細については、「Azure App Service および IIS での ASP.NET Core のトラブルシューティング」を参照してください。
Azure Apps 展開で、アプリケーションをアップグレードして新しいアセンブリを展開しようとしたときにこの例外が発生した場合は、以前の展開からすべてのファイルを手動で削除してください。 アップグレードしたアプリを展開するとき、互換性のないアセンブリが残っていると、
System.BadImageFormatException例外が発生します。
URI のエンドポイントが間違っているか、Web サイトが停止している
ブラウザー: ERR_CONNECTION_REFUSED --または-- 接続できません
アプリケーション ログ: エントリなし
ASP.NET Core モジュールの stdout ログ: ログ ファイルが作成されていません。
ASP.NET Core モジュール デバッグ ログ: ログ ファイルが作成されていません。
トラブルシューティング:
アプリに対して正しい URI エンドポイントが使用されていることを確認します。 バインドを確認します。
IIS Web サイトが [停止] 状態でないことを確認します。
CoreWebEngine または W3SVC サーバー機能が無効
OS の例外: ASP.NET Core モジュールを使用するには、IIS 7.0 CoreWebEngine および W3SVC の機能をインストールする必要があります。
トラブルシューティング:
適切な役割と機能が有効になっていることを確認します。 「IIS 構成」を参照してください。
Web サイト物理パスが間違っているか、アプリが見つからない
ブラウザー: 403 許可されていません - アクセスが拒否されました --または-- 403.14 許可されていません - Web サーバーは、このディレクトリの内容の一覧を表示しないように構成されています。
アプリケーション ログ: エントリなし
ASP.NET Core モジュールの stdout ログ: ログ ファイルが作成されていません。
ASP.NET Core モジュール デバッグ ログ: ログ ファイルが作成されていません。
トラブルシューティング:
IIS Web サイトの基本設定と物理アプリのフォルダーを確認します。 アプリが IIS Web サイトの物理パスにあるフォルダー内に配置されていることを確認します。
役割が正しくない、ASP.NET Core モジュールがインストールされていない、または不適切なアクセス許可
ブラウザー: 500.19 内部サーバー エラー - ページに関連する構成データが無効であるため、要求されたページにアクセスできません。 --または-- このページを表示できません
アプリケーション ログ: エントリなし
ASP.NET Core モジュールの stdout ログ: ログ ファイルが作成されていません。
ASP.NET Core モジュール デバッグ ログ: ログ ファイルが作成されていません。
トラブルシューティング:
適切な役割が有効になっていることを確認します。 「IIS 構成」を参照してください。
[プログラムと機能] または [アプリと機能] を開き、[Windows Server Hosting] がインストールされていることを確認します。 インストールされているプログラムの一覧に [Windows Server Hosting] がない場合、.NET Core ホスティング バンドルをダウンロードしてインストールします。
現在の .NET Core ホスティング バンドルのインストーラー (直接ダウンロード)
詳細については、「.NET Core ホスティング バンドルのインストール」をご覧ください。
[アプリケーション プール]>[プロセス モデル]>Identity が ApplicationPoolIdentity に設定されていることを確認します。または、カスタム ID に、アプリの展開フォルダーにアクセスするための正しいアクセス許可があることを確認します。
ASP.NET Core ホスティング バンドルをアンインストールし、以前のバージョンのホスティング バンドルをインストールした場合、applicationHost.config ファイルには ASP.NET Core モジュールのセクションが含まれません。 applicationHost.config で %windir%/System32/inetsrv/config を開き、
<configuration><configSections><sectionGroup name="system.webServer">セクション グループを見つけます。 セクション グループに ASP.NET Core モジュールのセクションがない場合は、セクション要素を追加します。<section name="aspNetCore" overrideModeDefault="Allow" />または、ASP.NET Core ホスティング バンドルの最新バージョンをインストールします。 最新バージョンは、ポートされている ASP.NET Core アプリと下位互換性があります。
processPath の誤り、PATH 変数の欠如、ホスティング バンドルが未インストール、システムまたは IIS が再起動されていない、VC++ 再頒布可能パッケージが未インストール、dotnet.exe アクセス違反
ブラウザー: HTTP エラー 500.0 - ANCM インプロセス ハンドラーの読み込みエラー
アプリケーション ログ: 物理ルートが 'C:{PATH}' のアプリケーション 'MACHINE/WEBROOT/APPHOST/{ASSEMBLY}' は、コマンドライン '"{...}" ' でプロセスを開始できませんでした。ErrorCode = '0x80070002 : 0。 アプリケーション '{PATH}' は開始できませんでした。 実行可能ファイルが '{PATH}' で見つかりませんでした。 アプリケーション '/LM/W3SVC/2/ROOT' を起動できませんでした、エラー コード '0x8007023e'。
ASP.NET Core モジュールの stdout ログ: ログ ファイルが作成されていません。
ASP.NET Core モジュール デバッグ ログ: イベント ログ:'アプリケーション '{PATH}' を起動できませんでした。 実行可能ファイルが '{PATH}' で見つかりませんでした。 HRESULT が失敗し、次が返されました:0x8007023e
トラブルシューティング:
Kestrel でアプリをローカルに実行できることを確認します。 プロセスのエラーは、アプリ内の問題の結果である可能性があります。 詳細については、「Azure App Service および IIS での ASP.NET Core のトラブルシューティング」を参照してください。
web.config で
<aspNetCore>要素の processPath 属性を調べ、フレームワークに依存する展開 (FDD) の場合はそれがdotnetであること、自己完結型展開 (SCD) の場合はそれが.\{ASSEMBLY}.exeであることを確認します。FDD の場合、PATH 設定で dotnet.exe にアクセスできていない可能性があります。 C:\Program Files\dotnet がシステムの PATH 設定に含まれていることを確認します。
FDD では、アプリ プールのユーザー ID で dotnet.exe にアクセスできていない可能性があります。 アプリ プール ユーザー ID に、C:\Program Files\dotnet ディレクトリへのアクセス許可が設定されていることを確認します。 C:\Program Files\dotnet とアプリのディレクトリに、アプリ プール ユーザー ID に対する拒否ルールが構成されていないことを確認します。
FDD を配置し、IIS を再起動せずに .NET Core をインストールした可能性があります。 サーバーを再起動するか、コマンド プロンプトから net stop was /y に続けて net start w3svc を実行して IIS を再起動します。
ホスト システムで、 .NET Core ランタイムをインストールせずに、FDD を配置した可能性があります。 .NET Core ランタイムがインストールされていない場合は、システムで .NET Core ホスティング バンドルのインストーラーを実行します。
現在の .NET Core ホスティング バンドルのインストーラー (直接ダウンロード)
詳細については、「.NET Core ホスティング バンドルのインストール」をご覧ください。
特定のランタイムが必要な場合、.NET ダウンロードのページからランタイムをダウンロードし、システムにインストールしてください。 インストールを完了するために、システムを再起動するか、コマンド プロンプトから net stop was /y に続けて net start w3svc を実行して IIS を再起動します。
<aspNetCore> 要素の引数の誤り
ブラウザー: HTTP エラー 500.0 - ANCM インプロセス ハンドラーの読み込みエラー
アプリケーション ログ: hostfxr を呼び出し、インプロセス要求ハンドラーを見つけようとすると、ネイティブの依存関係が見つからず、失敗しました。 これが意味するところは、ほとんどの場合、アプリが正しく設定されていないということです。アプリケーションの対象であり、コンピューターにインストールされている Microsoft.NetCore.App と Microsoft.AspNetCore.App のバージョンを確認してください。 インプロセス要求ハンドラーが見つかりませんでした。 hostfxr の呼び出し時にキャプチャされた出力:dotnet SDK コマンドを実行しますか? dotnet SDK を https://go.microsoft.com/fwlink/?LinkID=798306&clcid=0x409 からインストールしてください。アプリケーション '/LM/W3SVC/3/ROOT' を起動できませんでした。ErrorCode '0x8000ffff'。
ASP.NET Core モジュールの stdout ログ: dotnet SDK コマンドを実行しますか? dotnet SDK を https://go.microsoft.com/fwlink/?LinkID=798306&clcid=0x409 からインストールしてください
ASP.NET Core モジュール デバッグ ログ: hostfxr を呼び出し、インプロセス要求ハンドラーを見つけようとすると、ネイティブの依存関係が見つからず、失敗しました。 これが意味するところは、ほとんどの場合、アプリが正しく設定されていないということです。アプリケーションの対象であり、コンピューターにインストールされている Microsoft.NetCore.App と Microsoft.AspNetCore.App のバージョンを確認してください。 HRESULT が失敗し、次が返されました:0x8000ffff インプロセス要求ハンドラーが見つかりませんでした。 hostfxr の呼び出し時にキャプチャされた出力:dotnet SDK コマンドを実行しますか? dotnet SDK を https://go.microsoft.com/fwlink/?LinkID=798306&clcid=0x409 からインストールしてください。HRESULT が失敗し、次が返されました: 0x8000ffff
トラブルシューティング:
Kestrel でアプリをローカルに実行できることを確認します。 プロセスのエラーは、アプリ内の問題の結果である可能性があります。 詳細については、「Azure App Service および IIS での ASP.NET Core のトラブルシューティング」を参照してください。
web.config で
<aspNetCore>要素の arguments 属性を調べ、次のいずれかになっていることを確認します。(a) フレームワークに依存する展開 (FDD) の場合は.\{ASSEMBLY}.dll、または (b) 自己完結型の展開 (SCD) の場合は、未指定の空の文字列 (arguments="") か、アプリの引数のリスト (arguments="{ARGUMENT_1}, {ARGUMENT_2}, ... {ARGUMENT_X}")。
.NET Core 共有フレームワークがありません
ブラウザー: HTTP エラー 500.0 - ANCM インプロセス ハンドラーの読み込みエラー
アプリケーション ログ: hostfxr を呼び出し、インプロセス要求ハンドラーを見つけようとすると、ネイティブの依存関係が見つからず、失敗しました。 これが意味するところは、ほとんどの場合、アプリが正しく設定されていないということです。アプリケーションの対象であり、コンピューターにインストールされている Microsoft.NetCore.App と Microsoft.AspNetCore.App のバージョンを確認してください。 インプロセス要求ハンドラーが見つかりませんでした。 hostfxr の呼び出し時にキャプチャされた出力:互換性のあるフレームワーク バージョンが見つかりませんでした。 指定のフレームワーク 'Microsoft.AspNetCore.App', version '{VERSION}' が見つかりませんでした。
アプリケーション '/LM/W3SVC/5/ROOT' を起動できませんでした、エラー コード '0x8000ffff'。
ASP.NET Core モジュールの stdout ログ: 互換性のあるフレームワーク バージョンが見つかりませんでした。 指定のフレームワーク 'Microsoft.AspNetCore.App', version '{VERSION}' が見つかりませんでした。
ASP.NET Core モジュール デバッグ ログ: HRESULT が失敗し、次が返されました:0x8000ffff
トラブルシューティング:
フレームワークに依存する展開 (FDD) では、正しいランタイムがシステムにインストールされていることを確認します。
アプリケーション プールの停止
ブラウザー: 503 サービスをご利用いただけません
アプリケーション ログ: エントリなし
ASP.NET Core モジュールの stdout ログ: ログ ファイルが作成されていません。
ASP.NET Core モジュール デバッグ ログ: ログ ファイルが作成されていません。
トラブルシューティング:
アプリケーション プールが [停止] 状態でないことを確認します。
サブアプリケーションに <handlers> セクションが含まれている
ブラウザー: HTTP エラー 500.19 - 内部サーバー エラー
アプリケーション ログ: エントリなし
ASP.NET Core モジュールの stdout ログ: ルート アプリのログ ファイルが作成され、通常の操作を示しています。 サブアプリのログ ファイルが作成されていません。
ASP.NET Core モジュール デバッグ ログ: ルート アプリのログ ファイルが作成され、通常の動作を示します。 サブアプリのログ ファイルが作成されません。
トラブルシューティング:
サブアプリの web.config ファイルに <handlers> セクションがないか、サブアプリが親アプリのハンドラーを継承していないことを確認してください。
<system.webServer> の親アプリの <system.webServer> セクションが <location> 要素の中に置かれています。 InheritInChildApplications プロパティは、false に設定されます。これは、InheritInChildApplications 要素内で指定された設定が、親アプリのサブディレクトリにあるアプリによって継承されないことを示します。 詳細については、「IIS の ASP.NET Core モジュール (ANCM)」を参照してください。
stdout ログのパスが正しくありません
ブラウザー: アプリは通常どおりに応答します。
アプリケーション ログ: C:\Program Files\IIS\Asp.Net Core Module\V2\aspnetcorev2.dll で stdout リダイレクトを開始できません。 例外メッセージ:HRESULT 0x80070005 が {PATH}\aspnetcoremodulev2\commonlib\fileoutputmanager.cpp:84 で返されました。 C:\Program Files\IIS\Asp.Net Core Module\V2\aspnetcorev2.dll で stdout リダイレクトを停止できません。 例外メッセージ:HRESULT 0x80070002 が {PATH} で返されました。 {PATH}\aspnetcorev2_inprocess.dll で stdout リダイレクトを開始できません。
ASP.NET Core モジュールの stdout ログ: ログ ファイルが作成されていません。
ASP.NET Core モジュール デバッグ ログ: C:\Program Files\IIS\Asp.Net Core Module\V2\aspnetcorev2.dll で stdout リダイレクトを開始できません。 例外メッセージ:HRESULT 0x80070005 が {PATH}\aspnetcoremodulev2\commonlib\fileoutputmanager.cpp:84 で返されました。 C:\Program Files\IIS\Asp.Net Core Module\V2\aspnetcorev2.dll で stdout リダイレクトを停止できません。 例外メッセージ:HRESULT 0x80070002 が {PATH} で返されました。 {PATH}\aspnetcorev2_inprocess.dll で stdout リダイレクトを開始できません。
トラブルシューティング:
stdoutLogFileの<aspNetCore>要素で指定されたstdoutLogFileパスが存在しません。 詳細については、「ASP.NET Core モジュール:ログの作成とリダイレクト」を参照してください。アプリ プール ユーザーに stdout ログ パスに対する書き込みアクセス権がありません。
アプリケーション構成の一般的な問題
ブラウザー: HTTP エラー 500.0 - ANCM インプロセス要求ハンドラー失敗 --または-- HTTP エラー 500.30 - ANCM インプロセス起動失敗
アプリケーション ログ: 変数
ASP.NET Core モジュールの stdout ログ: ログ ファイルが作成されますが空です。あるいは作成され、通常のエントリが含まれますが、アプリのところでエラーが発生します。
ASP.NET Core モジュール デバッグ ログ: 変数
トラブルシューティング:
このプロセスはおそらく、アプリの設定またはプログラミングに問題があり、開始できませんでした。
詳細については、次のトピックを参照してください。
その他のリソース
- Visual Studio で .NET と ASP.NET Core のソース コードをデバッグする
- ASP.NET Core プロジェクトのトラブルシューティングとデバッグ
- ASP.NET Core のエラーを処理する
- IIS の ASP.NET Core モジュール (ANCM)
Azure のドキュメント
- ASP.NET Core 用 Application Insights
- Visual Studio を使用した Azure App Service の Web アプリのトラブルシューティングの Web アプリのリモート デバッグ セクション
- Azure App Service の診断の概要
- 方法: Azure App Service でアプリを監視する
- Visual Studio を使用した Azure App Service での Web アプリのトラブルシューティング
- Azure Web Apps での "502 bad gateway" および "503 service unavailable" の HTTP エラーのトラブルシューティング
- Azure App Service での Web アプリのパフォーマンス低下に関する問題のトラブルシューティング
- Azure での Web アプリのアプリケーションパフォーマンスに関するよくあるご質問
- Azure Web アプリのサンドボックス (App Service ランタイムの実行の制限)
Visual Studio ドキュメント
- Visual Studio 2017 における Azure の IIS での ASP.NET Core のリモート デバッグ
- Visual Studio 2017 におけるリモートの IIS コンピューターでの ASP.NET Core のリモート デバッグ
- Visual Studio を使用したデバッグについて理解する
Visual Studio Code ドキュメント
この記事では、アプリの起動時に発生する一般的なエラーに関する情報と、アプリが Azure App Service または IIS にデプロイされるときのエラーを診断する手順を提供します。
アプリ起動時のエラー
一般的な起動時の HTTP 状態コードのシナリオについて説明します。
Azure App Service でのトラブルシューティング
Azure App Service にデプロイされたアプリに関するトラブルシューティングのアドバイスを提供します。
IIS でのトラブルシューティング
IIS にデプロイされているアプリまたは IIS Express でローカルに実行されているアプリに関するトラブルシューティングのアドバイスを提供します。 このガイダンスは、Windows Server と Windows デスクトップの両方の配置に適用されます。
パッケージ キャッシュをクリアする
統一性のないパッケージにより、メジャー アップグレードの実行時またはパッケージ バージョンの変更時に、アプリが中断したときの対処方法について説明します。
その他のリソース
その他のトラブルシューティングのトピックを一覧表示します。
アプリ起動時のエラー
Visual Studio では、ASP.NET Core プロジェクトのデバッグ時に IIS Express のホスティングが既定の設定です。 このトピックのアドバイスを使用すると、ローカルでのデバッグ時に発生する "502.5 - 処理エラー" または "500.30 - 開始エラー" を診断できます。
403.14 禁止
アプリの開始に失敗しました。 次のエラーがログに記録されます。
The Web server is configured to not list the contents of this directory.
このエラーが発生するのは、通常、ホスト システム上の配置が壊れている場合です。これには、次のようなシナリオが含まれます。
- アプリがホスト システム上の不適切なフォルダーに配置されています。
- 配置プロセスで、アプリのすべてのファイルとフォルダーを、ホスティング システムの配置フォルダーに移動できませんでした。
- 配置に web.config ファイルがありません。または、web.config ファイルの内容の形式が正しくありません。
次の手順に従います。
- ホスト システム上の配置フォルダーからすべてのファイルとフォルダーを削除します。
- Visual Studio、PowerShell、手動配置など、通常の配置方法を使用して、アプリの "公開" フォルダーの内容をホスティング システムに再配置します。
- web.config ファイルがそのデプロイに存在し、その内容が正しいことを確認します。
- Azure App Service でホストする場合は、アプリが
D:\home\site\wwwrootフォルダーにデプロイされていることを確認します。 - アプリが IIS によってホストされている場合は、アプリが IIS マネージャーの [基本設定] に表示されている IIS の物理パスに配置されていることを確認します。
- ホスティング システムの配置をプロジェクトの "公開" フォルダーの内容と比較して、アプリのすべてのファイルとフォルダーが配置されていることを確認します。
公開された ASP.NET Core アプリのレイアウトの詳細については、「ASP.NET Core のディレクトリ構造」を参照してください。 web.config ファイルの詳細については、IIS の ASP.NET Core モジュール (ANCM) に関するページを参照してください。
500 内部サーバー エラー
アプリは起動しますが、エラーのためにサーバーは要求を実行できません。
このエラーは、起動時または応答の作成中に、アプリのコード内で発生します。 応答にコンテンツが含まれていないか、またはブラウザーに "500 内部サーバー エラー" という応答が表示される可能性があります。 通常、アプリケーション イベント ログではアプリが正常に起動したことが示されます。 サーバーから見るとそれは正しいことです。 アプリは起動しましたが、有効な応答を生成できません。 問題を解決するには、サーバー上のコマンド プロンプトでアプリを実行するか、ASP.NET Core モジュールの stdout ログを有効にします。
このエラーは、.NET Core ホスティング バンドルがインストールされていないか、破損している場合にも発生する可能性があります。 .NET Core ホスティング バンドル (IIS 用) または Visual Studio (IIS Express 用) をインストールするか、インストールを修復すると、問題が解決する場合があります。
500.0 インプロセス ハンドラーの読み込みエラー
ワーカー プロセスが失敗します。 アプリは起動しません。
ASP.NET Core モジュールは .NET Core CLR の検出に失敗し、インプロセス要求ハンドラー (aspnetcorev2_inprocess.dll) を検出します。 次の点をご確認ください。
- アプリが Microsoft.AspNetCore.Server.IIS NuGet パッケージまたは Microsoft.AspNetCore.App メタパッケージを対象としている。
- アプリが対象としているバージョンの ASP.NET Core 共有フレームワークが対象のコンピューターにインストールされている。
500.0 アウト プロセス ハンドラーの読み込みエラー
ワーカー プロセスが失敗します。 アプリは起動しません。
ASP.NET Core モジュールは、アウト プロセスのホスティング要求ハンドラーの検索に失敗します。 aspnetcorev2_outofprocess.dll が aspnetcorev2.dll の隣のサブフォルダーにあることを確認してください。
502.5 処理エラー
ワーカー プロセスが失敗します。 アプリは起動しません。
ASP.NET Core モジュールはワーカー プロセスの開始を試みますが、開始に失敗します。 プロセス起動時のエラーの原因は、通常、アプリケーション イベント ログと ASP.NET Core モジュールの stdout ログのエントリから判断できます。
一般的なエラー条件は、存在しないバージョンの ASP.NET Core 共有フレームワークが対象にされていて、アプリが正しく構成されていないことです。 対象のコンピューターにどのバージョンの ASP.NET Core 共有フレームワークがインストールされているかを確認します。 共有フレームワークは、コンピューター上にインストールされたアセンブリ ( .dll ファイル) のセットであり、Microsoft.AspNetCore.App などのメタパッケージによって参照されます。 メタパッケージの参照には、必要な最低限のバージョンを指定できます。 詳しくは、共有フレームワークに関するページをご覧ください。
正しく構成されていないホスティングやアプリが原因でワーカー プロセスが失敗する場合、"502.5 処理エラー" のエラー ページが返されます。
アプリケーションの起動に失敗しました (ErrorCode '0x800700c1')
EventID: 1010
Source: IIS AspNetCore Module V2
Failed to start application '/LM/W3SVC/6/ROOT/', ErrorCode '0x800700c1'.
アプリのアセンブリ ( .dll) を読み込めなかったため、アプリの起動に失敗しました。
このエラーは、公開されたアプリと w3wp/iisexpress プロセスの間でビットの不一致がある場合に発生します。
アプリ プールの 32 ビット設定が正しいことを確認してください。
- IIS マネージャーの [アプリケーション プール] でそのアプリ プールを選択します。
- [アクション] パネルの [アプリケーション プールの編集] で [詳細設定] を選択します。
- [32 ビット アプリケーションの有効化] を設定します。
- 32 ビット (x86) アプリを展開する場合は、この値を
Trueに設定します。 - 64 ビット (x64) アプリを展開する場合は、この値を
Falseに設定します。
- 32 ビット (x86) アプリを展開する場合は、この値を
プロジェクト ファイルの <Platform> MSBuild プロパティと公開されたアプリのビット数との間で競合が発生していないことを確認します。
接続のリセット
ヘッダー送信後にエラーが発生した場合、サーバーが 500 内部サーバー エラーを送信するには遅すぎます。 このような状況は、応答に対する複雑なオブジェクトのシリアル化中にエラーが起きたときによく発生します。 この種のエラーは、クライアントでは "接続リセット" エラーとして表示されます。 この種のエラーのトラブルシューティングには、アプリケーション ログが役に立つことがあります。
既定の起動制限
ASP.NET Core モジュールの startupTimeLimit は、既定では 120 秒に構成されます。 既定値のままにした場合、モジュールで処理エラーが記録されるまでに、アプリは最大で 2 分を起動にかけることができます。 モジュールの構成の詳細については、「AspNetCore 要素の属性」を参照してください。
Azure App Service でのトラブルシューティング
重要
Azure App Service と ASP.NET Core のプレビュー リリース
ASP.NET Core のプレビュー リリースは、既定では Azure App Service に展開されません。 ASP.NET Core プレビュー リリースを使用するアプリをホストするには、「Azure App Service に ASP.NET Core プレビュー リリースを展開する」を参照してください。
アプリケーション イベント ログ (Azure App Service)
アプリケーション イベント ログにアクセスするには、Azure portal の [問題の診断と解決] ブレードを使います。
- Azure portal の [App Services] でアプリを開きます。
- [問題の診断と解決] を選択します。
- [診断ツール] という見出しを選択します。
- [サポート ツール] で [アプリケーション イベント] ボタンを選択します。
- [Source](ソース) 列で、IIS AspNetCoreModule または IIS AspNetCoreModule V2 によって提供された最新のエラーを調べます。
[問題の診断と解決] ブレードを使う代わりに、Kudu を使ってアプリケーション イベント ログ ファイルを直接調べることもできます。
- [開発ツール] 領域で [高度なツール] を開きます。 [Go→] ボタンを選択します。 新しいブラウザー タブまたはウィンドウで Kudu コンソールが開きます。
- ページの上部にあるナビゲーション バーを使って [デバッグ コンソール] を開き、 [CMD] を選びます。
- LogFiles フォルダーを開きます。
eventlog.xmlファイルの横にある鉛筆アイコンを選択します。- ログを調べます。 ログの末尾までスクロールし、最新のイベントを確認します。
Kudu コンソールでアプリを実行します。
多くの起動時エラーでは、アプリケーション イベント ログに役に立つ情報が生成されません。 Kudu のリモート実行コンソールでアプリを実行すると、エラーを検出することができます。
- [開発ツール] 領域で [高度なツール] を開きます。 [Go→] ボタンを選択します。 新しいブラウザー タブまたはウィンドウで Kudu コンソールが開きます。
- ページの上部にあるナビゲーション バーを使って [デバッグ コンソール] を開き、 [CMD] を選びます。
32 ビット (x86) アプリをテストする
現在のリリース
cd d:\home\site\wwwroot- アプリを実行します:
アプリがフレームワークに依存する展開の場合:
dotnet .\{ASSEMBLY NAME}.dllアプリが自己完結型の展開の場合:
{ASSEMBLY NAME}.exe
エラーを示すアプリからのコンソール出力はすべて、Kudu コンソールにパイプされます。
プレビュー リリース上で実行されているフレームワークに依存するデプロイ
"ASP.NET Core {バージョン} (x86) ランタイムのサイト拡張機能をインストールする必要があります。 "
cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x32({X.Y}はランタイム バージョンです)- アプリを実行します:
dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll
エラーを示すアプリからのコンソール出力はすべて、Kudu コンソールにパイプされます。
64 ビット (x64) アプリをテストする
現在のリリース
- アプリが 64 ビット (x64) のフレームワークに依存する展開の場合:
cd D:\Program Files\dotnet- アプリを実行します:
dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll
- アプリが自己完結型の展開の場合:
cd D:\home\site\wwwroot- アプリを実行します:
{ASSEMBLY NAME}.exe
エラーを示すアプリからのコンソール出力はすべて、Kudu コンソールにパイプされます。
プレビュー リリース上で実行されているフレームワークに依存するデプロイ
"ASP.NET Core {バージョン} (x64) ランタイムのサイト拡張機能をインストールする必要があります。 "
cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x64({X.Y}はランタイム バージョンです)- アプリを実行します:
dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll
エラーを示すアプリからのコンソール出力はすべて、Kudu コンソールにパイプされます。
ASP.NET Core モジュールの stdout ログ (Azure App Service)
ASP.NET Core モジュールの stdout には、アプリケーション イベント ログでは見つからない有用なエラー メッセージが記録されることがよくあります。 stdout ログを有効にして表示するには:
- Azure portal で [問題の診断と解決] ブレードに移動します。
- [SELECT PROBLEM CATEGORY](問題カテゴリの選択) で、 [Web App Down](Web アプリのダウン) ボタンを選びます。
- [Suggested Solutions](推奨される解決方法)>[Enable Stdout Log Redirection](Stdout ログのリダイレクトを有効にする) で、ボタンをクリックして[Open Kudu Console to edit Web.Config](Kudu コンソールを開いて Web.Config を編集する) ボタンを選びます。
- Kudu の診断コンソールで、パス site>wwwroot へのフォルダーを開きます。 下にスクロールして、一覧の最後にある web.config ファイルを表示します。
- web.config ファイルの隣の鉛筆アイコンをクリックします。
- stdoutLogEnabled を
trueに設定し、stdoutLogFile パスを\\?\%home%\LogFiles\stdoutに変更します。 - [保存] を選んで、更新した web.config ファイルを保存します。
- アプリに対して要求します。
- Azure portal に戻ります。 [開発ツール] 領域で [高度なツール] ブレードを選びます。 [Go→] ボタンを選択します。 新しいブラウザー タブまたはウィンドウで Kudu コンソールが開きます。
- ページの上部にあるナビゲーション バーを使って [デバッグ コンソール] を開き、 [CMD] を選びます。
- LogFiles フォルダーを選びます。
- [Modified](変更日) 列を調べて、変更日が最新の stdout ログの鉛筆アイコンを選んで編集します。
- ログ ファイルが開くと、エラーが表示されます。
トラブルシューティングが完了したら、stdout ログを無効にします。
- Kudu の診断コンソール で、パス site>wwwroot に戻り、web.config ファイルを表示します。 鉛筆アイコンを選んで web.config ファイルを再び開きます。
- stdoutLogEnabled を
falseに設定します。 - [保存] を選んでファイルを保存します。
詳細については、IIS の ASP.NET Core モジュール (ANCM) に関するページを参照してください。
警告
stdout ログを無効にしないと、アプリまたはサーバーで障害が発生する可能性があります。 ログ ファイルのサイズまたは作成されるログ ファイルの数に制限はありません。 stdout ログは、アプリ起動時の問題のトラブルシューティングにのみ使ってください。
起動後の ASP.NET Core アプリでの一般的なログの場合は、ログ ファイルのサイズを制限し、ログをローテーションするログ ライブラリを使います。 詳細については、「サードパーティ製のログ プロバイダー」を参照してください。
ASP.NET Core モジュールのデバッグ ログ (Azure App Service)
ASP.NET Core モジュール デバッグ ログでは、ASP.NET Core モジュールのさらに詳しいログが提供されます。 stdout ログを有効にして表示するには:
- 強化された診断ログを有効にするには、次のいずれかを実行します。
- 「強化された診断ログ」の指示に従い、強化された診断ログをアプリに対して設定します。 アプリを再デプロイします。
- Kudu コンソールを利用し、「
<handlerSettings>強化された診断ログ」にある をライブ アプリの web.config ファイルに追加します。- [開発ツール] 領域で [高度なツール] を開きます。 [Go→] ボタンを選択します。 新しいブラウザー タブまたはウィンドウで Kudu コンソールが開きます。
- ページの上部にあるナビゲーション バーを使って [デバッグ コンソール] を開き、 [CMD] を選びます。
- パス site>wwwroot へのフォルダーを開きます。 鉛筆アイコンを選択し、web.config ファイルを編集します。 「強化された診断ログ」にある
<handlerSettings>セクションを追加します。 [保存] ボタンを選択します。
- [開発ツール] 領域で [高度なツール] を開きます。 [Go→] ボタンを選択します。 新しいブラウザー タブまたはウィンドウで Kudu コンソールが開きます。
- ページの上部にあるナビゲーション バーを使って [デバッグ コンソール] を開き、 [CMD] を選びます。
- パス site>wwwroot へのフォルダーを開きます。 aspnetcore-debug.log ファイルにパスを指定しなかった場合、ファイルが一覧に表示されます。 パスを指定した場合、ログ ファイルの場所に移動します。
- ファイル名の隣にある鉛筆アイコンでログ ファイルを開きます。
トラブルシューティングが完了したら、debug ログを無効にします。
強化されたデバッグ ログを無効にするには、次のいずれかを実行します。
- ローカルの web.config ファイルから
<handlerSettings>を削除し、アプリを再デプロイします。 - Kudu コンソールを使用して web.config ファイルを編集し、
<handlerSettings>セクションを削除します。 ファイルを保存します。
詳細については、ASP.NET Core モジュールを使用したログの作成とリダイレクトに関する記事を参照してください。
警告
debug ログを無効にしないと、アプリまたはサーバーで障害が発生する可能性があります。 ログ ファイルのサイズに制限はありません。 debug ログは、アプリ起動時の問題のトラブルシューティングにのみ使ってください。
起動後の ASP.NET Core アプリでの一般的なログの場合は、ログ ファイルのサイズを制限し、ログをローテーションするログ ライブラリを使います。 詳細については、「サードパーティ製のログ プロバイダー」を参照してください。
遅いアプリまたはハングしているアプリ (Azure App Service)
要求に対してアプリの反応が遅い場合、またはハングする場合は、次の記事を参照してください。
- Azure App Service での Web アプリのパフォーマンス低下に関する問題のトラブルシューティング
- Use Crash Diagnoser Site Extension to Capture Dump for Intermittent Exception issues or performance issues on Azure Web App (クラッシュ診断サイト拡張機能を使用して Azure Web App での断続的な例外の問題またはパフォーマンスの問題用のダンプをキャプチャする)
監視ブレード
監視ブレードでは、このトピックでこれまでに説明した方法に代わるトラブルシューティング エクスペリエンスが提供されます。 これらのブレードは、500 番台のエラーの診断に使用できます。
ASP.NET Core 拡張機能がインストールされていることを確認してください。 拡張機能がインストールされていない場合は、手動でインストールします。
- [開発ツール] ブレード セクションで、 [拡張機能] ブレードを選びます。
- [ASP.NET Core Extensions](ASP.NET Core 拡張機能) が一覧に表示されます。
- 拡張機能がインストールされていない場合は、 [追加] ボタンを選びます。
- 一覧から [ASP.NET Core Extensions](ASP.NET Core 拡張機能) を選びます。
- [OK] を選んで法的条項に同意します。
- [拡張機能の追加] ブレードで [OK] を選びます。
- 拡張機能が正常にインストールされると、情報ポップアップ メッセージで通知されます。
stdout ログが有効になっていない場合は、次の手順のようにします。
- Azure portal の [開発ツール] 領域で [高度なツール] ブレードを選びます。 [Go→] ボタンを選択します。 新しいブラウザー タブまたはウィンドウで Kudu コンソールが開きます。
- ページの上部にあるナビゲーション バーを使って [デバッグ コンソール] を開き、 [CMD] を選びます。
- パス site>wwwroot へのフォルダーを開き、下にスクロールして、一覧の最後にある web.config ファイルを表示します。
- web.config ファイルの隣の鉛筆アイコンをクリックします。
- stdoutLogEnabled を
trueに設定し、stdoutLogFile パスを\\?\%home%\LogFiles\stdoutに変更します。 - [保存] を選んで、更新した web.config ファイルを保存します。
続けて診断ログをアクティブにします。
- Azure portal で [診断ログ] ブレードを選びます。
- [アプリケーション ログ (ファイル システム)] および [詳細なエラー メッセージ] の [オン] スイッチを選びます。 ブレードの上部にある [保存] ボタンを選びます。
- 失敗した要求イベントのバッファ処理 (FREB) とも呼ばれる失敗した要求のトレースを含めるには、 [失敗した要求のトレース] で [オン] スイッチを選びます。
- ポータルで [診断ログ] ブレードのすぐ下にある [ログ ストリーム] ブレードを選びます。
- アプリに対して要求します。
- ログ ストリーム データ内で、エラーの原因が示されます。
トラブルシューティングが完了したら、stdout ログを無効にしてください。
失敗した要求のトレース ログ (FREB ログ) を見るには:
- Azure portal で [問題の診断と解決] ブレードに移動します。
- サイド バーの [SUPPORT TOOLS](サポート ツール) 領域で、 [Failed Request Tracing Logs](失敗した要求のトレース ログ) を選びます。
詳しくは、「Azure App Service の Web アプリの診断ログの有効化」トピックの「失敗した要求トレース」セクションおよび「Azure での Web アプリのアプリケーション パフォーマンスに関するよくあるご質問」の「失敗した要求トレースをオンにするにはどうすればよいですか?」をご覧ください。
詳しくは、「Azure App Service の Web アプリの診断ログの有効化」をご覧ください。
警告
stdout ログを無効にしないと、アプリまたはサーバーで障害が発生する可能性があります。 ログ ファイルのサイズまたは作成されるログ ファイルの数に制限はありません。
ASP.NET Core アプリでのルーチン ログの場合は、ログ ファイルのサイズを制限し、ログをローテーションするログ ライブラリを使います。 詳細については、「サードパーティ製のログ プロバイダー」を参照してください。
IIS でのトラブルシューティング
アプリケーション イベント ログ (IIS)
アプリケーション イベント ログにアクセスします。
- [スタート] メニューを開き、イベント ビューアーを検索し、イベント ビューアー アプリを選択します。
- イベント ビューアーで [Windows ログ] ノードを開きます。
- [Application] を選択して、アプリケーション イベント ログを開きます。
- 失敗したアプリに関連するエラーを検索します。 エラーの [ソース] 列には IIS AspNetCore Module または IIS Express AspNetCore Module の値が表示されます。
コマンド プロンプトでアプリを実行する
多くの起動時エラーでは、アプリケーション イベント ログに役に立つ情報が生成されません。 ホスティング システムのコマンド プロンプトでアプリを実行すると、エラーの原因がわかることがあります。
フレームワークに依存する展開
アプリがフレームワークに依存する展開の場合:
- コマンド プロンプトで展開フォルダーに移動し、dotnet.exe 使用してアプリのアセンブリを実行して、アプリを実行します。
dotnet .\<assembly_name>.dllコマンドの <assembly_name> を、アプリのアセンブリの名前に置き換えます。 - エラーを示すアプリからのコンソール出力は、すべてコンソール ウィンドウに書き込まれます。
- アプリへの要求時にエラーが発生した場合は、Kestrel がリッスンしているホストとポートに要求が送信されます。 既定のホストと post を使用して
http://localhost:5000/に要求を行います。 アプリが Kestrel のエンドポイント アドレスで正常に応答する場合、問題はホスティングの構成に関連している可能性が高く、アプリ内が原因の可能性は低くなります。
自己完結型の展開
アプリが自己完結型の展開の場合:
- コマンド プロンプトで、展開フォルダーに移動し、アプリの実行可能ファイルを実行します。
<assembly_name>.exeコマンドの <assembly_name> を、アプリのアセンブリの名前に置き換えます。 - エラーを示すアプリからのコンソール出力は、すべてコンソール ウィンドウに書き込まれます。
- アプリへの要求時にエラーが発生した場合は、Kestrel がリッスンしているホストとポートに要求が送信されます。 既定のホストと post を使用して
http://localhost:5000/に要求を行います。 アプリが Kestrel のエンドポイント アドレスで正常に応答する場合、問題はホスティングの構成に関連している可能性が高く、アプリ内が原因の可能性は低くなります。
ASP.NET Core モジュールの stdout ログ (IIS)
stdout ログを有効にして表示するには:
- ホスティング システム上のサイトの展開フォルダーに移動します。
- logs フォルダーが存在しない場合は、フォルダーを作成します。 MSBuild で展開フォルダーに logs フォルダーを自動的に作成されるようにする手順については、「ディレクトリ構造」のトピックを参照してください。
- web.config ファイルを編集します。 stdoutLogEnabled を
trueに設定し、stdoutLogFile のパスを logs フォルダー (たとえば.\logs\stdout) を指すように変更します。 パスのstdoutはログ ファイル名のプレフィックスです。 ログ ファイルの作成時には、タイムスタンプ、プロセス ID、およびファイルの拡張子が自動的に追加されます。 ファイル名のプレフィックスとしてstdoutを使用すると、一般的なログ ファイルの名前は stdout_20180205184032_5412.log になります。 - アプリケーション プールの ID に logs フォルダーへの書き込みアクセス許可があることを確認します。
- 更新した web.config ファイルを保存します。
- アプリに対して要求します。
- logs フォルダーに移動します。 最新の stdout ログを探して開きます。
- ログのエラーを調べます。
トラブルシューティングが完了したら、stdout ログを無効にします。
- web.config ファイルを編集します。
- stdoutLogEnabled を
falseに設定します。 - ファイルを保存します。
詳細については、IIS の ASP.NET Core モジュール (ANCM) に関するページを参照してください。
警告
stdout ログを無効にしないと、アプリまたはサーバーで障害が発生する可能性があります。 ログ ファイルのサイズまたは作成されるログ ファイルの数に制限はありません。
ASP.NET Core アプリでのルーチン ログの場合は、ログ ファイルのサイズを制限し、ログをローテーションするログ ライブラリを使います。 詳細については、「サードパーティ製のログ プロバイダー」を参照してください。
ASP.NET Core モジュールのデバッグ ログ (IIS)
ASP.NET Core モジュールのデバッグ ログを有効にするには、次のハンドラー設定をアプリの web.config ファイルに追加します。
<aspNetCore ...>
<handlerSettings>
<handlerSetting name="debugLevel" value="file" />
<handlerSetting name="debugFile" value="c:\temp\ancm.log" />
</handlerSettings>
</aspNetCore>
ログに指定されたパスが存在することと、アプリ プールの ID にその場所への書き込みアクセス許可があることを確認します。
詳細については、ASP.NET Core モジュールを使用したログの作成とリダイレクトに関する記事を参照してください。
開発者例外ページを有効にする
開発環境でアプリを実行するには、ASPNETCORE_ENVIRONMENT環境変数を web.config に追加することができます。 アプリの起動時にホスト ビルダー上で UseEnvironment によって環境がオーバーライドされない限り、環境変数を設定すると、アプリの実行時に開発者例外ページが表示されます。
<aspNetCore processPath="dotnet"
arguments=".\MyApp.dll"
stdoutLogEnabled="false"
stdoutLogFile=".\logs\stdout"
hostingModel="InProcess">
<environmentVariables>
<environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Development" />
</environmentVariables>
</aspNetCore>
ASPNETCORE_ENVIRONMENT の環境変数を設定する方法は、インターネットに公開されないステージング サーバーやテスト用サーバーの場合にのみお勧めされます。 トラブルシューティング後は、必ず web.config ファイルからこの環境変数を削除してください。 web.config で環境変数を設定する方法の詳細については、aspNetCore の environmentVariables 子要素を参照してください。
アプリからデータを取得する
アプリが要求に応答できる場合は、ターミナル インライン ミドルウェアを使用して、要求、接続、その他のデータをアプリから取得します。 詳細とサンプル コードについては、「ASP.NET Core プロジェクトのトラブルシューティングとデバッグ」を参照してください。
遅いアプリまたはハングしているアプリ (IIS)
"クラッシュ ダンプ" とはシステムのメモリのスナップショットであり、アプリのクラッシュ、起動の失敗、遅いアプリの原因を突き止めるのに役立ちます。
アプリのクラッシュまたは例外の発生
Windows エラー報告 (WER) からダンプを取得して分析します。
c:\dumpsにクラッシュ ダンプ ファイルを保持するフォルダーを作成します。 アプリ プールには、そのフォルダーへの書き込みアクセス権が必要です。EnableDumps PowerShell スクリプト を実行します。
アプリでインプロセス ホスティング モデルが使われている場合は、w3wp.exe に対するスクリプトを実行します。
.\EnableDumps w3wp.exe c:\dumpsアプリでアウト プロセス ホスティング モデルが使われている場合は、dotnet.exe に対するスクリプトを実行します。
.\EnableDumps dotnet.exe c:\dumps
クラッシュが発生する条件の下でアプリを実行します。
クラッシュが発生した後、DisableDumps PowerShell スクリプトを実行します。
アプリでインプロセス ホスティング モデルが使われている場合は、w3wp.exe に対するスクリプトを実行します。
.\DisableDumps w3wp.exeアプリでアウト プロセス ホスティング モデルが使われている場合は、dotnet.exe に対するスクリプトを実行します。
.\DisableDumps dotnet.exe
アプリがクラッシュし、ダンプの収集が完了したら、アプリを普通に終了してかまいません。 PowerShell スクリプトにより、アプリごとに最大 5 つのダンプを収集する WER が構成されます。
警告
クラッシュ ダンプでは、大量のディスク領域 (1 つにつき最大、数ギガバイト) が使用される場合があります。
アプリが起動時または正常な実行中にハングまたは失敗する
アプリが起動時または正常な実行中に "ハング" (応答を停止するがクラッシュしない) または失敗するときは、「User-Mode Dump Files:Choosing the Best Tool」(ユーザー モード ダンプ ファイル: 最適なツールの選択) を参照し、適切なツールを選択してダンプを生成します。
ダンプを分析する
ダンプはいくつかの方法で分析できます。 詳細については、「Analyzing a User-Mode Dump File」(ユーザー モード ダンプ ファイルの分析) を参照してください。
パッケージ キャッシュをクリアする
開発マシンで .NET Core SDK をアップグレードしたり、アプリ内のパッケージ バージョンを変更したりした直後に、機能しているアプリが失敗することがあります。 場合によっては、パッケージに統一性がないと、メジャー アップグレード実行時にアプリが破壊されることがあります。 これらの問題のほとんどは、次の手順で解決できます。
bin フォルダーと obj フォルダーを削除します。
コマンド シェルから dotnet nuget locals all --clear を実行して、パッケージ キャッシュをクリアします。
パッケージ キャッシュをクリアするには、nuget.exe ツールを使用して
nuget locals all -clearコマンドを実行する方法もあります。 nuget.exe は、Windows デスクトップ オペレーティング システムにバンドルされているインストールではなく、NuGet Web サイトから別に入手する必要があります。プロジェクトを復元してリビルドします。
アプリを再展開する前に、サーバー上の展開フォルダー内のすべてのファイルを削除します。
その他の技術情報
Azure のドキュメント
- ASP.NET Core 用 Application Insights
- Visual Studio を使用した Azure App Service の Web アプリのトラブルシューティングの Web アプリのリモート デバッグ セクション
- Azure App Service の診断の概要
- 方法: Azure App Service でアプリを監視する
- Visual Studio を使用した Azure App Service での Web アプリのトラブルシューティング
- Azure Web Apps での "502 bad gateway" および "503 service unavailable" の HTTP エラーのトラブルシューティング
- Azure App Service での Web アプリのパフォーマンス低下に関する問題のトラブルシューティング
- Azure での Web アプリのアプリケーションパフォーマンスに関するよくあるご質問
- Azure Web アプリのサンドボックス (App Service ランタイムの実行の制限)
Visual Studio ドキュメント
- Visual Studio 2017 における Azure の IIS での ASP.NET Core のリモート デバッグ
- Visual Studio 2017 におけるリモートの IIS コンピューターでの ASP.NET Core のリモート デバッグ
- Visual Studio を使用したデバッグについて理解する
Visual Studio Code ドキュメント
この記事では、アプリの起動時に発生する一般的なエラーに関する情報と、アプリが Azure App Service または IIS にデプロイされるときのエラーを診断する手順を提供します。
アプリ起動時のエラー
一般的な起動時の HTTP 状態コードのシナリオについて説明します。
Azure App Service でのトラブルシューティング
Azure App Service にデプロイされたアプリに関するトラブルシューティングのアドバイスを提供します。
IIS でのトラブルシューティング
IIS にデプロイされているアプリまたは IIS Express でローカルに実行されているアプリに関するトラブルシューティングのアドバイスを提供します。 このガイダンスは、Windows Server と Windows デスクトップの両方の配置に適用されます。
パッケージ キャッシュをクリアする
統一性のないパッケージにより、メジャー アップグレードの実行時またはパッケージ バージョンの変更時に、アプリが中断したときの対処方法について説明します。
その他のリソース
その他のトラブルシューティングのトピックを一覧表示します。
アプリ起動時のエラー
Visual Studio では、ASP.NET Core プロジェクトの既定のサーバーは Kestrel です。 Visual Studio は、IIS Express を使用するように構成することができます。 このトピックのアドバイスを使用すると、IIS Express を使用したローカルでのデバッグ時に発生する "502.5 - 処理エラー" または "500.30 - 開始エラー" を診断できます。
403.14 禁止
アプリの開始に失敗しました。 次のエラーがログに記録されます。
The Web server is configured to not list the contents of this directory.
このエラーが発生するのは、通常、ホスト システム上の配置が壊れている場合です。これには、次のようなシナリオが含まれます。
- アプリがホスト システム上の不適切なフォルダーに配置されています。
- 配置プロセスで、アプリのすべてのファイルとフォルダーを、ホスティング システムの配置フォルダーに移動できませんでした。
- 配置に web.config ファイルがありません。または、web.config ファイルの内容の形式が正しくありません。
次の手順に従います。
- ホスト システム上の配置フォルダーからすべてのファイルとフォルダーを削除します。
- Visual Studio、PowerShell、手動配置など、通常の配置方法を使用して、アプリの "公開" フォルダーの内容をホスティング システムに再配置します。
- web.config ファイルがそのデプロイに存在し、その内容が正しいことを確認します。
- Azure App Service でホストする場合は、アプリが
D:\home\site\wwwrootフォルダーにデプロイされていることを確認します。 - アプリが IIS によってホストされている場合は、アプリが IIS マネージャーの [基本設定] に表示されている IIS の物理パスに配置されていることを確認します。
- ホスティング システムの配置をプロジェクトの "公開" フォルダーの内容と比較して、アプリのすべてのファイルとフォルダーが配置されていることを確認します。
公開された ASP.NET Core アプリのレイアウトの詳細については、「ASP.NET Core のディレクトリ構造」を参照してください。 web.config ファイルの詳細については、IIS の ASP.NET Core モジュール (ANCM) に関するページを参照してください。
500 内部サーバー エラー
アプリは起動しますが、エラーのためにサーバーは要求を実行できません。
このエラーは、起動時または応答の作成中に、アプリのコード内で発生します。 応答にコンテンツが含まれていないか、またはブラウザーに "500 内部サーバー エラー" という応答が表示される可能性があります。 通常、アプリケーション イベント ログではアプリが正常に起動したことが示されます。 サーバーから見るとそれは正しいことです。 アプリは起動しましたが、有効な応答を生成できません。 問題を解決するには、サーバー上のコマンド プロンプトでアプリを実行するか、ASP.NET Core モジュールの stdout ログを有効にします。
このエラーは、.NET Core ホスティング バンドルがインストールされていないか、破損している場合にも発生する可能性があります。 .NET Core ホスティング バンドル (IIS 用) または Visual Studio (IIS Express 用) をインストールするか、インストールを修復すると、問題が解決する場合があります。
500.0 インプロセス ハンドラーの読み込みエラー
ワーカー プロセスが失敗します。 アプリは起動しません。
ASP.NET Core モジュール コンポーネントの読み込み中に不明なエラーが発生しました。 次のいずれかのアクションを実行します。
- Microsoft サポートに問い合わせます ( [開発者ツール] 、 [ASP.NET Core] の順に選択します)。
- Stack Overflow について質問します。
- GitHub リポジトリで問題を報告します。
500.30 インプロセス起動エラー
ワーカー プロセスが失敗します。 アプリは起動しません。
ASP.NET Core モジュールは .NET Core CLR の開始をインプロセスで試みますが、開始に失敗します。 プロセス起動時のエラーの原因は、通常、アプリケーション イベント ログと ASP.NET Core モジュールの stdout ログのエントリから判断できます。
一般的なエラー条件:
- 存在しないバージョンの ASP.NET Core 共有フレームワークが対象にされていて、アプリが正しく構成されていません。 対象のコンピューターにどのバージョンの ASP.NET Core 共有フレームワークがインストールされているかを確認します。
- Azure Key Vault を使用している場合、Key Vault へのアクセス許可がありません。 対象の Key Vault のアクセス ポリシーを確認して、正しいアクセス許可が付与されていることを確実にします。
500.31 ANCM Failed to Find Native Dependencies (500.31 ANCM ネイティブの依存関係を見つけられませんでした)
ワーカー プロセスが失敗します。 アプリは起動しません。
ASP.NET Core モジュールで .NET Core ランタイムの開始がインプロセスで試行されますが、開始に失敗します。 このスタートアップ エラーの最も一般的な原因は、Microsoft.NETCore.App または Microsoft.AspNetCore.App ランタイムがインストールされていない場合です。 アプリが ASP.NET Core 3.0 をターゲットとして展開されていて、そのバージョンがコンピューターに存在しない場合、このエラーが発生します。 エラー メッセージの例は次のとおりです。
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 のバージョンとアプリに必要なバージョンが一覧表示されます。 このエラーを修正するには、次のいずれかを実行します。
- 適切なバージョンの .NET Core をマシンにインストールします。
- マシンに存在する .NET Core のバージョンをターゲットにするようにアプリを変更します。
- アプリを自己完結型の展開として発行します。
開発環境で実行している場合 (ASPNETCORE_ENVIRONMENT 環境変数が Development に設定されている場合)、特定のエラーが HTTP 応答に書き込まれます。 プロセスのスタートアップ エラーの原因は、アプリケーション イベント ログでも見つかります。
500.32 ANCM Failed to Load dll (500.32 ANCM DLL を読み込めませんでした)
ワーカー プロセスが失敗します。 アプリは起動しません。
このエラーの最も一般的な原因は、アプリが互換性のないプロセッサ アーキテクチャ用に発行されていることです。 ワーカー プロセスが 32 ビットアプリとして実行されていて、そのアプリが 64 ビットをターゲットとして発行されている場合、このエラーが発生します。
このエラーを修正するには、次のいずれかを実行します。
- ワーカー プロセスと同じプロセッサ アーキテクチャ用にアプリを再発行します。
- アプリをフレームワークに依存する展開として発行します。
500.33 ANCM Request Handler Load Failure (500.33 ANCM 要求ハンドラーの読み込みエラー)
ワーカー プロセスが失敗します。 アプリは起動しません。
アプリは Microsoft.AspNetCore.App フレームワークを参照していませんでした。 ASP.NET Core モジュールでホストできるのは、Microsoft.AspNetCore.App フレームワークをターゲットとしているアプリのみです。
このエラーを修正するには、アプリが Microsoft.AspNetCore.App フレームワークをターゲットにしていることを確認します。 アプリがターゲットとしているフレームワークを確認するには、.runtimeconfig.json を確認します。
500.34 ANCM Mixed Hosting Models Not Supported (500.34 ANCM 混在ホスティング モデルはサポートされません)
ワーカー プロセスでは、インプロセス アプリとアウト プロセス アプリの両方を同じプロセスで実行できません。
このエラーを修正するには、別の IIS アプリケーション プールでアプリを実行します。
500.35 ANCM Multiple In-Process Applications in same Process (500.35 ANCM 同一プロセス内の複数のインプロセス アプリケーション)
ワーカー プロセスによって、同じプロセスで複数のインプロセス アプリを実行することはできません。
このエラーを修正するには、別の IIS アプリケーション プールでアプリを実行します。
500.36 ANCM Out-Of-Process Handler Load Failure (500.36 ANCM アウト プロセス ハンドラーの読み込みエラー)
アウト プロセス要求ハンドラーの aspnetcorev2_outofprocess.dll が aspnetcorev2.dll ファイルの次にありません。 これは、ASP.NET Core モジュールのインストールが破損していることを示しています。
このエラーを修正するには、.NET Core Hosting Bundle (IIS 用) または Visual Studio (IIS Express 用) のインストールを修復します。
500.37 ANCM Failed to Start Within Startup Time Limit (500.37 ANCM スタートアップ時間の制限内に起動できませんでした)
指定されたスタートアップ時間の制限内に ANCM が起動に失敗しました。 既定では、タイムアウトは 120 秒です。
このエラーは、同じマシン上で多数のアプリを起動したときに発生する可能性があります。 スタートアップ中のサーバー上の CPU/メモリ使用量の急上昇を確認します。 必要に応じて、複数のアプリのスタートアップ プロセスをずらします。
500.38 ANCM アプリケーション DLL が見つかりません
ANCM は、実行可能ファイルの横にあるアプリケーション DLL を見つけることができませんでした。
このエラーは、インプロセス ホスティング モデルを使用して単一ファイルの実行可能ファイルとしてパッケージ化されたアプリをホストするときに発生します。 インプロセス モデルでは、ANCM によって既存の IIS プロセスに .NET Core アプリが読み込まれることが必要です。 このシナリオは、単一ファイル展開モデルではサポートされていません。 このエラーを修正するには、アプリのプロジェクト ファイルで、次のうち 1 つを使用します。
PublishSingleFileMSBuild プロパティをfalseに設定して、単一ファイルの公開を無効にします。AspNetCoreHostingModelMSBuild プロパティをOutOfProcessに設定して、アウトプロセス ホスティング モデルに切り替えます。
502.5 処理エラー
ワーカー プロセスが失敗します。 アプリは起動しません。
ASP.NET Core モジュールはワーカー プロセスの開始を試みますが、開始に失敗します。 プロセス起動時のエラーの原因は、通常、アプリケーション イベント ログと ASP.NET Core モジュールの stdout ログのエントリから判断できます。
一般的なエラー条件は、存在しないバージョンの ASP.NET Core 共有フレームワークが対象にされていて、アプリが正しく構成されていないことです。 対象のコンピューターにどのバージョンの ASP.NET Core 共有フレームワークがインストールされているかを確認します。 共有フレームワークは、コンピューター上にインストールされたアセンブリ ( .dll ファイル) のセットであり、Microsoft.AspNetCore.App などのメタパッケージによって参照されます。 メタパッケージの参照には、必要な最低限のバージョンを指定できます。 詳しくは、共有フレームワークに関するページをご覧ください。
正しく構成されていないホスティングやアプリが原因でワーカー プロセスが失敗する場合、"502.5 処理エラー" のエラー ページが返されます。
アプリケーションの起動に失敗しました (ErrorCode '0x800700c1')
EventID: 1010
Source: IIS AspNetCore Module V2
Failed to start application '/LM/W3SVC/6/ROOT/', ErrorCode '0x800700c1'.
アプリのアセンブリ ( .dll) を読み込めなかったため、アプリの起動に失敗しました。
このエラーは、公開されたアプリと w3wp/iisexpress プロセスの間でビットの不一致がある場合に発生します。
アプリ プールの 32 ビット設定が正しいことを確認してください。
- IIS マネージャーの [アプリケーション プール] でそのアプリ プールを選択します。
- [アクション] パネルの [アプリケーション プールの編集] で [詳細設定] を選択します。
- [32 ビット アプリケーションの有効化] を設定します。
- 32 ビット (x86) アプリを展開する場合は、この値を
Trueに設定します。 - 64 ビット (x64) アプリを展開する場合は、この値を
Falseに設定します。
- 32 ビット (x86) アプリを展開する場合は、この値を
プロジェクト ファイルの <Platform> MSBuild プロパティと公開されたアプリのビット数との間で競合が発生していないことを確認します。
アプリケーションの起動に失敗しました (ErrorCode '0x800701b1')
EventID: 1010
Source: IIS AspNetCore Module V2
Failed to start application '/LM/W3SVC/3/ROOT', ErrorCode '0x800701b1'.
Windows サービスの読み込みに失敗したため、アプリの起動に失敗しました。
有効にする必要がある一般的なサービスの 1 つは、"null 値" サービスです。
次のコマンドは null Windows サービスを有効にします。
sc.exe start null
接続のリセット
ヘッダー送信後にエラーが発生した場合、サーバーが 500 内部サーバー エラーを送信するには遅すぎます。 このような状況は、応答に対する複雑なオブジェクトのシリアル化中にエラーが起きたときによく発生します。 この種のエラーは、クライアントでは "接続リセット" エラーとして表示されます。 この種のエラーのトラブルシューティングには、アプリケーション ログが役に立つことがあります。
既定の起動制限
ASP.NET Core モジュールの startupTimeLimit は、既定では 120 秒に構成されます。 既定値のままにした場合、モジュールで処理エラーが記録されるまでに、アプリは最大で 2 分を起動にかけることができます。 モジュールの構成の詳細については、「AspNetCore 要素の属性」を参照してください。
Azure App Service でのトラブルシューティング
重要
Azure App Service と ASP.NET Core のプレビュー リリース
ASP.NET Core のプレビュー リリースは、既定では Azure App Service に展開されません。 ASP.NET Core プレビュー リリースを使用するアプリをホストするには、「Azure App Service に ASP.NET Core プレビュー リリースを展開する」を参照してください。
Azure App Services ログ ストリーム
Azure App Services ログは、発生したログ情報をストリーミングします。 ストリーミング ログを表示するには、次のようにします。
- Azure portal の [App Services] でアプリを開きます。
- 左側のペインで、[監視]>[App Service ログ] に移動します。
- [Web サーバーのログ記録] の [ファイル システム] を選択します。 必要に応じて、[アプリケーションのログ記録] を有効にします。
- 左側のペインで、[監視]>[ログ ストリーム] に移動し、[アプリケーション ログ] または [Web サーバー ログ] を選択します。
次の画像は、アプリケーション ログの出力を示しています。
ストリーミング ログにはある程度の待機時間があり、すぐには表示されない場合があります。
アプリケーション イベント ログ (Azure App Service)
アプリケーション イベント ログにアクセスするには、Azure portal の [問題の診断と解決] ブレードを使います。
- Azure portal の [App Services] でアプリを開きます。
- [問題の診断と解決] を選択します。
- [診断ツール] という見出しを選択します。
- [サポート ツール] で [アプリケーション イベント] ボタンを選択します。
- [Source](ソース) 列で、IIS AspNetCoreModule または IIS AspNetCoreModule V2 によって提供された最新のエラーを調べます。
[問題の診断と解決] ブレードを使う代わりに、Kudu を使ってアプリケーション イベント ログ ファイルを直接調べることもできます。
- [開発ツール] 領域で [高度なツール] を開きます。 [Go→] ボタンを選択します。 新しいブラウザー タブまたはウィンドウで Kudu コンソールが開きます。
- ページの上部にあるナビゲーション バーを使って [デバッグ コンソール] を開き、 [CMD] を選びます。
- LogFiles フォルダーを開きます。
eventlog.xmlファイルの横にある鉛筆アイコンを選択します。- ログを調べます。 ログの末尾までスクロールし、最新のイベントを確認します。
Kudu コンソールでアプリを実行します。
多くの起動時エラーでは、アプリケーション イベント ログに役に立つ情報が生成されません。 Kudu のリモート実行コンソールでアプリを実行すると、エラーを検出することができます。
- [開発ツール] 領域で [高度なツール] を開きます。 [Go→] ボタンを選択します。 新しいブラウザー タブまたはウィンドウで Kudu コンソールが開きます。
- ページの上部にあるナビゲーション バーを使って [デバッグ コンソール] を開き、 [CMD] を選びます。
32 ビット (x86) アプリをテストする
現在のリリース
cd d:\home\site\wwwroot- アプリを実行します:
アプリがフレームワークに依存する展開の場合:
dotnet .\{ASSEMBLY NAME}.dllアプリが自己完結型の展開の場合:
{ASSEMBLY NAME}.exe
エラーを示すアプリからのコンソール出力はすべて、Kudu コンソールにパイプされます。
プレビュー リリース上で実行されているフレームワークに依存するデプロイ
"ASP.NET Core {バージョン} (x86) ランタイムのサイト拡張機能をインストールする必要があります。 "
cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x32({X.Y}はランタイム バージョンです)- アプリを実行します:
dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll
エラーを示すアプリからのコンソール出力はすべて、Kudu コンソールにパイプされます。
64 ビット (x64) アプリをテストする
現在のリリース
- アプリが 64 ビット (x64) のフレームワークに依存する展開の場合:
cd D:\Program Files\dotnet- アプリを実行します:
dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll
- アプリが自己完結型の展開の場合:
cd D:\home\site\wwwroot- アプリを実行します:
{ASSEMBLY NAME}.exe
エラーを示すアプリからのコンソール出力はすべて、Kudu コンソールにパイプされます。
プレビュー リリース上で実行されているフレームワークに依存するデプロイ
"ASP.NET Core {バージョン} (x64) ランタイムのサイト拡張機能をインストールする必要があります。 "
cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x64({X.Y}はランタイム バージョンです)- アプリを実行します:
dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll
エラーを示すアプリからのコンソール出力はすべて、Kudu コンソールにパイプされます。
ASP.NET Core モジュールの stdout ログ (Azure App Service)
警告
stdout ログを無効にしないと、アプリまたはサーバーで障害が発生する可能性があります。 ログ ファイルのサイズまたは作成されるログ ファイルの数に制限はありません。 stdout ログは、アプリ起動時の問題のトラブルシューティングにのみ使ってください。
起動後の ASP.NET Core アプリでの一般的なログの場合は、ログ ファイルのサイズを制限し、ログをローテーションするログ ライブラリを使います。 詳細については、「サードパーティ製のログ プロバイダー」を参照してください。
ASP.NET Core モジュールの stdout には、アプリケーション イベント ログでは見つからない有用なエラー メッセージが記録されることがよくあります。 stdout ログを有効にして表示するには:
- Azure portal で Web アプリに移動します。
- [App Service] ブレードで、検索ボックスに「kudu」と入力します。
- [高度なツール]>[Go] の順に選択します。
- [デバッグ コンソール] > [CMD] の順に選択します。
- site/wwwroot に移動します
- 鉛筆アイコンを選択し、web.config ファイルを編集します。
<aspNetCore />要素でstdoutLogEnabled="true"を設定し、 [保存] を選択します。
トラブルシューティングが完了したら、stdoutLogEnabled="false" を設定して stdout ログを無効にします。
詳細については、IIS の ASP.NET Core モジュール (ANCM) に関するページを参照してください。
ASP.NET Core モジュールのデバッグ ログ (Azure App Service)
ASP.NET Core モジュール デバッグ ログでは、ASP.NET Core モジュールのさらに詳しいログが提供されます。 stdout ログを有効にして表示するには:
- 強化された診断ログを有効にするには、次のいずれかを実行します。
- 「強化された診断ログ」の指示に従い、強化された診断ログをアプリに対して設定します。 アプリを再デプロイします。
- Kudu コンソールを利用し、「
<handlerSettings>強化された診断ログ」にある をライブ アプリの web.config ファイルに追加します。- [開発ツール] 領域で [高度なツール] を開きます。 [Go→] ボタンを選択します。 新しいブラウザー タブまたはウィンドウで Kudu コンソールが開きます。
- ページの上部にあるナビゲーション バーを使って [デバッグ コンソール] を開き、 [CMD] を選びます。
- パス site>wwwroot へのフォルダーを開きます。 鉛筆アイコンを選択し、web.config ファイルを編集します。 「強化された診断ログ」にある
<handlerSettings>セクションを追加します。 [保存] ボタンを選択します。
- [開発ツール] 領域で [高度なツール] を開きます。 [Go→] ボタンを選択します。 新しいブラウザー タブまたはウィンドウで Kudu コンソールが開きます。
- ページの上部にあるナビゲーション バーを使って [デバッグ コンソール] を開き、 [CMD] を選びます。
- パス site>wwwroot へのフォルダーを開きます。 aspnetcore-debug.log ファイルにパスを指定しなかった場合、ファイルが一覧に表示されます。 パスを指定した場合、ログ ファイルの場所に移動します。
- ファイル名の隣にある鉛筆アイコンでログ ファイルを開きます。
トラブルシューティングが完了したら、debug ログを無効にします。
強化されたデバッグ ログを無効にするには、次のいずれかを実行します。
- ローカルの web.config ファイルから
<handlerSettings>を削除し、アプリを再デプロイします。 - Kudu コンソールを使用して web.config ファイルを編集し、
<handlerSettings>セクションを削除します。 ファイルを保存します。
詳細については、ASP.NET Core モジュールを使用したログの作成とリダイレクトに関する記事を参照してください。
警告
debug ログを無効にしないと、アプリまたはサーバーで障害が発生する可能性があります。 ログ ファイルのサイズに制限はありません。 debug ログは、アプリ起動時の問題のトラブルシューティングにのみ使ってください。
起動後の ASP.NET Core アプリでの一般的なログの場合は、ログ ファイルのサイズを制限し、ログをローテーションするログ ライブラリを使います。 詳細については、「サードパーティ製のログ プロバイダー」を参照してください。
遅いアプリまたはハングしているアプリ (Azure App Service)
要求に対してアプリの応答が遅いとき、またはアプリがハングするときは、「Azure App Service での Web アプリのパフォーマンス低下に関する問題のトラブルシューティング」をご覧ください。
監視ブレード
監視ブレードでは、このトピックでこれまでに説明した方法に代わるトラブルシューティング エクスペリエンスが提供されます。 これらのブレードは、500 番台のエラーの診断に使用できます。
ASP.NET Core 拡張機能がインストールされていることを確認してください。 拡張機能がインストールされていない場合は、手動でインストールします。
- [開発ツール] ブレード セクションで、 [拡張機能] ブレードを選びます。
- [ASP.NET Core Extensions](ASP.NET Core 拡張機能) が一覧に表示されます。
- 拡張機能がインストールされていない場合は、 [追加] ボタンを選びます。
- 一覧から [ASP.NET Core Extensions](ASP.NET Core 拡張機能) を選びます。
- [OK] を選んで法的条項に同意します。
- [拡張機能の追加] ブレードで [OK] を選びます。
- 拡張機能が正常にインストールされると、情報ポップアップ メッセージで通知されます。
stdout ログが有効になっていない場合は、次の手順のようにします。
- Azure portal の [開発ツール] 領域で [高度なツール] ブレードを選びます。 [Go→] ボタンを選択します。 新しいブラウザー タブまたはウィンドウで Kudu コンソールが開きます。
- ページの上部にあるナビゲーション バーを使って [デバッグ コンソール] を開き、 [CMD] を選びます。
- パス site>wwwroot へのフォルダーを開き、下にスクロールして、一覧の最後にある web.config ファイルを表示します。
- web.config ファイルの隣の鉛筆アイコンをクリックします。
- stdoutLogEnabled を
trueに設定し、stdoutLogFile パスを\\?\%home%\LogFiles\stdoutに変更します。 - [保存] を選んで、更新した web.config ファイルを保存します。
続けて診断ログをアクティブにします。
- Azure portal で [診断ログ] ブレードを選びます。
- [アプリケーション ログ (ファイル システム)] および [詳細なエラー メッセージ] の [オン] スイッチを選びます。 ブレードの上部にある [保存] ボタンを選びます。
- 失敗した要求イベントのバッファ処理 (FREB) とも呼ばれる失敗した要求のトレースを含めるには、 [失敗した要求のトレース] で [オン] スイッチを選びます。
- ポータルで [診断ログ] ブレードのすぐ下にある [ログ ストリーム] ブレードを選びます。
- アプリに対して要求します。
- ログ ストリーム データ内で、エラーの原因が示されます。
トラブルシューティングが完了したら、stdout ログを無効にしてください。
失敗した要求のトレース ログ (FREB ログ) を見るには:
- Azure portal で [問題の診断と解決] ブレードに移動します。
- サイド バーの [SUPPORT TOOLS](サポート ツール) 領域で、 [Failed Request Tracing Logs](失敗した要求のトレース ログ) を選びます。
詳しくは、「Azure App Service の Web アプリの診断ログの有効化」トピックの「失敗した要求トレース」セクションおよび「Azure での Web アプリのアプリケーション パフォーマンスに関するよくあるご質問」の「失敗した要求トレースをオンにするにはどうすればよいですか?」をご覧ください。
詳しくは、「Azure App Service の Web アプリの診断ログの有効化」をご覧ください。
警告
stdout ログを無効にしないと、アプリまたはサーバーで障害が発生する可能性があります。 ログ ファイルのサイズまたは作成されるログ ファイルの数に制限はありません。
ASP.NET Core アプリでのルーチン ログの場合は、ログ ファイルのサイズを制限し、ログをローテーションするログ ライブラリを使います。 詳細については、「サードパーティ製のログ プロバイダー」を参照してください。
IIS でのトラブルシューティング
アプリケーション イベント ログ (IIS)
アプリケーション イベント ログにアクセスします。
- [スタート] メニューを開き、イベント ビューアーを検索し、イベント ビューアー アプリを選択します。
- イベント ビューアーで [Windows ログ] ノードを開きます。
- [Application] を選択して、アプリケーション イベント ログを開きます。
- 失敗したアプリに関連するエラーを検索します。 エラーの [ソース] 列には IIS AspNetCore Module または IIS Express AspNetCore Module の値が表示されます。
コマンド プロンプトでアプリを実行する
多くの起動時エラーでは、アプリケーション イベント ログに役に立つ情報が生成されません。 ホスティング システムのコマンド プロンプトでアプリを実行すると、エラーの原因がわかることがあります。
フレームワークに依存する展開
アプリがフレームワークに依存する展開の場合:
- コマンド プロンプトで展開フォルダーに移動し、dotnet.exe 使用してアプリのアセンブリを実行して、アプリを実行します。
dotnet .\<assembly_name>.dllコマンドの <assembly_name> を、アプリのアセンブリの名前に置き換えます。 - エラーを示すアプリからのコンソール出力は、すべてコンソール ウィンドウに書き込まれます。
- アプリへの要求時にエラーが発生した場合は、Kestrel がリッスンしているホストとポートに要求が送信されます。 既定のホストと post を使用して
http://localhost:5000/に要求を行います。 アプリが Kestrel のエンドポイント アドレスで正常に応答する場合、問題はホスティングの構成に関連している可能性が高く、アプリ内が原因の可能性は低くなります。
自己完結型の展開
アプリが自己完結型の展開の場合:
- コマンド プロンプトで、展開フォルダーに移動し、アプリの実行可能ファイルを実行します。
<assembly_name>.exeコマンドの <assembly_name> を、アプリのアセンブリの名前に置き換えます。 - エラーを示すアプリからのコンソール出力は、すべてコンソール ウィンドウに書き込まれます。
- アプリへの要求時にエラーが発生した場合は、Kestrel がリッスンしているホストとポートに要求が送信されます。 既定のホストと post を使用して
http://localhost:5000/に要求を行います。 アプリが Kestrel のエンドポイント アドレスで正常に応答する場合、問題はホスティングの構成に関連している可能性が高く、アプリ内が原因の可能性は低くなります。
ASP.NET Core モジュールの stdout ログ (IIS)
stdout ログを有効にして表示するには:
- ホスティング システム上のサイトの展開フォルダーに移動します。
- logs フォルダーが存在しない場合は、フォルダーを作成します。 MSBuild で展開フォルダーに logs フォルダーを自動的に作成されるようにする手順については、「ディレクトリ構造」のトピックを参照してください。
- web.config ファイルを編集します。 stdoutLogEnabled を
trueに設定し、stdoutLogFile のパスを logs フォルダー (たとえば.\logs\stdout) を指すように変更します。 パスのstdoutはログ ファイル名のプレフィックスです。 ログ ファイルの作成時には、タイムスタンプ、プロセス ID、およびファイルの拡張子が自動的に追加されます。 ファイル名のプレフィックスとしてstdoutを使用すると、一般的なログ ファイルの名前は stdout_20180205184032_5412.log になります。 - アプリケーション プールの ID に logs フォルダーへの書き込みアクセス許可があることを確認します。
- 更新した web.config ファイルを保存します。
- アプリに対して要求します。
- logs フォルダーに移動します。 最新の stdout ログを探して開きます。
- ログのエラーを調べます。
トラブルシューティングが完了したら、stdout ログを無効にします。
- web.config ファイルを編集します。
- stdoutLogEnabled を
falseに設定します。 - ファイルを保存します。
詳細については、IIS の ASP.NET Core モジュール (ANCM) に関するページを参照してください。
警告
stdout ログを無効にしないと、アプリまたはサーバーで障害が発生する可能性があります。 ログ ファイルのサイズまたは作成されるログ ファイルの数に制限はありません。
ASP.NET Core アプリでのルーチン ログの場合は、ログ ファイルのサイズを制限し、ログをローテーションするログ ライブラリを使います。 詳細については、「サードパーティ製のログ プロバイダー」を参照してください。
ASP.NET Core モジュールのデバッグ ログ (IIS)
ASP.NET Core モジュールのデバッグ ログを有効にするには、次のハンドラー設定をアプリの web.config ファイルに追加します。
<aspNetCore ...>
<handlerSettings>
<handlerSetting name="debugLevel" value="file" />
<handlerSetting name="debugFile" value="c:\temp\ancm.log" />
</handlerSettings>
</aspNetCore>
ログに指定されたパスが存在することと、アプリ プールの ID にその場所への書き込みアクセス許可があることを確認します。
詳細については、ASP.NET Core モジュールを使用したログの作成とリダイレクトに関する記事を参照してください。
開発者例外ページを有効にする
開発環境でアプリを実行するには、ASPNETCORE_ENVIRONMENT環境変数を web.config に追加することができます。 アプリの起動時にホスト ビルダー上で UseEnvironment によって環境がオーバーライドされない限り、環境変数を設定すると、アプリの実行時に開発者例外ページが表示されます。
<aspNetCore processPath="dotnet"
arguments=".\MyApp.dll"
stdoutLogEnabled="false"
stdoutLogFile=".\logs\stdout"
hostingModel="InProcess">
<environmentVariables>
<environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Development" />
</environmentVariables>
</aspNetCore>
ASPNETCORE_ENVIRONMENT の環境変数を設定する方法は、インターネットに公開されないステージング サーバーやテスト用サーバーの場合にのみお勧めされます。 トラブルシューティング後は、必ず web.config ファイルからこの環境変数を削除してください。 web.config で環境変数を設定する方法の詳細については、aspNetCore の environmentVariables 子要素を参照してください。
アプリからデータを取得する
アプリが要求に応答できる場合は、ターミナル インライン ミドルウェアを使用して、要求、接続、その他のデータをアプリから取得します。 詳細とサンプル コードについては、「ASP.NET Core プロジェクトのトラブルシューティングとデバッグ」を参照してください。
遅いアプリまたはハングしているアプリ (IIS)
"クラッシュ ダンプ" とはシステムのメモリのスナップショットであり、アプリのクラッシュ、起動の失敗、遅いアプリの原因を突き止めるのに役立ちます。
アプリのクラッシュまたは例外の発生
Windows エラー報告 (WER) からダンプを取得して分析します。
c:\dumpsにクラッシュ ダンプ ファイルを保持するフォルダーを作成します。 アプリ プールには、そのフォルダーへの書き込みアクセス権が必要です。EnableDumps PowerShell スクリプト を実行します。
アプリでインプロセス ホスティング モデルが使われている場合は、w3wp.exe に対するスクリプトを実行します。
.\EnableDumps w3wp.exe c:\dumpsアプリでアウト プロセス ホスティング モデルが使われている場合は、dotnet.exe に対するスクリプトを実行します。
.\EnableDumps dotnet.exe c:\dumps
クラッシュが発生する条件の下でアプリを実行します。
クラッシュが発生した後、DisableDumps PowerShell スクリプトを実行します。
アプリでインプロセス ホスティング モデルが使われている場合は、w3wp.exe に対するスクリプトを実行します。
.\DisableDumps w3wp.exeアプリでアウト プロセス ホスティング モデルが使われている場合は、dotnet.exe に対するスクリプトを実行します。
.\DisableDumps dotnet.exe
アプリがクラッシュし、ダンプの収集が完了したら、アプリを普通に終了してかまいません。 PowerShell スクリプトにより、アプリごとに最大 5 つのダンプを収集する WER が構成されます。
警告
クラッシュ ダンプでは、大量のディスク領域 (1 つにつき最大、数ギガバイト) が使用される場合があります。
アプリが起動時または正常な実行中にハングまたは失敗する
アプリが起動時または正常な実行中に "ハング" (応答を停止するがクラッシュしない) または失敗するときは、「User-Mode Dump Files:Choosing the Best Tool」(ユーザー モード ダンプ ファイル: 最適なツールの選択) を参照し、適切なツールを選択してダンプを生成します。
ダンプを分析する
ダンプはいくつかの方法で分析できます。 詳細については、「Analyzing a User-Mode Dump File」(ユーザー モード ダンプ ファイルの分析) を参照してください。
パッケージ キャッシュをクリアする
開発マシンで .NET Core SDK をアップグレードしたり、アプリ内のパッケージ バージョンを変更したりした直後に、機能しているアプリが失敗することがあります。 場合によっては、パッケージに統一性がないと、メジャー アップグレード実行時にアプリが破壊されることがあります。 これらの問題のほとんどは、次の手順で解決できます。
bin フォルダーと obj フォルダーを削除します。
コマンド シェルから dotnet nuget locals all --clear を実行して、パッケージ キャッシュをクリアします。
パッケージ キャッシュをクリアするには、nuget.exe ツールを使用して
nuget locals all -clearコマンドを実行する方法もあります。 nuget.exe は、Windows デスクトップ オペレーティング システムにバンドルされているインストールではなく、NuGet Web サイトから別に入手する必要があります。プロジェクトを復元してリビルドします。
アプリを再展開する前に、サーバー上の展開フォルダー内のすべてのファイルを削除します。
状態コードとログ エントリを収集する
IIS で実行されている ASP.NET Core アプリでエラーが発生した場合は、情報を収集し問題の診断に役立てます。 次の情報は、トラブルシューティングに役立ちます。次の情報を収集します。
- ブラウザーの動作 (状態コードやエラー メッセージなど)。
- アプリケーション イベント ログのエントリ
- Azure App Service: 「Azure App Service および IIS での ASP.NET Core のトラブルシューティング」を参照してください。
- IIS
- [Windows] メニューで [スタート] を選択し、「Event Viewer」と入力し、Enter を押します。
- イベント ビューアーが開いたら、サイドバーで [Windows ログ]、[アプリケーション] の順に展開します。
- ASP.NET Core モジュールの stdout ログ エントリと debug ログ エントリ
- Azure App Service: 「Azure App Service および IIS での ASP.NET Core のトラブルシューティング」を参照してください。
- IIS:ASP.NET Core モジュール トピックの「ログの作成とリダイレクト」と「強化された診断ログ」のセクションの指示に従います。
エラー情報を次の一般的なエラーと比較します。 一致が見つかった場合は、トラブルシューティングのアドバイスに従います。
このトピックではすべてのエラーを網羅しているわけではありません。 ここに記載されていないエラーに遭遇した場合、このトピックの一番下にある [コンテンツ フィードバック] ボタンで新しい問題を登録してください。その際、エラーを再現する方法を詳しく教えてください。
重要
Azure App Service と ASP.NET Core のプレビュー リリース
ASP.NET Core のプレビュー リリースは、既定では Azure App Service に展開されません。 ASP.NET Core プレビュー リリースを使用するアプリをホストするには、「Azure App Service に ASP.NET Core プレビュー リリースを展開する」を参照してください。
OS のアップグレードによって 32 ビット ASP.NET Core モジュールが削除された
アプリケーション ログ: モジュール DLL C:\WINDOWS\system32\inetsrv\aspnetcore.dll を読み込めませんでした。 このデータはエラーです。
トラブルシューティング:
C:\Windows\SysWOW64\inetsrv ディレクトリにある OS ファイルでないファイルは、OS アップグレード時に保持されません。 OS アップグレードより前に ASP.NET Core モジュールをインストールしていた場合、OS アップグレード後に 32 ビット モードでアプリ プールを実行しようとすると、この問題が発生します。 OS アップグレード後に ASP.NET Core モジュールを修復してください。 「.NET Core ホスティング バンドルのインストール」をご覧ください。 インストーラーを実行するときに [修復] を選択します。
サイト拡張機能の不足、32 ビット (x86) および 64 ビット (x64) サイト拡張機能がインストールされている、または間違ったプロセス ビットが設定されている
"Azure App Services でホストしているアプリに適用されます。 "
ブラウザー: HTTP エラー 500.0 - ANCM インプロセス ハンドラーの読み込みエラー
アプリケーション ログ: hostfxr を呼び出し、インプロセス要求ハンドラーを見つけようとすると、ネイティブの依存関係が見つからず、失敗しました。 インプロセス要求ハンドラーが見つかりませんでした。 hostfxr の呼び出し時にキャプチャされた出力:互換性のあるフレームワーク バージョンが見つかりませんでした。 指定したフレームワーク 'Microsoft.AspNetCore.App'、バージョン '{VERSION}-preview-*' が見つかりませんでした。 アプリケーション '/LM/W3SVC/1416782824/ROOT' を起動できませんでした、エラー コード '0x8000ffff'。
ASP.NET Core モジュールの stdout ログ: 互換性のあるフレームワーク バージョンが見つかりませんでした。 指定したフレームワーク 'Microsoft.AspNetCore.App'、バージョン '{VERSION}-preview-*' が見つかりませんでした。
ASP.NET Core モジュール デバッグ ログ: hostfxr を呼び出し、インプロセス要求ハンドラーを見つけようとすると、ネイティブの依存関係が見つからず、失敗しました。 これが意味するところは、ほとんどの場合、アプリが正しく設定されていないということです。アプリケーションの対象であり、コンピューターにインストールされている Microsoft.NetCore.App と Microsoft.AspNetCore.App のバージョンを確認してください。 HRESULT が失敗し、次が返されました:0x8000ffff。 インプロセス要求ハンドラーが見つかりませんでした。 互換性のあるフレームワーク バージョンが見つかりませんでした。 指定したフレームワーク 'Microsoft.AspNetCore.App'、バージョン '{VERSION}-preview-*' が見つかりませんでした。
トラブルシューティング:
プレビュー ランタイムでアプリを実行している場合、アプリのビットとアプリのランタイム バージョンに一致する、32 ビット (x86) または 64 ビット (x64) のいずれかのサイト拡張機能をインストールします。 両方の拡張機能や、拡張機能の複数のランタイム バージョンをインストールしないでください。
- ASP.NET Core {ランタイム バージョン} (x86) ランタイム
- ASP.NET Core {ランタイム バージョン} (x64) ランタイム
アプリを再起動します。 アプリが再起動するまで数秒待ちます。
プレビュー ランタイムでアプリを実行していて、32 ビット (x86)、64 ビット (x64) 両方のサイト拡張機能がインストールされている場合、アプリのビットと一致しないサイト拡張機能をアンインストールします。 サイト拡張機能を削除した後、アプリを再起動します。 アプリが再起動するまで数秒待ちます。
プレビュー ランタイムでアプリを実行していて、サイト拡張機能とアプリのビットが一致している場合、プレビュー サイト拡張機能の "ランタイム バージョン" がアプリのランタイム バージョンと一致していることを確認します。
[アプリケーション設定] のアプリの [プラットフォーム] がアプリのビットと一致していることを確認します。
詳細については、「Azure App Service に ASP.NET Core アプリを展開する」を参照してください。
x86 アプリが展開されますが、32 ビット アプリに対してアプリ プールは有効になりません。
ブラウザー: HTTP エラー 500.30 - ANCM インプロセス起動失敗
アプリケーション ログ: 物理ルートが '{PATH}' のアプリケーション '/LM/W3SVC/5/ROOT' に予想外のマネージド例外が発生しました、例外コード = '0xe0434352'。 詳細については、stderr ログを確認してください。 物理ルートが '{PATH}' のアプリケーション '/LM/W3SVC/5/ROOT' で clr とマネージド アプリケーションを読み込めませんでした。 CLR ワーカー スレッドが途中で終了しました
ASP.NET Core モジュールの stdout ログ: ログ ファイルが作成されましたが、空です。
ASP.NET Core モジュール デバッグ ログ: HRESULT が失敗し、次が返されました:0x8007023e
このシナリオは、自己完結型アプリの公開時、SDK によってトラップされます。 RID がプラットフォーム ターゲットに一致しない場合 (win10-x64 RID とプロジェクト ファイルの <PlatformTarget>x86</PlatformTarget> など)、SDK からエラーが生成されます。
トラブルシューティング:
x86 フレームワークに依存する展開の場合 (<PlatformTarget>x86</PlatformTarget>)、32 ビット アプリに対して IIS アプリ プールを有効にします。 IIS Manager でアプリ プールの [詳細設定] を開き、 [32 ビット アプリケーションの有効化] を [True] に設定します。
プラットフォームが RID と競合している
ブラウザー: HTTP エラー 502.5 - 処理エラー
アプリケーション ログ: 物理ルートが 'C:{PATH}' のアプリケーション 'MACHINE/WEBROOT/APPHOST/{ASSEMBLY}' は、コマンドライン '"C:{PATH}{ASSEMBLY}.{exe|dll}" ' でプロセスを開始できませんでした。ErrorCode = '0x80004005 : ff。
ASP.NET Core モジュールの stdout ログ: 未処理の例外:System.BadImageFormatException:ファイルまたはアセンブリ '{ASSEMBLY}.dll' を読み込めませんでした。 正しくない形式のプログラムを読み込もうとしました。
トラブルシューティング:
Kestrel でアプリをローカルに実行できることを確認します。 プロセスのエラーは、アプリ内の問題の結果である可能性があります。 詳細については、「Azure App Service および IIS での ASP.NET Core のトラブルシューティング」を参照してください。
Azure Apps 展開で、アプリケーションをアップグレードして新しいアセンブリを展開しようとしたときにこの例外が発生した場合は、以前の展開からすべてのファイルを手動で削除してください。 アップグレードしたアプリを展開するとき、互換性のないアセンブリが残っていると、
System.BadImageFormatException例外が発生します。
URI のエンドポイントが間違っているか、Web サイトが停止している
ブラウザー: ERR_CONNECTION_REFUSED --または-- 接続できません
アプリケーション ログ: エントリなし
ASP.NET Core モジュールの stdout ログ: ログ ファイルが作成されていません。
ASP.NET Core モジュール デバッグ ログ: ログ ファイルが作成されていません。
トラブルシューティング:
アプリに対して正しい URI エンドポイントが使用されていることを確認します。 バインドを確認します。
IIS Web サイトが [停止] 状態でないことを確認します。
CoreWebEngine または W3SVC サーバー機能が無効
OS の例外: ASP.NET Core モジュールを使用するには、IIS 7.0 CoreWebEngine および W3SVC の機能をインストールする必要があります。
トラブルシューティング:
適切な役割と機能が有効になっていることを確認します。 「IIS 構成」を参照してください。
Web サイト物理パスが間違っているか、アプリが見つからない
ブラウザー: 403 許可されていません - アクセスが拒否されました --または-- 403.14 許可されていません - Web サーバーは、このディレクトリの内容の一覧を表示しないように構成されています。
アプリケーション ログ: エントリなし
ASP.NET Core モジュールの stdout ログ: ログ ファイルが作成されていません。
ASP.NET Core モジュール デバッグ ログ: ログ ファイルが作成されていません。
トラブルシューティング:
IIS Web サイトの基本設定と物理アプリのフォルダーを確認します。 アプリが IIS Web サイトの物理パスにあるフォルダー内に配置されていることを確認します。
役割が正しくない、ASP.NET Core モジュールがインストールされていない、または不適切なアクセス許可
ブラウザー: 500.19 内部サーバー エラー - ページに関連する構成データが無効であるため、要求されたページにアクセスできません。 --または-- このページを表示できません
アプリケーション ログ: エントリなし
ASP.NET Core モジュールの stdout ログ: ログ ファイルが作成されていません。
ASP.NET Core モジュール デバッグ ログ: ログ ファイルが作成されていません。
トラブルシューティング:
適切な役割が有効になっていることを確認します。 「IIS 構成」を参照してください。
[プログラムと機能] または [アプリと機能] を開き、[Windows Server Hosting] がインストールされていることを確認します。 インストールされているプログラムの一覧に [Windows Server Hosting] がない場合、.NET Core ホスティング バンドルをダウンロードしてインストールします。
現在の .NET Core ホスティング バンドルのインストーラー (直接ダウンロード)
詳細については、「.NET Core ホスティング バンドルのインストール」をご覧ください。
[アプリケーション プール]>[プロセス モデル]>Identity が ApplicationPoolIdentity に設定されていることを確認します。または、カスタム ID に、アプリの展開フォルダーにアクセスするための正しいアクセス許可があることを確認します。
ASP.NET Core ホスティング バンドルをアンインストールし、以前のバージョンのホスティング バンドルをインストールした場合、applicationHost.config ファイルには ASP.NET Core モジュールのセクションが含まれません。 applicationHost.config で %windir%/System32/inetsrv/config を開き、
<configuration><configSections><sectionGroup name="system.webServer">セクション グループを見つけます。 セクション グループに ASP.NET Core モジュールのセクションがない場合は、セクション要素を追加します。<section name="aspNetCore" overrideModeDefault="Allow" />または、ASP.NET Core ホスティング バンドルの最新バージョンをインストールします。 最新バージョンは、ポートされている ASP.NET Core アプリと下位互換性があります。
processPath の誤り、PATH 変数の欠如、ホスティング バンドルが未インストール、システムまたは IIS が再起動されていない、VC++ 再頒布可能パッケージが未インストール、dotnet.exe アクセス違反
ブラウザー: HTTP エラー 500.0 - ANCM インプロセス ハンドラーの読み込みエラー
アプリケーション ログ: 物理ルートが 'C:{PATH}' のアプリケーション 'MACHINE/WEBROOT/APPHOST/{ASSEMBLY}' は、コマンドライン '"{...}" ' でプロセスを開始できませんでした。ErrorCode = '0x80070002 : 0。 アプリケーション '{PATH}' は開始できませんでした。 実行可能ファイルが '{PATH}' で見つかりませんでした。 アプリケーション '/LM/W3SVC/2/ROOT' を起動できませんでした、エラー コード '0x8007023e'。
ASP.NET Core モジュールの stdout ログ: ログ ファイルが作成されていません。
ASP.NET Core モジュール デバッグ ログ: イベント ログ:'アプリケーション '{PATH}' を起動できませんでした。 実行可能ファイルが '{PATH}' で見つかりませんでした。 HRESULT が失敗し、次が返されました:0x8007023e
トラブルシューティング:
Kestrel でアプリをローカルに実行できることを確認します。 プロセスのエラーは、アプリ内の問題の結果である可能性があります。 詳細については、「Azure App Service および IIS での ASP.NET Core のトラブルシューティング」を参照してください。
web.config で
<aspNetCore>要素の processPath 属性を調べ、フレームワークに依存する展開 (FDD) の場合はそれがdotnetであること、自己完結型展開 (SCD) の場合はそれが.\{ASSEMBLY}.exeであることを確認します。FDD の場合、PATH 設定で dotnet.exe にアクセスできていない可能性があります。 C:\Program Files\dotnet がシステムの PATH 設定に含まれていることを確認します。
FDD では、アプリ プールのユーザー ID で dotnet.exe にアクセスできていない可能性があります。 アプリ プール ユーザー ID に、C:\Program Files\dotnet ディレクトリへのアクセス許可が設定されていることを確認します。 C:\Program Files\dotnet とアプリのディレクトリに、アプリ プール ユーザー ID に対する拒否ルールが構成されていないことを確認します。
FDD を配置し、IIS を再起動せずに .NET Core をインストールした可能性があります。 サーバーを再起動するか、コマンド プロンプトから net stop was /y に続けて net start w3svc を実行して IIS を再起動します。
ホスト システムで、 .NET Core ランタイムをインストールせずに、FDD を配置した可能性があります。 .NET Core ランタイムがインストールされていない場合は、システムで .NET Core ホスティング バンドルのインストーラーを実行します。
現在の .NET Core ホスティング バンドルのインストーラー (直接ダウンロード)
詳細については、「.NET Core ホスティング バンドルのインストール」をご覧ください。
特定のランタイムが必要な場合、.NET ダウンロードのページからランタイムをダウンロードし、システムにインストールしてください。 インストールを完了するために、システムを再起動するか、コマンド プロンプトから net stop was /y に続けて net start w3svc を実行して IIS を再起動します。
<aspNetCore> 要素の引数の誤り
ブラウザー: HTTP エラー 500.0 - ANCM インプロセス ハンドラーの読み込みエラー
アプリケーション ログ: hostfxr を呼び出し、インプロセス要求ハンドラーを見つけようとすると、ネイティブの依存関係が見つからず、失敗しました。 これが意味するところは、ほとんどの場合、アプリが正しく設定されていないということです。アプリケーションの対象であり、コンピューターにインストールされている Microsoft.NetCore.App と Microsoft.AspNetCore.App のバージョンを確認してください。 インプロセス要求ハンドラーが見つかりませんでした。 hostfxr の呼び出し時にキャプチャされた出力:dotnet SDK コマンドを実行しますか? dotnet SDK を https://go.microsoft.com/fwlink/?LinkID=798306&clcid=0x409 からインストールしてください。アプリケーション '/LM/W3SVC/3/ROOT' を起動できませんでした。ErrorCode '0x8000ffff'。
ASP.NET Core モジュールの stdout ログ: dotnet SDK コマンドを実行しますか? dotnet SDK を https://go.microsoft.com/fwlink/?LinkID=798306&clcid=0x409 からインストールしてください
ASP.NET Core モジュール デバッグ ログ: hostfxr を呼び出し、インプロセス要求ハンドラーを見つけようとすると、ネイティブの依存関係が見つからず、失敗しました。 これが意味するところは、ほとんどの場合、アプリが正しく設定されていないということです。アプリケーションの対象であり、コンピューターにインストールされている Microsoft.NetCore.App と Microsoft.AspNetCore.App のバージョンを確認してください。 HRESULT が失敗し、次が返されました:0x8000ffff インプロセス要求ハンドラーが見つかりませんでした。 hostfxr の呼び出し時にキャプチャされた出力:dotnet SDK コマンドを実行しますか? dotnet SDK を https://go.microsoft.com/fwlink/?LinkID=798306&clcid=0x409 からインストールしてください。HRESULT が失敗し、次が返されました: 0x8000ffff
トラブルシューティング:
Kestrel でアプリをローカルに実行できることを確認します。 プロセスのエラーは、アプリ内の問題の結果である可能性があります。 詳細については、「Azure App Service および IIS での ASP.NET Core のトラブルシューティング」を参照してください。
web.config で
<aspNetCore>要素の arguments 属性を調べ、次のいずれかになっていることを確認します。(a) フレームワークに依存する展開 (FDD) の場合は.\{ASSEMBLY}.dll、または (b) 自己完結型の展開 (SCD) の場合は、未指定の空の文字列 (arguments="") か、アプリの引数のリスト (arguments="{ARGUMENT_1}, {ARGUMENT_2}, ... {ARGUMENT_X}")。
.NET Core 共有フレームワークがありません
ブラウザー: HTTP エラー 500.0 - ANCM インプロセス ハンドラーの読み込みエラー
アプリケーション ログ: hostfxr を呼び出し、インプロセス要求ハンドラーを見つけようとすると、ネイティブの依存関係が見つからず、失敗しました。 これが意味するところは、ほとんどの場合、アプリが正しく設定されていないということです。アプリケーションの対象であり、コンピューターにインストールされている Microsoft.NetCore.App と Microsoft.AspNetCore.App のバージョンを確認してください。 インプロセス要求ハンドラーが見つかりませんでした。 hostfxr の呼び出し時にキャプチャされた出力:互換性のあるフレームワーク バージョンが見つかりませんでした。 指定のフレームワーク 'Microsoft.AspNetCore.App', version '{VERSION}' が見つかりませんでした。
アプリケーション '/LM/W3SVC/5/ROOT' を起動できませんでした、エラー コード '0x8000ffff'。
ASP.NET Core モジュールの stdout ログ: 互換性のあるフレームワーク バージョンが見つかりませんでした。 指定のフレームワーク 'Microsoft.AspNetCore.App', version '{VERSION}' が見つかりませんでした。
ASP.NET Core モジュール デバッグ ログ: HRESULT が失敗し、次が返されました:0x8000ffff
トラブルシューティング:
フレームワークに依存する展開 (FDD) では、正しいランタイムがシステムにインストールされていることを確認します。
アプリケーション プールの停止
ブラウザー: 503 サービスをご利用いただけません
アプリケーション ログ: エントリなし
ASP.NET Core モジュールの stdout ログ: ログ ファイルが作成されていません。
ASP.NET Core モジュール デバッグ ログ: ログ ファイルが作成されていません。
トラブルシューティング:
アプリケーション プールが [停止] 状態でないことを確認します。
サブアプリケーションに <handlers> セクションが含まれている
ブラウザー: HTTP エラー 500.19 - 内部サーバー エラー
アプリケーション ログ: エントリなし
ASP.NET Core モジュールの stdout ログ: ルート アプリのログ ファイルが作成され、通常の操作を示しています。 サブアプリのログ ファイルが作成されていません。
ASP.NET Core モジュール デバッグ ログ: ルート アプリのログ ファイルが作成され、通常の動作を示します。 サブアプリのログ ファイルが作成されません。
トラブルシューティング:
サブアプリの web.config ファイルに <handlers> セクションがないか、サブアプリが親アプリのハンドラーを継承していないことを確認してください。
<system.webServer> の親アプリの <system.webServer> セクションが <location> 要素の中に置かれています。 InheritInChildApplications プロパティは、false に設定されます。これは、InheritInChildApplications 要素内で指定された設定が、親アプリのサブディレクトリにあるアプリによって継承されないことを示します。 詳細については、「IIS の ASP.NET Core モジュール (ANCM)」を参照してください。
stdout ログのパスが正しくありません
ブラウザー: アプリは通常どおりに応答します。
アプリケーション ログ: C:\Program Files\IIS\Asp.Net Core Module\V2\aspnetcorev2.dll で stdout リダイレクトを開始できません。 例外メッセージ:HRESULT 0x80070005 が {PATH}\aspnetcoremodulev2\commonlib\fileoutputmanager.cpp:84 で返されました。 C:\Program Files\IIS\Asp.Net Core Module\V2\aspnetcorev2.dll で stdout リダイレクトを停止できません。 例外メッセージ:HRESULT 0x80070002 が {PATH} で返されました。 {PATH}\aspnetcorev2_inprocess.dll で stdout リダイレクトを開始できません。
ASP.NET Core モジュールの stdout ログ: ログ ファイルが作成されていません。
ASP.NET Core モジュール デバッグ ログ: C:\Program Files\IIS\Asp.Net Core Module\V2\aspnetcorev2.dll で stdout リダイレクトを開始できません。 例外メッセージ:HRESULT 0x80070005 が {PATH}\aspnetcoremodulev2\commonlib\fileoutputmanager.cpp:84 で返されました。 C:\Program Files\IIS\Asp.Net Core Module\V2\aspnetcorev2.dll で stdout リダイレクトを停止できません。 例外メッセージ:HRESULT 0x80070002 が {PATH} で返されました。 {PATH}\aspnetcorev2_inprocess.dll で stdout リダイレクトを開始できません。
トラブルシューティング:
stdoutLogFileの<aspNetCore>要素で指定されたstdoutLogFileパスが存在しません。 詳細については、「ASP.NET Core モジュール:ログの作成とリダイレクト」を参照してください。アプリ プール ユーザーに stdout ログ パスに対する書き込みアクセス権がありません。
アプリケーション構成の一般的な問題
ブラウザー: HTTP エラー 500.0 - ANCM インプロセス要求ハンドラー失敗 --または-- HTTP エラー 500.30 - ANCM インプロセス起動失敗
アプリケーション ログ: 変数
ASP.NET Core モジュールの stdout ログ: ログ ファイルが作成されますが空です。あるいは作成され、通常のエントリが含まれますが、アプリのところでエラーが発生します。
ASP.NET Core モジュール デバッグ ログ: 変数
トラブルシューティング:
このプロセスはおそらく、アプリの設定またはプログラミングに問題があり、開始できませんでした。
詳細については、次のトピックを参照してください。
その他のリソース
- Visual Studio で .NET と ASP.NET Core のソース コードをデバッグする
- ASP.NET Core プロジェクトのトラブルシューティングとデバッグ
- ASP.NET Core のエラーを処理する
- IIS の ASP.NET Core モジュール (ANCM)
Azure のドキュメント
- ASP.NET Core 用 Application Insights
- Visual Studio を使用した Azure App Service の Web アプリのトラブルシューティングの Web アプリのリモート デバッグ セクション
- Azure App Service の診断の概要
- 方法: Azure App Service でアプリを監視する
- Visual Studio を使用した Azure App Service での Web アプリのトラブルシューティング
- Azure Web Apps での "502 bad gateway" および "503 service unavailable" の HTTP エラーのトラブルシューティング
- Azure App Service での Web アプリのパフォーマンス低下に関する問題のトラブルシューティング
- Azure での Web アプリのアプリケーションパフォーマンスに関するよくあるご質問
- Azure Web アプリのサンドボックス (App Service ランタイムの実行の制限)
Visual Studio ドキュメント
- Visual Studio 2017 における Azure の IIS での ASP.NET Core のリモート デバッグ
- Visual Studio 2017 におけるリモートの IIS コンピューターでの ASP.NET Core のリモート デバッグ
- Visual Studio を使用したデバッグについて理解する
Visual Studio Code ドキュメント
ASP.NET Core
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示