IIS 500.19の原因と直し方：web.config設定エラーの確認順

2026年8月4日

IISで業務Webを開いたときに HTTP Error 500.19 - Internal Server Error が出ると、まずアプリの不具合を疑いたくなります。ただ、500.19はアプリの処理まで進む前に止まっていることがあります。

画面には Error Code、Config File、Config Source などが出ます。ここを読まずにコードやDBを触り始めると、かなり遠回りになります。

IIS 500.19は、IISが設定を読み込む段階で失敗したときに出るエラーです。まずエラー画面の Error Code と Config File を控え、web.config、IISモジュール、権限、上位設定との差分を順に確認します。

この記事では、IIS 500.19の意味を確認したうえで、代表的な原因ごとに直し方を整理します。対象は、IIS上で動くASP.NET、ASP.NET Core、PHP、社内Webアプリなどです。

IIS 500.19とは何か

IIS 500.19は、HTTP 500番台のエラーです。ただし、アプリケーションコードの例外で返っている通常の500エラーとは少し違います。

IISがサイトの設定を読み込むときに、web.config や ApplicationHost.config の内容を解釈できない、必要なモジュールがない、設定ファイルを読めない、といった状態で出ます。そのため、アプリ側のログには何も出ていないことがあります。

HTTP 500の中でも設定読み込みに失敗したときのエラー

画面には、だいたい次のような情報が表示されます。サーバー設定によって見え方は少し変わりますが、見る場所は同じです。

Markdown

HTTP Error 500.19 - Internal Server Error
The requested page cannot be accessed because the related configuration data for the page is invalid.

Module: IIS Web Core
Notification: BeginRequest
Handler: Not yet determined
Error Code: 0x8007000d
Config File: \\?\C:\inetpub\wwwroot\sample\web.config
Config Source:
   12:     <rewrite>
   13:       <rules>

HTTP Error 500.19 - Internal Server Error
The requested page cannot be accessed because the related configuration data for the page is invalid.

Module: IIS Web Core
Notification: BeginRequest
Handler: Not yet determined
Error Code: 0x8007000d
Config File: \\?\C:\inetpub\wwwroot\sample\web.config
Config Source:
   12:     <rewrite>
   13:       <rules>

Handler: Not yet determined のように出ている場合、IISがまだリクエストをアプリの処理へ渡せていません。まず見るべき場所はアプリコードではなく、IISが読んでいる設定ファイルです。

tomo

アプリログに何も出ないと、何を見ればいいのか不安になります。500.19では、その沈黙自体がIIS側で止まっている手がかりになります。

アプリの処理に入る前に止まっている場合がある

アプリログ、Laravelログ、ASP.NET Coreのログ、PHPのログに何も出ないときは、IIS側で止まっている可能性があります。この状態でアプリの例外処理やSQLを追っても、原因に届きません。

500.19では、IISが設定を読み込めず、アプリケーションプールのワーカープロセスへ処理を渡す前にエラー画面を返していることがあります。だから、最初の調査順を間違えないことが大事です。

エラー画面に原因の手がかりが表示される

500.19の画面で特に見るのは、次の3つです。

項目	見る理由	例
Error Code	原因の系統を絞る	0x8007000d、0x80070021、0x80070005
Config File	どの設定ファイルで止まったか確認する	C:\inetpub\wwwroot\app\web.config
Config Source	問題に近い行を確認する	handlers、modules、rewrite など

Error Code が分かると、確認する場所をかなり絞れます。画面を閉じる前に、エラーコードとファイルパス、表示されている行をメモしておきます。

500.19の調査は、エラー画面を読むところから始めます。 0x8007000d なら設定内容や未導入モジュール、0x80070005 なら権限、0x80070021 なら設定ロックを先に疑います。

500.19で最初に見るエラー画面の項目

最初にサーバーへログインして設定を変える前に、エラー画面の情報を残します。このメモがないと、あとで「何を直して直ったのか」が分からなくなります。

Error Codeで原因の種類を確認する

