ASP.NET Web アプリケーションで System.OutOfMemoryException が発生する場合のトラブルシューティング

現象
Microsoft ASP.NET Web アプリケーション (以下 ASP.NET Web) で発生し得る一般的な問題として、System.OutOfMemoryException (メモリ不足エラー) があります。この資料では、このような問題の一般的な原因と、原因を調査するために必要な情報を取得する方法を説明します。
はじめに
Microsoft .NET Framework における System.OutOfMemoryException は、主に .NET のメモリ セグメントを確保できないために発生します。このセグメント サイズは 32bit ASP.NET Web アプリケーションの既定では 64 MB となります。すなわち、System.OutOfMemoryException は、システムに実装された物理メモリの不足や、システム全体の空きメモリ不足を意味するものではなく、OS がプロセスに割り当てたユーザー仮想メモリ空間 (32 bit Windows の既定では 2GB です) の使用量増加や、断片化 (フラグメンテーション) による連続空き領域の不足が原因で発生します。

一般的には、32 bit 環境では ASP.NET Web のホスト プロセス (aspnet_wp.exe または w3wp.exe) のメモリ使用量が 800 MB を超えると OutOfMemoryException が発生し始め、1 GB を超えると GC の負荷により CPU 使用率が上昇し始める事が知られています。なお、この数値はあくまで一般的な経験値であり、アプリケーションの構成や実装によっては、300 MB 程度で OutOfMemoryException が発生する事例や、1.8 GB 使用していても例外が発生しない事例も確認されています。

Microsoft Product Support Services では、ASP.NET Web において System.OutOfMemoryException が発生する場合、この資料で紹介する問題に該当していないかの確認や情報のご提供を依頼することがあります。また、この資料で紹介する情報がない場合には、このような問題に関する調査が行えない場合があります。
詳細

ASP.NET Web アプリケーションで System.OutOfMemoryException が発生する一般的な原因

System.OutOfMemoryException は必ずしも物理メモリの不足を意味するものではありません。また、.NET アプリケーションではプログラムが使用しなくなったメモリを解放する機能を持つガベージ コレクト (以下 GC) の存在により、通常の使用においてメモリ リークが発生することは基本的にありません。このため、ASP.NET Web において System.OutOfMemoryException が発生し、メモリの使用量が多い場合、その原因はアプリケーションにそういった動作を招く実装や構成がなされている可能性が高いと考えられます。ここでは、System.OutOfMemoryException となるいくつかの一般的な原因を説明します。

原因 1 : セッション変数に大きなデータを保持している、または、セッション数が多い場合

セッション変数にデータを保持する際、データは格納可能な形式にシリアライズされるため本来のサイズよりも大きくなります。

具体的なサイズの増分については、セッション変数に格納するデータの型、大きさ、構造等により異なりますので定量化はできませんが、DataSet などの構造が複雑なものほどシリアライズによるサイズの増分は大きくなります。また、情報はセッション = 接続毎に保持されますので、たとえば、1 セッションあたり 1 MB のデータを保持する場合、セッション数が同時に 100 接続ある場合は 100 MB のメモリ容量を必要とします。

原因 2 : ASP.NET Web アプリケーションが使用するアセンブリの数が多い場合

.NET は JIT コンパイルしたマシン コードをアセンブリごとのチャンクでメモリ上に保持するため、アセンブリ数が増える (おおよそ 500 個以上) とメモリが断片化しやすくなる傾向があります。この傾向は ASP.NET 1.0 および 1.1 で顕著に現れます。

原因 3 : web.config ファイル <compilation> 要素の debug 属性を True に設定している場合

ASP.NET Web は、バッチ コンパイル時にプロジェクト毎に 1 つのアセンブリとして構成されますが、web.config ファイル <compilation> 要素の debug の属性が True であった場合は、デバッグ情報を含むアセンブリを、*.aspx ファイル毎にそれぞれ個別に生成します。これによって 原因 2 の発生原因となり、OutOfMemoryException が発生しやすくなります。また、デバッグ モードのアセンブリは動作速度等に多少のオーバーヘッドが発生する事が知られています。

原因 4 : 厳密名を持つアセンブリのインストールが正しくない場合

