d99@Microsoft

ASP.NET 障害解析最初の一歩

d99 — Fri, 11 Dec 2009 09:09:03 GMT

こんにちわ d99 です。

弊社 technet のページで当チームで作成した WebCast が公開されました。

ASP.NET 障害解析最初の一歩
http://technet.microsoft.com/ja-jp/ee862421.aspx

非常に初歩的な内容ではありますが、是非ご覧頂ければ幸いです。5分に収まるように頑張ってはみたのですが、逆に10分になっちゃって前後編になってしまったというのはナイショです :-)

ではまた。
d99 でした。

ASP.NET と SQL Azure について

d99 — Fri, 20 Nov 2009 09:13:00 GMT

こんにちわ d99 です。
PDC で Azure のハナシが出て盛り上がっているようですね。

そういえば、つい先日以下のサポート技術情報がリリースされました。

Updated ASP.net scripts for use with Microsoft SQL Azure
http://support.microsoft.com/kb/2006191

こちらは、ASP.NET の各種機能（メンバーシップ、パーソナライズ、プロファイル、ロール、ヘルスモニリング）を、SQL Azure 相手に使う方法について、です。

これらの機能を使用する場合には aspnet_regsql.exe コマンドを使用しますが、このコマンドで実行される SQL スクリプトが SQL Azure 相手だと通らないため、新しいものをご用意した、という内容になります。

なお、sessionState については SQL Azure にストアする事は not support となりますのでご注意ください。SQL Azure にセッションを格納すると、セッションが Expire しなくなっちゃうのですが、逆にそれがいいという方は自己責任でご検討頂ければ、と :-)

ではまた。
d99 でした。

ASP.NET デッドロック検知機能について (1)

d99 — Tue, 10 Mar 2009 09:36:02 GMT

こんにちわ d99 です。
今回は、トラブルシューティングネタを取り上げます。今回のネタは、お問い合わせ頂く事も多いデッドロックです。

デッドロックといっても、実際には「以下のイベントログが記録されたんだけどどうすればいいの？」というものがほとんどですね。

IIS 5.x (Windows 2000, XP) の場合

種類 : エラー
ソース : ASP.NET <バージョン>
分類 : なし
イベント ID : 1003
日付 : yyyy/MM/dd
時刻 : HH:mm:ss
ユーザー : N/A
コンピュータ : <コンピュータ名>
説明 :
デッドロック状態である可能性があるため、aspnet_wp.exe (PID: xxx) が繰り返されました。この 180 秒間に保留中の要求に対して応答は何も送信されていません。

IIS 6.0 （Windows Server 2003）以降の場合

種類 : 警告
ソース : W3SVC-WP
分類 : なし
イベント ID : 2262
日付 : yyyy/MM/dd
時刻 : HH:mm:ss
ユーザー : N/A
コンピュータ : <コンピュータ名>
説明 :
次の理由のため、ISAPI 'C:\Windows\Microsoft.net\Framework\<バージョン>\aspnet_isapi.dll' は自身が危険な状況であると報告しました: 'デッドロックが検出されました'。

現象の詳細

このイベントログは、ASP.NET のデッドロック検知機能が動作した事を示しています。つまり、このイベントログを ASP.NET 君になったつもりで意訳すると、「ASP.NET アプリケーションが長時間無応答になってるよ？たぶんデッドロックだと思うから再起動しとくね～」という感じです。ですので、このイベントログが記録されたら、その aspnet_wp.exe や w3wp.exe はもう再起動されています。

また、このデッドロック検知機能は、何かのリソースに対するロックを監視していて「おっとデッドロック発生！」と具体的な何かを見つけて検知しているわけではありません。ある条件に従ってデッドロックの疑いを感知しているに過ぎません。その条件は以下の二つです。

responseDeadlockInterval （既定値3分）以上、ASP.NET アプリケーションが要求を受け取っているのに応答を返していない
リクエストの同時実行処理数が上限（ASP.NET 2.0 での既定値は 12 x CPU数）に達している

これは、例えば以下のようなシナリオを想定しています（下記は IIS 6.0 での場合です）。

あるリクエスト処理でデータベースへコマンドを実行するが、データベース側のなんらかの要因（デッドロック等）によってハングアップしてしまう
後続のリクエスト処理でも同じデータベースへのコマンドを実行して、1. の完了を待ってハングアップする。これがどんどん溜まっていく
そのまま誰も応答を返せず 3分が経過、かつ、ハングアップしたリクエスト数が 12xCPU数を超えた時点で ASP.NET はデッドロックを検知した旨を W3SVC に知らせ、イベントログに記録する
W3SVC は w3wp.exe が不健康とマークされた事を確認して、そのプロセスに対して終了依頼する
また W3SVC は（古いプロセスの終了完了を待たずに）新しい w3wp.exe を起動し、それ以降に到着したリクエストを新しいプロセスへルーティングする
終了依頼に応じない場合、アプリケーションプールの [ワーカープロセスをシャットダウンする時間] の設定値だけ待機した後、強制終了する。その際、強制終了した事をイベントログに記録する