500.19では、同じ画面でも Error Code によって原因が変わります。代表的なものだけでも、これくらい違います。

Error Code	疑う原因	最初に見る場所
0x8007000d	XML不正、認識できない設定要素、未導入モジュール	Config Source、handlers、modules、rewrite
0x80070021	上位レベルで設定セクションがロックされている	該当セクション、ApplicationHost.config
0x80070005	権限不足	サイトフォルダ、web.config、IIS_IUSRS、アプリプールID
0x800700b7	設定の重複	親フォルダや上位設定との重複
0x8007007e	参照しているモジュールやDLLがない	modules、Hosting Bundle、URL Rewrite
0x80070003	物理パスや設定ファイルが見つからない	Physical Path、Config File、仮想ディレクトリ

0x8007000d なら web.config の書式や未導入モジュール、0x80070005 なら権限、0x80070021 なら設定ロックを先に見ます。全部を順番に総当たりするより、エラーコードから当たりを付けたほうが早いです。 Error Codeを控えない調査は、地図なしでサーバー内を歩くようなものです。

Config Fileで対象ファイルを確認する

Config File には、IISが読み込みに失敗した設定ファイルが出ます。よく見るのはアプリ直下の web.config ですが、アプリケーションプール用の一時設定や上位の設定ファイルが出ることもあります。

Markdown

Config File: \\?\C:\inetpub\wwwroot\sales-app\web.config

Config File: \\?\C:\inetpub\wwwroot\sales-app\web.config

ここに出ているパスが、今アクセスしているサイトの物理パスと一致しているかを見ます。別のフォルダを見ている場合は、IISマネージャーのサイト設定や仮想ディレクトリの物理パスがずれている可能性があります。

Config Sourceで問題の行を確認する

Config Source には、問題の近くの行が表示されます。たとえば rewrite の行で止まっていればURL Rewriteモジュール不足、aspNetCore の行で止まっていればASP.NET Core Hosting Bundle不足、handlers の行ならハンドラ設定の重複や不足を疑います。

ただし、表示される行が原因そのものとは限りません。 XMLの閉じ忘れでは、実際のミスより後ろの行で止まることがあります。

Config Sourceの行だけを消して直そうとすると、別の設定を壊すことがあります。先にバックアップを取り、差分を見ながら直してください。

本番環境の web.config や ApplicationHost.config を直接編集する場合は、変更前のファイルを必ず退避してください。 500.19が消えても、認証、リダイレクト、静的ファイル配信など別の動作が変わることがあります。

web.configの書き間違いを直す

0x8007000d や 0x800700b7 では、web.config の書き方そのものを疑います。デプロイ時に手で追記した設定、別環境からコピーした設定、親フォルダと重複した設定が原因になりやすいです。

XMLの閉じ忘れを確認する

web.config はXMLです。タグの閉じ忘れ、属性のクォート漏れ、不要な文字があると、IISは設定を読めません。

壊れた例です。

XML

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="SampleHandler" path="*.sample" verb="*" modules="IsapiModule"
    </handlers>
  </system.webServer>
</configuration>

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="SampleHandler" path="*.sample" verb="*" modules="IsapiModule"
    </handlers>
  </system.webServer>
</configuration>

add タグの閉じ /> が抜けています。このような場合は、XMLとして読める形に直します。

XML

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="SampleHandler" path="*.sample" verb="*" modules="IsapiModule" />
    </handlers>
  </system.webServer>
</configuration>

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="SampleHandler" path="*.sample" verb="*" modules="IsapiModule" />
    </handlers>
  </system.webServer>
</configuration>

エディタでXMLの構文チェックができるなら、まずそこに通します。本番サーバー上で直接編集した場合は、保存時に文字コードや不要な全角記号が混ざっていないかも見ます。

同じ設定を二重に書いていないか見る

0x800700b7 では、同じ設定がすでに上位にあり、アプリ側の web.config でも同じものを追加していることがあります。

たとえば親フォルダや ApplicationHost.config に同じ handlers や authorization があり、アプリ側でも同名の設定を足すと重複になります。

XML