厳密名を持つアセンブリや Web フォーム コントロールは、Global Assembly Cache (以下 GAC) に登録して使用する必要がありますが、bin に配置してもある程度動作するため、誤ったインストールが行われている場合があります。このような場合でも、低負荷の状態や単純な動作ではエラーが発生しないため気付かないことが多いですが、使用を続けるうちに予期しないエラーが発生する場合があります。この現象は特に ASP.NET 1.0 および 1.1 で発生します。ASP.NET 2.0 ではアセンブリローダの動作変更により影響を受けにくいと考えられます。

原因 5 : リクエスト処理に大量のメモリを必要とする場合

Web サーバの動的応答処理は、単純な処理をわずかなメモリ使用量で短期間に高い多重度で繰り返す、という動作の特性があります。そのため、大量のリクエスト処理を行ったとしてもメモリ使用量および CPU 使用率はある程度で保たれる状態が一般的です。

しかし、多重度の低いバッチ処理サーバのようなアプリケーションの実装を行うと、この動作特性と相反し、メモリ使用量が非常に高い状態を生み出す場合があります。特にデータベースから数万件のレコードを取り出し、それを XML にシリアライズして受け取る、受け渡すといった処理を行うと、1 リクエストの処理に数百 MB のメモリ領域 (フットプリント) を要求し、その結果 OutOfMemoryException が発生する場合があります。

原因 6 : メモリ使用量の増大、またはメモリの断片化 (フラグメンテーション) が発生している場合

GC はマネージ ヒープ内でオブジェクトを再配置して断片化を解消し、連続した空きメモリを確保することで最適化を行います。このとき、GC はジェネレーショナル メモリ管理によって、新しいジェネレーションのオブジェクトのメモリは頻繁に解放し、生存期間の長いジェネレーションのオブジェクトのメモリは頻繁な解放処理を行わないという動作をします。

しかし、ラージ オブジェクト ヒープ (Large Object Heap : 以下 LOH) の過度な使用や、不要なルート参照、mid-life crisis と呼ばれるメモリ配置の不均等の問題、GC のジェネレーションサイズ自動調整機能を阻害する意図的な GC.Collect() メソッドの実行等により GC が適切に機能せず、マネージ メモリが効率的に処理されないこともあります。

LOH、不要なルート参照、および mid-life crisis の詳細については、次のマイクロソフト Web サイトを参照してください。
マネージ コードでのメモリ リークの識別と回避
http://msdn.microsoft.com/msdnmag/issues/07/01/ManagedLeaks/default.aspx?loc=jp

System.OutOfMemoryException の一般的な原因に対する対応

上述に記載した原因で System.OutOfMemoryException が発生している場合は、以下のような対処方法が有効です。

対処方法 1 : セッション変数に格納するデータ サイズの確認、および負荷分散を行う

セッション変数に不要に大きなデータを格納することを避ける、またはセッション変数に格納したオブジェクトは不要になった時点で削除するなどの実装を行うことを検討します。または、<sessionState> 要素 mode 属性を SQLServer や StateServer にし、アウト プロセスにセッション変数を格納することで現象が緩和される可能性があります。

また、1 セッションあたりのデータ サイズが大きくなくても ASP.NET Web 実行プロセスあたりのセッション数が多いと、メモリ使用量が増大します。このような場合は Web ガーデンや Web ファームによる負荷分散を検討します。

対処方法 2 : ASP.NET Web アプリケーションが使用するアセンブリの数が多い場合

不要なアセンブリは削除します。また、複数のアセンブリのソースコードを統合して 1 つのアセンブリにビルドします。

対処方法 3 : web.config ファイル <compilation> 要素の debug 属性を False に設定する

web.config ファイル <compilation> 要素の debug の属性を False に設定します。

対処方法 4 : 厳密名を持つアセンブリを GAC に登録する

厳密名が付与されたアセンブリは共用アプリケーション ドメインに読み込まれるため、Global Assembly Cache(%WinDir%\Assembly) への格納をお勧めします。

関連するエラー メッセージについては、以下の 「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。
324519 PRB: ASP.NET で "別のプロセスによって使用されているので、ファイル AssemblyName にアクセスすることができません" と、エラー メッセージが表示される。
813833 PRB: グローバル アセンブリ キャッシュ に厳密名を持つアセンブリを配置しない場合、“アクセス拒否” エラー メッセージが表示される
一般的には gacutil.exe (グローバル アセンブリ キャッシュ ツー) を使用して厳密名を持つアセンブリを GAC に登録しますが、他社製のアセンブリをご利用の場合は、開発元に確認してください。
.NET Framework ツール グローバル アセンブリ キャッシュ ツール (Gacutil.exe)
http://msdn.microsoft.com/library/ja/cptools/html/cpgrfglobalassemblycacheutilitygacutilexe.asp