IIS 6.0 では W3SVC が w3wp.exe を監視する、という仕組みになっているので上記のような動きになります。IIS 5.x でもこれに "準じた" 動きになっていると考えてください。ちなみに 5. は「オーバーラップドリサイクル」と呼ばれる、なるべくアプリケーションのダウンタイムを短くする動作ですね。これは w3wp.exe でも aspnet_wp.exe でも観測できます。

現象に関連する設定値

設定値 responseDeadlockInterval は、machine.config、processModel 要素の属性です。同時実行数の最大値も同要素の maxWorkerThreads とかで調整できるのですが、ちょっとややこしいので、一応その事が記載されているサポート技術情報だけご紹介しておきます（ASP.NET のスレッド制御についてはまた日を改めて書きたいと思います）。

.NET Framework 一般リファレンス - processModel 要素 (ASP.NET 設定スキーマ)
http://msdn.microsoft.com/ja-jp/library/7w2sway1.aspx

ASP.NET アプリケーションから Web サービス要求を行うと、競合、パフォーマンスの低下、およびデッドロックが発生する
http://support.microsoft.com/kb/821268/ja
-------------------
ASP.NET では、次の個数を超える要求は同時に実行されません。
(maxWorkerThreads*number of CPUs)-minFreeThreads
-------------------

もう一つ関連する設定値は、web.config の compilation 要素、debug 属性です。

.NET Framework 一般リファレンス - compilation 要素 (ASP.NET 設定スキーマ)
http://msdn.microsoft.com/ja-jp/library/s10awwz0.aspx

この要素が true だと、所謂スクリプトタイムアウトがおきません。ASP.NET のスクリプトタイムアウトは web.config ファイル、httpRuntime 要素の executionTimeout 属性で設定されていて、既定値は 90秒です。ですから、通常、処理に 90秒以上かかっていれば、これによってプロセスではなくスレッド（処理）が強制終了されて、プロセスが再起動する事は避けられます。

.NET Framework 一般リファレンス - httpRuntime 要素 (ASP.NET 設定スキーマ)
http://msdn.microsoft.com/ja-jp/library/e1f13641.aspx

ただし、この executionTimeout は、ASP.NET のページの処理、例えば TextBox に値を入れたり取り出したりといった処理中には発生し得るのですが、データベースにアクセス中とか、Web サービスや他のコンポーネントを呼び出し中、といった外部処理の完了を待っている最中には発生しません。ですので先ほどのようなシナリオでは executionTimeout が発生せず、結局デッドロック検知が作動してしまう事になります。

ただ、Visual Studio.NET 2003 ですと、自動的に生成される web.config で debug 属性が true なので、パフォーマンスが出なかったり、メモリ使用量が多めになってしまったりといったトラブルが起きるので、できれば false にして頂く事をおすすめしています。

次のアクション

ASP.NET 1.0 の初期には「デッドロック誤検知」の障害があったのですが（サポート技術情報 321792）、わりと早い段階で修正されてしまったので、このイベントログが出てるという事は即ち、アプリケーションがどこかの処理でハング（応答停止）してしまっていると言える場合が多いですね。

エラーに至る仕組みはわかったけど、で、どうすんだ？、という事になるかと思うのですが、基本的にはデバッグで「詰まった処理」を特定する必要があります。アプリケーションのログ機能等から特定していく、というのが一般的なようですが、ログ機能がない、カスタムログから特定できない、なぜか本番運用中にしか出ない等々の事情がある場合には、それも難しいかと。

というわけでそんな場合は運用デバッグの出番になるわけですが、まずは次回のエントリで意図的にデッドロック検知を起こさせる方法をご紹介しようかと思います。そして、それを使って次々回に実際にデバッグしてみる、といった感じで進めましょう。ご期待ください。

ではまた。
d99 でした。

[連載] ASP.NET 運用デバッグ入門 3) メモ帳をデバッグ

d99 — Mon, 02 Mar 2009 11:32:00 GMT

こんにちわ、d99 です。

さて、前回の連載エントリでデバッガ（windbg.exe）の動作確認まで行いました。予告通り、引き続いてメモ帳をデバッグしてみましょう。

- 前提条件

1) Debugging Tools for Windows がインストールされている

インストール方法については [以前のエントリ] を参照してください。

2) インターネットにアクセスできる

今回はシンボルを使いますが、それをインターネット経由でダウンロードします。ですので、デバッグするマシンはインターネット（HTTP）にアクセスできる状態にしておいてください。

3) 二つのファイルを用意

テキストファイルを二つ用意します。C ドライブのルートに test.txt （C:\test.txt）、D ドライブのルートにも test.txt （D:\test.txt）を用意しましょう。中身はそれぞれのファイルのフルパスを書いて、区別が付くようにしてください。なお、1 ドライブ環境であれば、どこかのフォルダを共有して、それをネットワークドライブで適当なドライブ（例えば Y: とか）に割り当てておくといいと思います。その場合は以降の D: をそのドライブ名に読み替えてください。

- デバッグ手順

1) メモ帳を起動します。