<handlers>
  <add name="PHP_via_FastCGI" path="*.php" verb="*" modules="FastCgiModule" resourceType="Either" />
  <add name="PHP_via_FastCGI" path="*.php" verb="*" modules="FastCgiModule" resourceType="Either" />
</handlers>

<handlers>
  <add name="PHP_via_FastCGI" path="*.php" verb="*" modules="FastCgiModule" resourceType="Either" />
  <add name="PHP_via_FastCGI" path="*.php" verb="*" modules="FastCgiModule" resourceType="Either" />
</handlers>

この場合は、どちらを残すかを決めます。アプリ単位で持つべき設定なのか、サーバー全体で持つべき設定なのかを確認し、不要な重複を消します。 重複しているからといって、片方を機械的に削除してはいけません。上位設定で共通管理している場合は、アプリ側だけ見ても判断できません。

環境ごとの差分を比べる

開発環境では動くのに本番IISだけ500.19になる場合、設定差分を見ます。同じ web.config を置いていても、本番側にモジュールが入っていなければ動きません。

確認では、少なくとも次を比べます。

web.config の内容
IISのバージョン
インストール済みのIIS機能
URL RewriteやASP.NET Core Hosting Bundleの有無
アプリケーションプールの.NET CLR、パイプライン、32/64bit設定

差分を見ないまま web.config だけを直すと、次のデプロイで同じエラーが戻ります。設定ファイルとサーバー側の機能は、必ずセットで確認します。

handlersやmodulesの不足を直す

web.config に書かれている設定をIISが理解できないと、500.19になります。よくあるのは、アプリが使うモジュールを web.config が参照しているのに、サーバーへ入っていないケースです。

指定したモジュールがIISに入っているか確認する

Config Source に rewrite、handlers、modules が出ている場合、指定している機能がサーバーにあるかを確認します。

URL Rewriteを使っている例です。

XML

<system.webServer>
  <rewrite>
    <rules>
      <rule name="Redirect to index">
        <match url=".*" />
        <action type="Rewrite" url="index.php" />
      </rule>
    </rules>
  </rewrite>
</system.webServer>

<system.webServer>
  <rewrite>
    <rules>
      <rule name="Redirect to index">
        <match url=".*" />
        <action type="Rewrite" url="index.php" />
      </rule>
    </rules>
  </rewrite>
</system.webServer>

この設定を使うには、IISにURL Rewriteモジュールが必要です。別サーバーから web.config だけコピーしたときに、移行先へモジュールを入れ忘れると500.19になります。

ASP.NET Core Hosting BundleやFastCGIの不足を疑う

ASP.NET Coreアプリでは、aspNetCore の設定が web.config に入ります。 IIS側に対象バージョンのHosting Bundleが入っていないと、この設定を処理できません。

XML

<system.webServer>
  <handlers>
    <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
  </handlers>
  <aspNetCore processPath="dotnet" arguments=".\SampleApp.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="inprocess" />
</system.webServer>

<system.webServer>
  <handlers>
    <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
  </handlers>
  <aspNetCore processPath="dotnet" arguments=".\SampleApp.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="inprocess" />
</system.webServer>

PHPをIISで動かす場合は、FastCGIの設定やPHP実行ファイルのパスも確認します。 handlers がPHPを指しているのにFastCGIが有効でない、PHPのパスが古い、32bit/64bitが合わない、といったズレで止まることがあります。 Config Sourceに出た設定名は、IISにその機能が入っているかを確認する入口になります。

使わない設定をweb.configから外す

過去の設定が残っているだけなら、モジュールを追加するより web.config から外したほうがよい場合もあります。たとえば、もうURL Rewriteを使っていないのに rewrite セクションだけが残っているなら、アプリの動作を確認したうえで削除候補にします。

ただし、消す前に次を確認します。

その設定を使っているURLがないか
別環境では必要な設定ではないか
デプロイ手順で自動生成される設定ではないか
変更前のファイルを戻せる状態にしているか