対処方法 5 : リクエスト処理に大量のメモリを必要とする場合

前述のとおり、32 bit OS でのユーザー メモリ空間は既定で最大 2 GB の有限な資源となります。アプリケーションへの負荷テスト等にて、どの程度のメモリを使用するかを確認し、多重度を落としても大量のメモリを使用したい場合には、Remoting 等の技術を使用した専用ホスト プロセスの作成を検討してください。

対処方法 6 : メモリ リサイクル機能の使用

メモリが断片化された場合には、プロセスを終了しメモリを解放する以外に対処方法はありません。Microsoft Internet Information Services 6.0 (以下 IIS 6.0 ) では、アプリケーションを実行するプロセス (w3wp.exe) が一定のメモリ使用量に達した場合に自動的にプロセスを再起動 (リサイクル) するメモリ リサイクル機能があります。以下の手順で、メモリ リサイクル機能を有効にしてください。
  1. インターネット サービス マネージャを起動します。
  2. 左側ペインからメモリ不足エラーが発生するアプリケーションを実行するアプリケーション プールを選択し、右クリックしてプロパティを開きます。
  3. [リサイクル] タブを選択し、[メモリのリサイクル] で [最大仮想メモリ] チェック ボックスと [最大使用メモリ] チェック ボックスをオンにし、プロセスをリサイクルする閾値を設定します。
注 : IIS 6.0 のリサイクル機能は既定の構成では “オーバーラップしたリサイクル” であるため、新しいプロセスが開始されるまでは古いプロセスで要求を処理するので、サービスの中断が避けられます。

一般的に、w3wp.exe の仮想メモリのうち、予約領域 (Virtual Bytes) が 1.3 GB 程度、使用領域 (Private Bytes) が 800 MB 程度で、メモリの断片化に伴い連続領域の確保ができなくなり、メモリ不足エラーが発生する傾向が見られます。このような場合には、メモリ リサイクル機能のリサイクルのしきい値として [最大仮想メモリ] を 1.3 GB、[最大使用メモリ] を 800 MB に設定します。ただし、この数値は実行している環境やアプリケーションの処理内容に大きく依存するため、メモリ不足エラーが発生する環境で正常運用できる範囲を測定し、しきい値として使用してください。

対処方法 7 : /3GB オプションの使用を検討する

Windows メモリ マネージャは、ページ ベースの仮想メモリ管理方法を実装しており、実際に搭載されている物理メモリを超える巨大なプライベート アドレス空間を個々のユーザー モード プロセスに提供します。

このプライベート アドレス空間内で、64 bit オペレーティング システムのユーザー モード プロセスは 8 TB のメモリ (ユーザー領域と呼ばれるメモリ領域)、32 bit オペレーティング システムのユーザー モード プロセスは 2 GB のメモリにアクセスすることができます。ユーザー モード プロセスにおけるメモリ不足はこれらのプライベート アドレス空間内におけるメモリ領域が不足した場合に発生するものであり、物理メモリの不足を意味するものではありません。このため、System.OutOfMemoryException の対策として、物理メモリ (RAM) を増やすことは効果がありません。

32 bit オペレーティング システムにおいてユーザー モード プロセスがアクセスすることのできるメモリ領域を 2 GB から 3 GB に拡張するオプションとして /3GB オプションがあります。

/3GB オプションを使用する際の留意点

/3GB オプションを有効にすると、カーネル モードのコンポーネントが使用できるメモリ領域は 1 GB に縮小されます。

メモリ不足エラーの対策として、/3GB オプションを有効にする場合には、Windows Server 2003 では以下の「サポート技術情報」 (Microsoft Knowledge Base) に記載の弊害が発生しやすくなる点に注意してください。
934878 エラー メッセージ "ページを表示できません" がユーザーに表示され、Windows Server 2003、Exchange 2003、および IIS 6.0 を実行しているサーバーの Httperr.log ファイルに "Connections_refused" エントリが記録される

パフォーマンス ログおよびデバッグ情報 (ダンプ ファイル) の取得方法