2) デバッガを起動し、アタッチします。プログラムメニューから、[Debugging Tools for Windows] - [windbg] を起動します。[File] メニューから [Attach to a Process] を選択し、出てきたダイアログで、[notepad.exe] を選び、[OK] を押します。

3) [Save information for workspace] といったダイアログが出る場合がありますが、[No] で構いません。

4) デバッガがプロセスにアタッチされます。ブレークしますので、[GO] します。前回解説したように、[Command] 子ウィンドウを最大化してから 0:0nn>（n は任意の数字）と出ているプロンプトに g と入力して Enter を押下しましょう。

5) メモ帳を操作します。[ファイル] - [開く] で c:test.txt を選びますが、[開く] ボタンはまだ押しません。

さて、今回どのようにメモ帳を改造するかというと、「C ドライブのファイルを開こうとしても D ドライブのファイルが開かれる」という状態を目指します。

そもそも論になってしまうのですが、アプリケーションとはシステムコールをしながら動作しています。つまり、非常におおざっぱに言うと、アプリケーションが直接 HDD のドライバやコントローラーに命令してファイルを開いているのではなく、OS に対して「オイ、このファイルくれよ」とシステムコール＝ Windows API を呼び、その結果ファイルを受け取っています。これは Windows 上のアプリケーションであれば、どんな言語で書いても結局同じです。ですので「ファイルを開く」という時に使われる Windows API を知っておけば、そのアプリケーションが C で書かれていようが、VB で書かれていようが、C# で書かれていようがそのあたりをデバッグできる事になります。

そこで今回着目するのは、「CreateFile」という API です。詳細は下記リファレンスを見ていただくとして、要はファイルを開く時にそのファイルハンドルを得るための API です。イマイチよくわからなければ「ファイルを開く時はこの API が呼ばれるんだな」くらいの認識で構いません。

プラットフォーム SDK - CreateFile 関数
http://msdn.microsoft.com/ja-jp/library/cc429198.aspx

デバッガでメモ帳がこの API を呼ぶところをひっつかまえ、この第一引数のファイル名をちょちょいと書き換えてやろう、というのが今回の目標になります。

6) デバッガをブレークします。上部にあるポーズマークのボタンをクリックしてもいいですし、Ctrl+Break キーを押下してもかまいません。

7) まずはシンボルを設定します。シンボルはこれもまた大雑把に言うと :-)、バイナリファイルの内部情報を記したファイルです。今回の作業では実際には不要ですが、今後のためにここでやっておきましょう。デバッガで [File] - [Symbol File Path] を選び、出てきたウィンドウに以下を入力し、[Reload] にチェックを入れて、[OK] を押します。この操作によって、Windows 関連等のシンボルが自動的にインターネットからダウンロードされます。毎回ダウンロードしなくて済むように、C:\Windows\Symbols にキャッシュされます。もし C ドライブの空き容量が少ない場合は適宜変更してください。

SRV*c:\windows\symbols*http://msdl.microsoft.com/download/symbols

8) 次に、先ほど g と入力した [Command] 子ウィンドウにて以下のコマンドを入力します。特にエラーが出なければ問題ありません。CreateFile じゃなくて CreateFileW なの？という疑問を持たれた方もいらっしゃるかと思いますが、Unicode 版と ANSI 版があって、Unicode 版が W が付いてる、という大雑把な理解で構いません。

bp kernel32!CreateFileW

9) g コマンドを入力し、メモ帳を動かします。先ほど開いていたダイアログで [開く] を押してください。

10) すると、デバッガがブレークします。つまり CreateFileW で止まった、という事です。メモ帳はデバッガでブレークされるので、画面描画が更新されなくなります。"Breakpoiint 0 Hit" と出て、kernel32!CreateFileW で止まった事が示されます。引数を見てみましょう。kvn とコマンドを入力してください。以下のようなスタックバックトレースが表示されます。

0:000> kvn
 # ChildEBP RetAddr  Args to Child              
00 0007fb14 01002dd0 0007fb98 80000000 00000003 kernel32!CreateFileW (FPO: [7,23,0])
01 0007fda4 01003947 00050126 00000002 00000000 notepad!NPCommand+0x229 (FPO: [3,152,4])
02 0007fdc8 77eab6e3 00050126 00000111 00000002 notepad!NPWndProc+0x4fe (FPO: [4,2,0])
03 0007fdf4 77eab874 01003449 00050126 00000111 USER32!InternalCallWinProc+0x28
04 0007fe6c 77eaba92 00000000 01003449 00050126 USER32!UserCallWinProcCheckWow+0x151 (FPO: [SEH])
05 0007fed4 77eabad0 0007fefc 00000000 0007ff1c USER32!DispatchMessageWorker+0x327 (FPO: [SEH])
06 0007fee4 01002a32 0007fefc 00000000 ffffffff USER32!DispatchMessageW+0xf (FPO: [1,0,0])
07 0007ff1c 01007527 01000000 00000000 000a24b2 notepad!WinMain+0xdc (FPO: [4,8,0])
08 0007ffc0 7c82f23b 00000000 00000000 7ffdf000 notepad!WinMainCRTStartup+0x182 (FPO: [SEH])
09 0007fff0 00000000 010073a5 00000000 78746341 kernel32!BaseProcessStart+0x23 (FPO: [SEH])