設定ファイルは小さく見えても、画面遷移、認証、静的ファイル、APIルーティングに影響します。軽く消すと別の障害になります。

tomo

ここまで来たら、直す対象はかなり絞れています。焦らず、設定を消す前に「この設定を誰が使っているか」だけ確認して進めます。

権限不足でweb.configを読めない状態を直す

0x80070005、0x80070003、0x8007052e では、ファイルやフォルダの権限を見ます。 IISが web.config やサイトフォルダを読めないと、設定が正しくても500.19になります。

アプリケーションプールの実行ユーザーを確認する

IISマネージャーで、対象サイトが使っているアプリケーションプールを確認します。そのアプリケーションプールのIDが、サイトフォルダを読める必要があります。

Windows Server 2008 R2以降では、アプリケーションプールごとの仮想アカウントを使う構成が一般的です。たとえばアプリケーションプール名が SalesAppPool なら、権限付与の対象は次のようになります。

Markdown

IIS AppPool\SalesAppPool

IIS AppPool\SalesAppPool

共有フォルダや別ドライブに配置している場合は、ローカルフォルダより権限が分かりにくくなります。このときは「IISで設定されているアプリケーションプールID」と「実際にファイルを読めるアカウント」を分けて確認します。

サイトフォルダに読み取り権限を付ける

まずは web.config があるフォルダに読み取り権限があるかを確認します。必要な場合は、対象アプリケーションプールのIDに読み取り権限を付けます。

コマンドで確認や付与をする場合の例です。実行前に、アプリケーションプール名と対象パスを必ず置き換えてください。

PowerShell

icacls "C:\inetpub\wwwroot\sales-app"
icacls "C:\inetpub\wwwroot\sales-app" /grant "IIS AppPool\SalesAppPool:(OI)(CI)(RX)"

icacls "C:\inetpub\wwwroot\sales-app"
icacls "C:\inetpub\wwwroot\sales-app" /grant "IIS AppPool\SalesAppPool:(OI)(CI)(RX)"

RX は読み取りと実行です。アップロード先やログ出力先には書き込み権限が必要なこともありますが、500.19の初期調査では、まず web.config とサイトフォルダを読めるかを見ます。 500.19の権限確認では、最初からフルコントロールを付ける必要はありません。まず読み取り権限で足りるかを確認します。

共有フォルダ配置で起きる権限ズレを見る

サイトの物理パスがUNCパスになっている場合は、ローカル権限だけでは足りません。共有フォルダ側の共有権限とNTFS権限、IISで指定している接続ユーザーを確認します。

Markdown

Physical Path: \\fileserver\webroot\sales-app

Physical Path: \\fileserver\webroot\sales-app

この構成では、IISサーバーのローカルユーザーではなく、ファイルサーバーから見て有効なアカウントで読む必要があります。手元でファイルが見えるからといって、IISからも読めるとは限りません。

直ったかどうかをログで確認する

設定を直したら、ブラウザを再読み込みするだけで終わらせません。同じ500.19が残っていないか、別のエラーへ進んだのかを確認します。

イベントビューアで同じ500.19が残っていないか見る

IISの設定読み込みで失敗している場合、イベントビューアに手がかりが残ることがあります。見る場所は環境によって変わりますが、まずは次を確認します。

Markdown

Windows ログ
  アプリケーション
  システム

アプリケーションとサービス ログ
  Microsoft
  Windows
  IIS-Configuration
  IIS-Logging

Windows ログ
  アプリケーション
  システム

アプリケーションとサービス ログ
  Microsoft
  Windows
  IIS-Configuration
  IIS-Logging

イベントの時刻を、ブラウザでエラーを再現した時刻と合わせます。古いエラーを見て判断すると、すでに直っている問題を追い続けてしまいます。

IISログとアプリログのどちらに進んだか見る

IISログには、リクエストのステータスが残ります。ただし、500.19は設定読み込みの段階で止まるため、アプリ側の詳細ログまでは出ないことがあります。

Markdown

C:\inetpub\logs\LogFiles\W3SVC<site-id>\