System.OutOfMemoryException の一般的な原因に対する対処を実施しても System.OutOfMemoryException が抑制されない場合はその原因を調査するために、パフォーマンス ログとデバッグ情報 (ダンプ ファイル) を収集します。

ツールのダウンロード

ダンプ ファイルは Debugging Tools for Windows に含まれる ADPlus.vbs を使用して取得します。あらかじめ、問題が発生する可能性のあるコンピュータに Debugging Tools for Windows をインストールしておきます。

最新の Microsoft Debugging Tools for Windows を入手するには、次のマイクロソフト Web サイトを参照してください。
Windows 用デバッグ ツール
http://www.microsoft.com/japan/whdc/devtools/debugging/default.mspx

このツールはインストーラを実行し、コンピュータにインストールします。しかし、別のコンピュータにインストールし、インストール ディレクトリごとコピーして使用することができます。ソフトウェア構成を変更できない運用環境で使用する際に役立ちます。また、削除する際はコピーしたフォルダを削除するだけです。

パフォーマンス モニタでの情報採取

時間経過に応じたシステムの動作状況を確認するために、パフォーマンス モニタで以下のログを採取します。サンプル間隔を 5 秒にし、現象発生前後のログを採取します。ただし、サンプル間隔はシステムの負荷状況に応じて調整してください。

パフォーマンス オブジェクト : Process
カウンタ : すべてのカウンタ
インスタンス : aspnet_wp.exe または w3wp.exe

注 : Microsoft Windows 2000 Server の Microsoft Internet Information Server 5.0 (以下 IIS 5.0)、または Microsoft Windows Server 2003 の IIS 5.0 プロセス分離モードを使用している場合は aspnet_wp.exe、Microsoft Windows Server 2003 の IIS 6.0 ワーカー プロセス分離モードを使用している場合は w3wp.exe を選択します。

パフォーマンス オブジェクト : .NET CLR Exceptions
カウンタ : すべてのカウンタ
インスタンス : すべてのインスタンス

パフォーマンス オブジェクト : .NET CLR Loading
カウンタ : すべてのカウンタ
インスタンス : すべてのインスタンス

パフォーマンス オブジェクト : .NET CLR LocksAndThreads
カウンタ : すべてのカウンタ
インスタンス : すべてのインスタンス

パフォーマンス オブジェクト : .NET CLR Memory
カウンタ : すべてのカウンタ
インスタンス : すべてのインスタンス

パフォーマンス オブジェクト : ASP.NET、ASP.NET v1.1.4322、または ASP.NET v2.7.50727
カウンタ : すべてのカウンタ
インスタンス : すべてのインスタンス

注 : ASP.NET 1.0 の場合は ASP.NET、ASP.NET 1.1 の場合は ASP.NET v1.1.4322、ASP.NET 2.0 の場合は ASP.NET v2.7.50727 を選択します。

パフォーマンス オブジェクト : ASP.NET Applications、ASP.NET Apps v1.1.4322、または ASP.NET Apps v2.0.50727
カウンタ : すべてのカウンタ
インスタンス : すべてのインスタンス

注 : ASP.NET 1.0 の場合は ASP.NET Applications、ASP.NET 1.1 の場合は ASP.NET Apps v1.1.4322、ASP.NET 2.0 の場合は ASP.NET Apps v2.0.50727 を選択します。

Debugging Tools for Windows での情報採取

ダンプ ファイルの採取には 以下の 2 つの方法があります。それぞれ、情報採取における特徴を踏まえ、ダンプ ファイルの取得方法を選択してください。
  • crash モード
    System.OutOfMemoryException が発生する前に、あらかじめデバッガ実行します。System.OutOfMemoryException が発生すると自動的にダンプ ファイルが生成されます。System.OutOfMemoryException が発生するまで、ASP.NET Web 実行プロセス (aspnet_wp.exe または w3wp.exe) にデバッガをアタッチした状態で運用するため、システムのパフォーマンスが劣化する可能性があります。また、System.OutOfMemoryException が発生しダンプ ファイルが生成されると、プロセスは終了する場合があります。しかし、System.OutOfMemoryException が発生した瞬間を捉えたデバッグ情報であるため、多くの有効な情報が収集できる可能性があります。
  • hang モード
    System.OutOfMemoryException が発生した後で、デバッガを実行し、手動でダンプ ファイルを生成します。システムへの負荷は、ダンプ ファイルを生成するときのみです。また、ダンプ ファイル生成後も、プロセスは動作を続けます。しかし、System.OutOfMemoryException が発生した後のデバッグ情報であるため、有効な情報が少なく、再度情報の採取が必要となる可能性があります。