これがブレークした際の、スタックバックトレース（呼び出し履歴）です。下から上に呼び出しが行われています。一番下が BaseProcessStart でプロセスが始まってる感じ（ｗ、ですね。そして色々あってから notepad から CreateFileW API が呼び出されて、ブレークという感じです。まだ今は「へー」くらいで構いません。また、引数は [Args to Ｃｈｉｌｄ] というところに出ています。先ほどの CreateFile API のリファレンスを見ると、第一引数がファイル名らしいので、上記で言えば [0007fb98] に Unicode の文字列が入っているはずです。中身を見てみましょう。

11) du [第一引数のアドレス] と入力します（Unicode 文字列を表示するコマンドです）。C ドライブの test.txt を開こうとしています。しめしめ

0:000> du 0007fb98 
0007fb98  "C:\test.txt"

12) おもむろにこの文字列冒頭を書き換えてしまいましょう。eu [書き換えるアドレス] [文字列] と入力します。NullTerminate する必要はありません。

0:000> eu 0007fb98 "D:"

13) 一応先ほどのコマンドで、書き換わっている事を確認します。確認できたら g します。

0:000> du 0007fb98 
0007fb98  "D:\test.txt"

0:000> g

いかがでしょうか？C ドライブのテキストファイルを開こうとしたのに、D ドライブのファイルが開かれていませんか？当チームでも、新人さんにデバッガの使い方を教える時は「まずメモ帳を開いてみろ」から始まる事が多いので、あんまり ASP.NET とは関係ないのですが、紹介してみました。ついでにオマケをつけておきます。

14) 一旦デバッガでブレークして、以下のコマンドを入力します。同じブレークポイントなので redefine = 再定義されます。bp = ブレークポイントを設定するコマンドには「ブレークした時にどんなコマンドを実行するか」を引数で設定できます。CreateFileW で止まるたびにメモリを書き換えているので、このコマンドを打った後はずっとメモ帳は「C ドライブのファイルを開こうとしても D ドライブのファイルが開かれてしまう」という状態になります。

0:001> bp kernel32!CreateFileW "eu eax \"D:\";g"
breakpoint 0 redefined

eax は何かって？レジスタ、というとお分りいただける方もいらっしゃるかと思いますが、ピンとこない方は r というコマンドの結果と、先ほどの kvn の結果をよく見比べてみてください。同じアドレスが出ているところがありませんか？正確に説明すると呼び出し規約とかコマカイところになってしまうので、今はこれも「へー」でも構いません。また、実行ファイル自体を書き換えているわけではないので、デバッガとメモ帳を終了してしまえば元通りです。ご安心を。

- まとめ

ざっと windbg の使い方というか、使っている風景、をご覧いただけたかなと思います。実際にはライブデバッグ（プロセスが動いている状態）なら、Visual Studio 使った方が速いのですが、まぁ windbg 君の本領発揮はまだまだこれから、という事でご期待いただければ、と。

なお「あれ？これって言わばメモ帳を改造しちゃってるんじゃね？」と思われた方もいらっしゃるかと思います。そうですね、改造というとおこがましいですが、そんな感じかもしれません。そのため、同じように「プロセスにデバッガをアタッチして××するとこんな事が！」というネタは結構紹介されていたりします。今回はスペースの都合上詳しい手順はご紹介しませんが、もし興味のある方は下記リンクのマインスイーパーをデバッグしちゃうのなんか、面白いと思いますよ :-)

[Windbg Script] Playing with Minesweeper
http://blogs.msdn.com/debuggingtoolbox/archive/2007/03/28/windbg-script-playing-with-minesweeper.aspx

- 次回予告

次は、いよいよ ASP.NET でもうすこし実践的な事例を取り上げます。そして、なぜ Visual Studio ではなくて windbg が ASP.NET の役にたつのか、をご紹介する予定です。

ではまた。
d99 でした。

[連載] ASP.NET 運用デバッグ入門 2) デバッガの動作確認

d99 — Fri, 22 Aug 2008 09:39:00 GMT

こんにちわ、d99 です。

さて、前回の連載エントリで Debugging Tools Windows のインストールまでを解説しました。今回は、さらにそれを使ってちょっとしたデバッガの "動作確認" をしてみましょう。

- 用意するもの

1) テスト用 IIS

なければ Visual Studio 付属の ASP.NET 開発サーバでも構いません。IIS をお使いの際には、アプリケーションを作成しておいてください。また、ASP.NET を動かすので、.NET Framework のインストールがもちろん必要です。バージョンは特に問いません。

2) 以下のコードを記述したページ

System.Diagonostics.Debug.WriteLine("hoge");

Visual Studio をお使いの場合は、Page_Load あたりにでも上記の一行を記述してください（C# です）。もしくは以下の一行だけのテキストファイルをテキストエディタで作成して、アプリケーションフォルダに置くだけでも構いません。

<%  System.Diagonostics.Debug.WriteLine("hoge") %><% 	System.Diagonostics.Debug.WriteLine("hoge") %>