C:\inetpub\logs\LogFiles\W3SVC<site-id>\

修正後に500.19ではなくアプリ側の500、404、認証エラーなどへ変わった場合は、調査の段階が進んでいます。その場合は、IIS設定の問題をいったん切り分け、アプリログやルーティング、認証設定の調査へ移ります。

tomo

500.19が別のエラーに変わったときは、失敗ではありません。IISが設定を読めるところまでは進んだ、という手がかりになります。

変更内容を調査メモに残す

障害対応では、直した内容よりも「何を見て、何を変えて、どう変わったか」が後で効きます。最低限、次の形で残しておくと再発時に使えます。

Markdown

発生日時: 2026-08-04 09:20
対象URL: https://example.local/sales/
表示エラー: HTTP Error 500.19
Error Code: 0x8007000d
Config File: C:\inetpub\wwwroot\sales-app\web.config
Config Source: rewrite セクション付近

確認:
- アプリログには該当時刻の例外なし
- 本番IISにURL Rewriteモジュールなし
- 検証環境にはURL Rewriteモジュールあり

対応:
- 本番IISへURL Rewriteモジュールを追加
- IIS再起動後、500.19は解消

残課題:
- デプロイ前チェックにIISモジュール確認を追加する

発生日時: 2026-08-04 09:20
対象URL: https://example.local/sales/
表示エラー: HTTP Error 500.19
Error Code: 0x8007000d
Config File: C:\inetpub\wwwroot\sales-app\web.config
Config Source: rewrite セクション付近

確認:
- アプリログには該当時刻の例外なし
- 本番IISにURL Rewriteモジュールなし
- 検証環境にはURL Rewriteモジュールあり

対応:
- 本番IISへURL Rewriteモジュールを追加
- IIS再起動後、500.19は解消

残課題:
- デプロイ前チェックにIISモジュール確認を追加する

このメモがあると、次回のデプロイ前チェックに落とし込めます。「直った」で終わらせると、次のサーバー移行でまた同じところに戻ります。

まとめ

IIS 500.19は、アプリの処理ではなく、IISの設定読み込みで止まっている可能性が高いエラーです。最初に見るのは、アプリコードではなくエラー画面の Error Code、Config File、Config Source です。

確認順は次の流れにすると迷いにくくなります。

Error Code で原因の系統を決める
web.config のXML不正や重複設定を見る
handlers、modules、URL Rewrite、Hosting Bundle、FastCGIの不足を見る
アプリケーションプールIDとサイトフォルダの読み取り権限を見る
イベントログ、IISログ、アプリログでどこまで進んだか確認する

500.19では、焦ってアプリコードを直す前に、IISが設定を読めているかを確認します。エラー画面に出ている情報を控えてから触るだけで、調査の遠回りをかなり減らせます。

よかったらシェアしてね！

URLをコピーしました！

タスクスケジューラでバッチが動かないときの確認順

IIS 500.19の原因と直し方：web.config設定エラーの確認順

IIS 500.19とは何か

HTTP 500の中でも設定読み込みに失敗したときのエラー

アプリの処理に入る前に止まっている場合がある

エラー画面に原因の手がかりが表示される

500.19で最初に見るエラー画面の項目

Error Codeで原因の種類を確認する

Config Fileで対象ファイルを確認する

Config Sourceで問題の行を確認する

web.configの書き間違いを直す

XMLの閉じ忘れを確認する

同じ設定を二重に書いていないか見る

環境ごとの差分を比べる

handlersやmodulesの不足を直す

指定したモジュールがIISに入っているか確認する

ASP.NET Core Hosting BundleやFastCGIの不足を疑う

使わない設定をweb.configから外す

権限不足でweb.configを読めない状態を直す

アプリケーションプールの実行ユーザーを確認する

サイトフォルダに読み取り権限を付ける

共有フォルダ配置で起きる権限ズレを見る

直ったかどうかをログで確認する

イベントビューアで同じ500.19が残っていないか見る

IISログとアプリログのどちらに進んだか見る

変更内容を調査メモに残す

まとめ

関連記事