crash モード

crash モードでダンプ ファイルを採取するには次の操作を実行してください。
  1. Windows Server 2003 の IIS 6.0 ワーカー プロセス分離モードを使用している場合はあらかじめ、以下の手順に従って、リサイクルの設定を無効にします。
    1. インターネット サービス マネージャで問題が発生するアプリケーション プールのプロパティを開きます。
    2. [リサイクル] タブで、以下のチェック ボックスをオフにします。

      [ワーカー プロセスのリサイクル (分ごと)]
      [ワーカー プロセスのリサイクル (要求数)]
      [ワーカー プロセスのリサイクルを以下の時間に行う]
      メモリのリサイクル の [最大仮想メモリ]
      メモリのリサイクル の [最大使用メモリ]
    3. [パフォーマンス] タブで、以下のチェック ボックスをオフにします。

      [アイドルなワーカー プロセスの解放までの待ち時間]
      [CPU 管理を有効にする]
    4. [状態] タブで、[Ping を有効にする] チェック ボックスをオフにします。
    5. [OK] をクリックして、アプリケーション プールのプロパティを閉じます。
  2. 以下の内容のテキスト ファイルにコピーし、ADP_Aspnet_OutOfMemory.cfg という名前で、Debugging Tools for Windows インストール ディレクトリに保存します。また、C ドライブに Temp という名前のフォルダを作成します。
    <ADPlus>	<Settings>		<RunMode> CRASH </RunMode>		<SympathPlus> c:¥symbols </SympathPlus>		<OutputDir> c:¥temp </OutputDir>	</Settings>	<PreCommands>		<Cmd> .loadby sos mscorwks </Cmd>	</PreCommands>	<Exceptions>		<Config>			<Code> clr </Code>			<Actions1> Log; </Actions1>			<CustomActions1> !soe System.OutOfMemoryException 1;.if(@$t1==0) {} .else {.dump /ma /u C:¥¥Temp¥¥OutOfMemoryException.dmp} </CustomActions1>			<ReturnAction1> GN </ReturnAction1>		</Config>		<Config>			<Code> bpe </Code>			<Actions1> Log; </Actions1>			<ReturnAction1> QD </ReturnAction1>		</Config>		<Option> NoDumpOnFirstChance </Option>	</Exceptions></ADPlus>
    補足 : 必要に応じて、以下の行を変更します。
    <SympathPlus> c:¥symbols </SympathPlus>
    シンボル パスを設定しています。もし該当環境がインターネットにアクセス可能な場合には <SympathPlus> c:¥symbols*http://msdl.microsoft.com/download/symbols </SympathPlus> を指定し、Windows 製品のシンボル サーバを使用する事が可能です。通常は変更不要です。
    <OutputDir> C:¥Temp </OutputDir>
    ダンプ ファイルの出力フォルダを設定しています。ダンプ ファイルの出力先は必要に応じて変更してください。なお、ダンプ ファイルの出力先フォルダは、あらかじめ作成しておきます。
    <CustomActions1>	!soe System.OutOfMemoryException 1;.if(@$t1==0) {} .else {.dump /ma /u C:¥¥Temp¥¥OutOfMemory.dmp}</CustomActions1>
    System.OutOfMemoryException 発生時に自動的に生成されるダンプ ファイルの出力先フォルダ (C:¥Temp) とダンプ ファイル名 (OutOfMemory.dmp) を指定しています。ダンプ ファイルの出力先 (C:¥¥Temp¥¥) は必要に応じて変更してください。なお、例のようにフォルダの区切り (¥) は ¥¥ としてエスケープしてください。
  3. コマンド プロンプトを起動し、Debugging Tools for Windows インストール ディレクトリに移動します。
  4. 次のコマンドを実行し、cdb.exe を起動します。

    Microsoft Windows 2000 Server の IIS 5.0、または Microsoft Windows Server 2003 の IIS 5.0 プロセス分離モードを使用している場合
    cscript.exe adplus.vbs -quiet -pn aspnet_wp.exe -c ADP_Aspnet_OutOfMemory.cfg

    Microsoft Windows Server 2003 の IIS 6.0 ワーカー プロセス分離モードを使用している場合
    cscript.exe adplus.vbs -quiet -pn w3wp.exe -c ADP_Aspnet_OutOfMemory.cfg
  5. コンピュータをロックし、現象が発生するまで待機します。

    注 : 待機中にコンピュータからログオフしないでください。コンピュータをログオフしたり、IIS やコンピュータを再起動した場合は、手順 3 から 手順 5 を再度実行しなおしてください。
  6. 問題が発生すると、自動的にダンプ ファイルが作成されます。手順 2 の ADP_Aspnet_OutOfMemory.cfg を使用した場合、C:¥Temp フォルダに OutOfMemory_<日付および時刻>.dmp が生成されます。

    エラーやプロセスが異常終了する問題が発生して、ダンプ ファイルが生成される前にアプリケーションの応答が停止する現象 (ハングアップ) が発生した場合は、cdb.exe のウィンドウ上で Ctrl + C キーを押すと手動でダンプ ファイルが作成できます。あらかじめ、System.OutOfMemoryException を発生させる以下のようなコードで、ダンプ ファイルが正常に採取される事をご確認いただくことをお勧めします。

    たとえば、 ボタンのクリック時に OutOfMemoryException を発生させる C# サンプル コード
    private void Button1_Click(object sender, System.EventArgs e){	        System.OutOfMemoryException ex = new OutOfMemoryException();	        throw ex;}