3) 以下の内容の web.config

 <compilation debug="true" />

Visual Studio をお使いの場合は、プロジェクトに [Web 構成ファイル] を追加し、上記の行があると思いますので、false を true へ書き換えてください。テキストエディタ党 :-) の方は、以下の web.config をアプリケーションフォルダに置いてください。

 <?xml version="1.0" encoding="utf-8"?>
 <configuration>
    <system.web>
        <compilation debug="true" />
    </system.web>
 </configuration>

4) そしてもちろん Debugging Tools for Windows

インストール方法については [前回のエントリ] を参照してください。

- 動作確認手順

1) まずは、[用意] の 2) で作成したページをブラウザで見てみましょう。ブラウザで要求するか、Visual Studio の方は Ctrl + F5 で [デバッグなしで実行] します。真っ白なページなので、特に何も画面には表示されません。

※ Debug.WriteLine() メソッドは、デバッガに文字列を出力するメソッドなので、デバッガがなければ何も起きません。Visual Studio で [デバッグ実行] している場合は [出力] タブに hoge と表示されます。デバッグ時のちょっとした内部変数の確認などで便利なメソッドです。

2) デバッガを起動し、アタッチします。プログラムメニューから、[Debugging Tools for Windows] - [windbg] を起動します。[File] メニューから [Attach to a Process] を選択し、出てきたダイアログで、適切なプロセスを選び、[OK] を押します。

IIS 5.x（Windows 2000、Windows XP）の場合
aspnet_wp.exe

IIS 6.0、7.0（Windows Server 2003、2008、Windows Vista）の場合
w3wp.exe

ASP.NET 開発サーバの場合
WebDev.WebServer.exe

※ コマンドライン派 :-) の方は、デバッガをインストールしたフォルダに移動し、以下のコマンドを実行してください。これは「既に起動している指定の名前のプロセスにデバッガをアタッチする」起動オプションになります。この指定方法の場合、同名のプロセスが複数起動していると全てにアタッチされてしまうので、その点だけ注意してください。

windbg -pn 上記プロセス名

3) [Save information for workspace] といったダイアログが出る場合がありますが、[No] で構いません。

4) デバッガがプロセスにアタッチされます。ブレークしますので、[GO] します。メニューやボタン、F5 キーなどでもいいのですが、やや玄人っぽく [Command] 子ウィンドウを最大化してから 0:0nn>（n は任意の数字）と出ているプロンプトに g と入力して Enter を押下します

5) ブラウザを [再読み込み] します。デバッガにいろいろなログが出る場合もありますが、それに混じって「hoge」という行が表示されるのがご確認頂けるかと思います。

- 考察

このようにアプリケーション自体にデバッガを意識したコードを書くことで、この windbg とかいうツールも "デバッガ" として動作している事が御確認頂けたかと思います。まぁ、当たり前なんですが :-)。

web.config をいじっている点からもお分かりいただけるように、debug="false" ではこの出力は行われません。コードだけ仕込んでおいて、何か起きたら debug="true" にしてデバッガをアタッチしログを確認する、なんて事も出来そうですね。Visual Studio を運用環境に入れるのは難しいと思いますが、Debugging Tools for Windows であればフォルダコピーでいいし、windbg なら Visual Studio よりは軽いので扱いやすいかなと思います。

なお、windbg.exe を使っていますが、ほぼ同機能のコマンドラインデバッガ、cdb.exe も Debugging Tools for Windows には含まれています。コマンドライン派の方はそちらをお試しください。コマンドは同じものが使えます。

- 次回予告

次は、もうちょっと下層を見てみたいと思います。

今は C# や VB.NET のプログラムコードのレベルで見ていますが、それが OS に伝わるまでにはいくつかの伝言ゲームが行われます。その伝言ゲームの過程、OS に伝わるところでは Windows API という必ず決まった出入り口を通過します。ですので、ここを覗き見れば別に自分が作ったアプリケーションじゃなくても、マネージドでもアンマネージドでも、元々のソースコードが C# でも VB.NET でも VB6 でも「ははーん、概ねこんな事してるんだな」というのは伺い知れる事になります。デバッグにはこの「ははーん」というのがわりと重要だったりしますので。

ではまた。
d99 でした。

Aspnet_regiis.exe って何してるの？

d99 — Mon, 07 Apr 2008 05:45:00 GMT

こんにちわ。d99 です。
図つきでなくて申し訳ないのですが。。。:-)

[トラブルシュート][ASP.NET]Temporary ASP.NET Files' への書き込みアクセスが与えられていません。の対処方法
http://blogs.wankuma.com/ogiogi/archive/2008/03/11/127161.aspx

aspnet_regiis
って、いろいろ裏でなんかしてますよ・・・・
詳しくご存じの方は、ぜひ図つきの解説をトラックバックしていただけるとｗｗ（ぼそ）

ASP.NET 登録ツール（aspnet_regiis.exe）を -i オプションで実行すると、イベントログの [アプリケーション] に以下のようなログが残ります。

ソース：ASP.NET 2.0.50727.0
イベント ID：1019
ASP.NET (バージョン 2.0.50727.0) の登録を完了します。登録ログの詳細は、C:\DOCUME~1\<ユーザー名>\LOCALS~1\Temp\ASPNETSetup.log で確認できます。

ソース：ASP.NET 1.1.4322.0
イベント ID：1019
ASP.NET (バージョン 1.1.4322.0) の登録を完了します。登録ログの詳細は、C:\Users\<ユーザー名>\AppData\Local\Temp\ASPNETSetup.log で確認できます。

前者は Windows Server 2003 に ASP.NET 2.0 をインストールした場合、後者は Windows Server 2008 に ASP.NET 1.1 をインストールした場合です。OS のメジャーバージョンが異なるため、ユーザーの Temp パスが違っていますね。Windows Server 2003 では 8 3 形式になってしまっていますが、フルパスは c:\Documents and Settings\<ユーザー名>\Local Settings\Temp です。なお、同名のセットアップログが既にある場合には、ASPNETSetup_00001.log というように、連番が付与されます。

このセットアップログですが、中身を見ていただければざっとの内容はご理解いただけると思いますが、一応主要なものだけ以下にまとめてみました（Windows Server 2003 + ASP.NET 2.0 の場合です）。

IIS の稼動を確認（Starting Querying status of a service: iisadmin）
ASP.NET のバージョンを確認（Starting Determining if current ASP.NET isapi has the highest version）
ASP.NET 状態サービスを停止（Starting Stopping service: aspnet_state）
IIS メタベース（※）を更新（Starting Update IIS Metabase to use this ASP.NET isapi）

MIME マップ（.aspx 等の関連付け）
InProcessIsapiApps （ISAPI の動作モード）設定
ISAPI Filter （aspnet_filter.dll）インストール
カスタムヘッダ（X-Powered-By ASP.NET）設定

ASPNET アカウント作成（Starting Creating ASPNET account）
ASPNET ユーザに必要なアクセス権等を設定（Starting Setting ACLs for the ASPNET account）
IIS6ユーザ（NETWORK　SERVICE）に必要なアクセス権を設定（Starting Setting WMI ACLs for a IIS6 account）
ASP.NET 状態サービス（aspnet_state.exe）をインストール（Starting Install all ASP.NET Services）
クライアントスクリプト（Validation コントロール等）インストール（Starting Setting up client script files for website:*）
W3SVC（IIS）を再起動（Starting Restarting W3SVC）

※ IIS メタベース（設定情報）は %WinDir%\System32\inetsrv\MetaBase.xml に保存されます

以上のように結構多岐に渡る内容をいじっています。もし「セットアップ/初期設定がうまくいっていないんじゃ？」と疑っている時はこのログを是非ご活用ください。少なくとも、aspnet_regiis を実行した結果ここにエラーが出ていないのであれば、セットアップ/初期設定周りに関する問題ではない、という事が切り分けできるかと思います。

.NET Framework ツール ASP.NET IIS 登録ツール (Aspnet_regiis.exe)
http://msdn2.microsoft.com/ja-jp/library/k6h9cz8h.aspx

設定周りのトラブルには、aspnet_regiis と aspnetsetup ログ、是非ご活用ください（aspnet_regiis をご紹介し、改善する事例はとても多いです）。
d99 でした。

[連載] ASP.NET 運用デバッグ入門 1) デバッガのインストール

d99 — Tue, 01 Apr 2008 06:56:00 GMT

こんにちわ、d99 です。

新年度 4月も始まる事ですし、これから何回かに渡り「ASP.NET Debugging 入門」と題して、ASP.NET アプリケーション運用デバッグのために、基本的なデバッガ等の使い方に関する内容を連載させて頂きます。何度か挫折を繰り返してしまっているこの blog ですが、何とか頑張ってみたいと思います。

この連載を通して、例えば「運用環境でサーバから応答がない！」とか「サーバで例外が出てるみたいなんだけど発生要因が分からない。。。」とか、そんな時の手段の一つに運用デバッグを加えて頂ければ幸いです。なお、途中までは単に「デバッガの使い方」になると思うので、通常のデスクトップアプリケーションやサービスなど、ユーザーモードアプリケーション全般に使える部分もあると考えています。

1. デバッガのインストール

今回は、デバッガのインストールについて解説します。もちろんデバッガとして、Visual Studio や Visual Web Developer でも良いのですが、運用環境にそれらをインストールするのはあまりに大仰ですし、いざ現象が起きてからインストールする、というのも無理がありますよね？

もっと軽量で、フォルダのコピーでもインストール出来て、より運用環境等での使用に適したデバッガとして、弊社では「Debugging Tools for Windows」というデバッガツール群をリリースしています。今連載ではこの中に含まれる windbg というデバッガを主に使っていきます。ではインストールをステップバイステップで見てみましょう。

1) ダウンロード

Debugging Tools for Windows は以下からダウンロードできます。

Debugging Tools for Windows 32 ビットバージョンのインストール
http://www.microsoft.com/japan/whdc/devtools/debugging/installx86.mspx

（図ダウンロードサイト）