hang モード

hang モードでダンプ ファイルを採取するには次の操作を実行してください。
  1. Windows Server 2003 の IIS 6.0 ワーカー プロセス分離モードを使用している場合はあらかじめ、以下の手順に従って、リサイクルの設定を無効にします。
    1. インターネット サービス マネージャで問題が発生するアプリケーション プールのプロパティを開きます。
    2. [リサイクル] タブで、以下のチェック ボックスをオフにします。

      [ワーカー プロセスのリサイクル (分ごと)]
      [ワーカー プロセスのリサイクル (要求数)]
      [ワーカー プロセスのリサイクルを以下の時間に行う]
      メモリのリサイクル の [最大仮想メモリ]
      メモリのリサイクル の [最大使用メモリ]
    3. [パフォーマンス] タブで、以下のチェック ボックスをオフにします。

      [アイドルなワーカー プロセスの解放までの待ち時間]
      [CPU 管理を有効にする]
    4. [状態] タブで、[Ping を有効にする] チェック ボックスをオフにします。
    5. [OK] をクリックして、アプリケーション プールのプロパティを閉じます。
  2. System.OutOfMemoryException が発生したら Web サーバーに管理者権限でログオンし、コマンド プロンプトを起動します。
  3. Debugging Tools for Windows インストール ディレクトリに移動します。
  4. 次のコマンドを実行します。この操作により cdb.exe が起動し、ダンプ ファイルを作成します。

    Microsoft Windows 2000 Server の IIS 5.0、または Microsoft Windows Server 2003 の IIS 5.0 プロセス分離モードを使用している場合
    cscript.exe adplus.vbs -quiet -hang -pn aspnet_wp.exe

    Microsoft Windows Server 2003 の IIS 6.0 ワーカー プロセス分離モードを使用している場合
    cscript.exe adplus.vbs -quiet -hang -pn w3wp.exe

    ダンプ ファイルは、Debugging Tools for Windows のインストール フォルダ内の以下のフォルダに作成されます。拡張子は .dmp です。

    Hang_Mode__Date_MM-DD-YYYY__Time_HH-MM-SSSS
関連情報
IIS 上で動作する Web アプリケーションのトラブルシューティング、またはダンプ ファイルの取得方法については、次の「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。
929117 IIS 上で動作する Web アプリケーションの応答が停止する場合やエラーになる場合のトラブルシューティング
929118 IIS 5.0 上で動作する Web アプリケーションのダンプ ファイル取得方法
929119 IIS 6.0 上で動作する Web アプリケーションのダンプ ファイル取得方法
プロパティ

文書番号:954830 - 最終更新日: 10/18/2016 06:36:00 - リビジョン: 4.0

Microsoft ASP.NET 2.0, Microsoft ASP.NET 1.1, Microsoft ASP.NET 1.0

  • kbharmony kbhowto kbexpertiseadvanced KB954830
フィードバック