[Debugging Tools for Windows のダウンロード] の [最新リリース] をダウンロードしましょう。なお、デバッガは少なくとも1年に1回程度はバージョンアップしていますので、もし 6.4 以前のバージョンをお使いの場合にはこの機会に新しいバージョンをご検討ください。また、64 ビット版は右にある [Debugging Tools 64 ビットバージョン] のリンクをご利用ください。

実は、右側 [概要] のリンクからこのツールの概要を見ていただくと、「Windows 用デバッグツール (Debugging Tools for Windows) は　（中略）　ドライバ、アプリケーション、サービス、およびオペレーティングシステム自体をデバッグするのに使用できます」と書いてあります。そう、このツールはデバイスドライバのデバッグにも使用できます。ブルースクリーンで生成されるカーネルダンプの解析や、シリアルポートなどを経由して OS 自体のデバッグ（カーネルデバッグ）にも使用可能です。

2) セットアップ

ダウンロードした MSI ファイルを実行してインストールを行います。なお、この場合、インストール後に再起動が必要となる場合があります。再起動を避けたい場合には別のマシンにインストールした後、インストールされたフォルダごと該当のサーバへコピーする、という方法でも構いません。

以下に、各ステップの画面を掲載しました。基本的には [Next] を選択していくだけです。インストールパスは、デフォルトの Program Files の下にインストールしています。ちなみに、このツール群はコマンドプロンプトから使う事も多いので、弊社内では CUI 操作のしやすい <システムドライブ>:\debuggers にインストールするエンジニアが多いようですが、私は既定のパスで使っています :-)

なお、64 ビット（x64）環境にインストールする場合は、64 ビット版 Debugging　Tools for Windows は "<システムドライブ>:\Program Files\Debugging Tools for Windows (x64)" に、32 ビット版は "<システムドライブ>:\Program Files (x86)\Debugging Tools for Windows (x86)" が既定のインストールパスになります。こうなるとさすがにちょっと長いですね。。。

（図 MSI ファイル実行後の画面）

（図ライセンス画面）

（図名前および組織名入力画面）

（図セットアップタイプの選択画面）

（図インストールパスの入力画面）

（図セットアップ開始画面）

（図セットアップ終了画面）

3) 確認

セットアップ出来た事を確認するために、windbg を起動してみましょう。スタートメニューの [プログラム] - [Debugging Tools for Windwos] - [windbg] または、インストールしたフォルダ内の windbg.exe を起動します。

（図 windbg 起動画面）

無事上記のウィンドウが表示されればセットアップ成功です。閉じると下記ダイアログが表示されますが、[No] で構いません

（図ワークスペース保存確認ダイアログ）

次回はこの windbg を使ってちょっと遊んでみたいと思います。お楽しみに。
d99 でした。

システムトラブルのパターン

d99 — Mon, 27 Aug 2007 05:31:00 GMT

こんにちわ、d99 です。

随分間があいてしまいました。
今回はシステムトラブルにはどんなパターンがあるか、について考えてみたいと思います。

運用段階にあるシステムに発生するトラブルは、その見え方によっていくつか典型的なパターンがあり、その内のいくつかには原因追及の手順がある程度確立されているように思います。まずは（追及手順はひとまず置いておいて）、どんなパターンがあるかを考えつつまとめてみました。

- クラッシュ（crash）

"落ちる" という現象、つまり異常終了してしまうというトラブルです。

Windows オペレーティングシステム自体の異常終了は、ブルースクリーンが該当します。システム自体ではなくアプリケーションが異常終了すると、一般保護違反といったエラーダイアログが出たり、エラー報告しますかと聞かれたり、ワトソン博士がお出ましになったり :-)、開発環境がインストールされていればデバッグするかといったダイアログが表示されたりします。サービスプロセスの場合はダイアログが出せないため、イベントログになんらかのログが残る事（残るように実装されている事）が多いと思います。

アプリケーション自身がうまくハンドリングできなかったとしても、基本的にはシステムがプロセスの異常終了をログオンユーザーに伝えようとします。まれになんの痕跡も残さず終了してしまう事もありますが、それはシステムが用意している異常終了時の処理がなんらの理由で実行できなかったか（できないほど深刻な異常だった、もしくはデバッガなどの介入を防ぐようにアプリケーションが作られていた、など）、異常終了に見えても実際には正常終了だったか、後は電源ケーブルが抜けたか :-) くらいしか考えられません。

- ハング (hang)

"止まる" という現象、応答がなくなるというトラブルです。ハングには2種類あり、それぞれコールドハング（cold hang）とビジーハング（busy hang）と呼ばれます。

コールドハングは、内部でデッドロック（Aの処理がBの処理完了を待っているが、Bの処理もAを待っているといった状態）などが発生し、処理はまったく行っていないが応答を停止している状態です。

これに対してビジーハングは、その名の通り CPU がガンガン回っているだけで応答が返ってこない状態です。無限ループしている事もありますし、他の処理が忙しくて応答を返せないといった状態もあります。

- 例外（exception）もしくは意図しない動作

クラッシュするわけでもなく、ハングするわけでもない、しかし例外が発生したり、意図しない結果となるという場合は "それ以外" に分類してみました :-) 。"トラブル" とは基本的に "意図しない現象の発生" かと思いますのでこういった分類名をつけました。

ここでは３つの分類を挙げてみました。

運用中に突然発生したトラブルにあたる時は、まずはこのどれか、正確には前者二つがどこかで起きていないか、を私は疑います。これは小さなデスクトップアプリケーションでも、何台ものマシンで構成されたクラスタシステムでも同様です。これは前者二つであれば "いつもの手順" が使えるからなのですが、それについてはまた回を改めてまとめてみたいと思います。

d99 でした。

マイクロソフトサポートでの私の仕事

d99 — Thu, 02 Aug 2007 07:50:00 GMT

こんにちわ！d99 です。

よくよく考えてみると、技術的な分野をお伝えしないといったいどんなブログなのかまったく分からないですよねぇ。というわけで、前回のご挨拶に引き続き自己紹介を。

私が所属するサポートチームでは、Web 系のシステム、つまり Internet Infomation Service (IIS)、その上で動く ASP、ASP.NET を核に、関連するサーバ製品群を担当しています。

こういったコードを書くとエラーになる、意図した動きをしない、こういう公開関数はあるか、といった開発フェイズでのご質問や、突然ユーザーアプリケーションが落ちた、サーバから応答がない、負荷が跳ね上がったというような運用フェイズでのご質問を頂きます。

そんなチームで、私は監察医のような事を主にやっています。

死体を見て死因を判断する。つまりシステムに問題が発生した際に、その時の情報を解析し、問題の原因にアタリを付けるという事です。いわゆる運用デバッグに当たるのですが、マイクロソフトサポートメニューの中でも上位のご契約が必要な事、技法に関する日本語のドキュメントが少ない事などから、それほど一般的には知られていないように思います。

私はあまり設計やコーディングなどの高尚なお話し等には詳しくないのですが、サポートでの経験からシステムのトラブルシューティングについてや（troubleshooting タグ）、Web サーバのダンプファイルばかり年間数百本ほど見ていますのでその技術について（debugging タグ）、少しお話しができるかと思います。

また、そんな私だけでは心もとないので、今回ブログを始めるにあたり Doug、Tess、Todd、Jerry などのいわば "デバッグマスター" のような人達や、Scott、Maoni など開発のアーキテクト達に、彼らのブログエントリの翻訳をしてもよいか聞いてみました。皆に快諾してもらえたので、彼らのエントリを日本語化しつつ（恐らく私の訳はかなり意訳になると思いますが）、日本でよく見られた問題などをご紹介できればと考えています。また、こういったトラブルシューティング方法があるといいなぁといったアイディアなどがありましたら是非教えてください。

よろしくお願いします。

d99 でした。

ご挨拶

d99 — Thu, 26 Jul 2007 08:53:00 GMT

初めまして！d99 です。

私はマイクロソフト株式会社グローバルテクニカルサポートセンターのエンジニアです。技術専門分野や得意技 :-) などの細かい点については、これからここでお伝えしていきたいと考えています。

今現在、日本のマイクロソフトで、エンジニアという単語が付く職種の人間が blog を書いているのはもしかすると珍しいのかもしれません。そんな事もあってやや緊張気味ですが、まぁあまり肩肘張らず気楽な感じで続けていければいいな、と思っています。

ちなみにペンネームなのはちょっと恥ずかしいから、、、というだけなので、いずれはどこの誰なのかをこっそり about あたりに書いておくかもしれません。

これからもよろしくお願いします。

d99 でした。

d99@Microsoft

ASP.NET 障害解析 最初の一歩

ASP.NET と SQL Azure について

ASP.NET デッドロック 検知機能について (1)

IIS 5.x (Windows 2000, XP) の場合

IIS 6.0 （Windows Server 2003） 以降の場合

現象の詳細

現象に関連する設定値

次のアクション

[連載] ASP.NET 運用デバッグ入門 3) メモ帳をデバッグ

- 前提条件

1) Debugging Tools for Windows がインストールされている

2) インターネットにアクセスできる

3) 二つのファイルを用意

- デバッグ手順

- まとめ

- 次回予告

[連載] ASP.NET 運用デバッグ入門 2) デバッガの動作確認

- 用意するもの

1) テスト用 IIS

2) 以下のコードを記述したページ

3) 以下の内容の web.config

4) そしてもちろん Debugging Tools for Windows

- 動作確認手順

- 考察

- 次回予告

Aspnet_regiis.exe って何してるの？

[連載] ASP.NET 運用デバッグ入門 1) デバッガのインストール

1. デバッガのインストール

1) ダウンロード

2) セットアップ

3) 確認

システムトラブルのパターン

- クラッシュ（crash）

- ハング (hang)

- 例外（exception）もしくは意図しない動作

マイクロソフト サポートでの私の仕事

ご挨拶

ASP.NET 障害解析最初の一歩

ASP.NET デッドロック検知機能について (1)

IIS 6.0 （Windows Server 2003）以降の場合

マイクロソフトサポートでの私の仕事