d99@Microsoft https://docs.microsoft.com/archive/blogs/d99/feed.xml Azure AppService, ASP.NET, IIS などの Web 系トラブル シューティングにまつわるアレコレについてお届けします Mon, 18 Dec 2017 12:14:44 GMT ja hourly 1 [Advent Calendar 2017 Day18] Azure Web Apps パフォーマンスチューニング https://docs.microsoft.com/archive/blogs/d99/azure-web-apps-perf Mon, 18 Dec 2017 20:56:54 GMT https://blogs.msdn.microsoft.com/d99/?p=565 こちらの記事は、Qiita に掲載した Microsoft Azure Tech Advent Calendar 2017 の企画に基づき、執筆した内容となります。 カレンダーに掲載された記事の一覧は、こちらよりご確認ください。   こんにちは。 d99 です。 今回は Azure のアドベントカレンダーという事で、Azure で動く Web アプリケーションのパフォーマンスボトルネックを見つける手順をご紹介します。  

1) Azure で簡単な php コードを動かす

まずは、Azure App Service を作成し、以下のような sleep.php を置きました。パッと見て分かる通り、QueryString に id=3 と渡されたら5秒スリープする、というコードです。既に種明かししてますが。 [php] &lt;?php if ( $_REQUEST['id'] == 3) { sleep(5); echo('sleeped'); } else { echo('done'); } ?&gt; [/php] この程度のファイルを配置するのであれば、kudu コンソール（https://<Web Apps 名>.scm.azurewebsites.net/DebugConsole にアクセスし、D:\home\site\wwwroot に移動してから、上の [+] マークから [New file] を選択してファイル作成、鉛筆マークの [Edit] アイコンから直接書いてしまうのが簡単だと思います。 私は、デスクトップにエディタでさらさらっと書いて、下記赤枠のところにポイっとドラッグ・アンド・ドロップしました。  

2) クライアントからリクエストを送る

次にクライアントからリクエストを送りまくります。今回は C# の コンソール アプリケーションで以下のような簡単なコードを書いて、毎秒ごとにパラメーター id をずらしながら、60秒間リクエストを送ってみます。 [c language="#"] while (starttime.AddSeconds(60 * 1000) &gt; DateTime.Now) { System.Net.Http.HttpClient h = new HttpClient(); uri = new System.Uri(args[0] + "?id=" + (DateTime.Now.Second % 4).ToString()); var r = h.GetAsync(uri); r.Wait(); Console.WriteLine(r.Result.StatusCode); System.Threading.Thread.Sleep(1000); } [/c]  

3) ETW を採取する

sleep.php やコンソールアプリケーションがきちんと動く事を確認したら、コンソールアプリケーションを動かしながら ETW トレースを取ってみましょう。   テスト段階で PHP のホストプロセス、php-cgi.exe は起動していると思うので、kudu の Process Explorer（https://<Web Apps 名>.scm.azurewebsites.net/ProcessExplorer/）を表示すると、php-cgi.exe が見えると思います。[Collect IIS Events] にチェックを入れた上で、[Start Profiling] をクリックします。そして、コンソールアプリケーションからリクエストを送りまくりましょう。 なお、以下のような注意書きが出ますのでご確認頂いた上で、[Yes] をクリックします。この後、[Start …] が [Stop Profiling] に変わり、色が赤くなりますので、コンソールアプリケーションを一分ほど動作させたら、そちらをクリックして止めます。少し待つと、～.diagsession というファイルがダウンロード出来ますので、ローカルに保存します。  

4) 遅いリクエストを見つける

ETW の解析には、PerfView を使用します。以下からダウンロードして展開します。

PerfView https://www.microsoft.com/en-us/download/details.aspx?id=28567

PerfView の使い方は以下を見てみてください :-)

PerfView Tutorial（英語） https://channel9.msdn.com/Series/PerfView-Tutorial

ハードコア デバッギング～Windows のアプリケーション運用トラブルシューティング実践 https://channel9.msdn.com/events/de-code/2017/MR15

今回の場合は、まず PerfView の左側ツールで .diagsession ファイルが置かれたフォルダまで移動し、当該ファイルをダブルクリックします。少し待つと .etl が展開されますので、その中の [Events] をダブルクリックします。取得された ETW のイベントが全てここで確認出来ます。 左側の [Event Types] で [IIS_Trace/IISGeneral/GENERAL_REQUEST_START] をクリック、さらに Ctrl を押しながら [IIS_Trace/IISGeneral/GENERAL_REQUEST_END] をクリックしてから、Enter キーを押します。これが、リクエストの入りと出の一覧なのですが、これだとなんだかわかりませんね。 右上の [Cols] をクリックし、Ctrl を押しながら、ContextId、DURATIOIN_MSEC、RequestURL、ThreadID をクリックしていき、最後に Enter を押します。すると、DURATION_MSEC つまり経過時間（ミリ秒）が別欄になりますのでわかりやすくなります。ざーっとスクロールしていくと。。。ありました。5,000 ミリ秒、つまり 5秒 かかっているリクエストです。ContextId がリクエストに付けられる一意な ID ですので、少し上の START と見比べると、sleep.php?id=3 の処理、という事が分かります。 さらに追い込みます。その列の ContextId をクリックしてコピー、上部 [Text Filter] にペーストします。Cols の右の内容を消した上で、さらに、左側では IIS_Trace で始まるものをすべて、Shift キーを押しながら範囲選択して Enter を押します。ここで出てくるのは、IIS の [失敗した] 要求トレース、とほぼ同じものですので、リクエストが入り乱れている場合などは、遅延している URL は何かといった点もここで突き止められます。さて、[Time MSEC]、つまり、ETW を採取開始してからのミリ秒がぽんと飛んでいる箇所があります。ここが問題の場所ですね。今回は PHP なので、php-cgi.exe でこの期間に何をやっていたのかを追いましょう。  

5) 遅いリクエストの遅い処理（ボトルネック）を見つける

PerfView のメインウィンドウに戻り、今度は [Events] ではなくて、[Thread Time (with StartStop Activities) Stacks] をダブルクリックしましょう。プロセスを選ぶウィンドウでは php-cgi をダブルクリックします。全時間範囲を見てもさっぱりなので、まずは時間範囲を絞ります。先程の FASTCGI_START の Time MSec を上部 [Start] に、FASTCGI_END の Time Msec を [End] にコピペし、さらに　[GroupPats] を空にして Enter を押します。 毎ミリ秒のスタックが記録されているので、ここから BROKEN を展開していくのですが、その前にシンボルを合わせておきましょう。Kudu コンソールで D:\ に上がり、"dir /s /b php-cgi.pdb" を検索すると、D:\Program Files (x86)\PHP\v5.6\debug\ にある事が分かります。使用している PHP バージョンに合わせて php-cgi.pdb とphp5.pdb などの PHP 主要モジュールの シンボルファイルをダウンロードし、適当なフォルダに入れます。Thread Time … のウィンドウ、[File] メニューから [Set Symbol Path] を選択します。表示されたダイアログで [Add Microsoft Symbol Server] をクリックした上で、.pdb をダウンロードしたフォルダを最初の列に記入します（セミコロンがデリミタになります）。 では、BROKEN から展開していきましょう。BROKEN は本来、スタック壊れているよ、という意味なのですが、まぁ往々にしてその下も展開できます。もし <モジュール名>? となってしまって関数が出ない場合は、そこを右クリックして、[Lookup Symbols] を選んでください。 もう一目瞭然ですね。php5.dll の zif_sleep() から、Windows の SleepEx() が呼ばれています。ポイントは、右の Inc %、つまり、この7.6 秒後から、12.7 秒後までの凡そ5秒間、このスレッドでは 99% の時間、ずっとスリープしてた、という事を示しています。   今回は以上となります。 本来はこんなシンプルな問題にはならないと思いますが、このように ETW + PerfView はかなり細かいところまで追い込めます。これが ASP.NET なら、さらに例外のスタックを引っ張り出したりなどもお手のもの。今回はあえて PHP でやってみました（なお、Java はシンボルが無いのであまり細かいところまでは追い込めません。Application Insights などの方がいいかもしれませんね）。 皆様のお役に立てば嬉しいです。 ではまた。 d99 でした。]]> [お知らせ] de:code に登壇します https://docs.microsoft.com/archive/blogs/d99/decode2017 Wed, 17 May 2017 22:27:03 GMT https://blogs.msdn.microsoft.com/d99/?p=555 ハードコア デバッギング～Windows のアプリケーション運用トラブルシューティング実践」に言及してくださっており、こ、これは！と久しぶりに blog を書こうかなと思った次第です。
（お知らせ） Xamarinを支える技術 at de:code2017 わたしの裏番組でやっているWindowsアプリケーションの実践的なデバッグ・トラブルシューティング手法などが紹介されるセッションに興味があるわけですが
上記エントリで言及されているように、セッションにはセッションレベルがあり、私たちもレベル500に設定してみました。澤さんにセッション内容をレビューして頂いたのですが、「君たちのセッションは変態による変態のためのセッションですからまぁ頑張ってください」という、激励なのか諦観なのか反応に困るようなコメントを頂いております。hahaha   問題が二つ。   まず、我々サポートのエンジニアは日の当たるところにあまり出てきません。 まぁまったくゼロではないんですが、基本的には地下のモルグ（品川の某フロア）から一日中一歩も出ることなく、次々と運ばれてくるシステムやアプリケーションのご遺体（ダンプとかトレースとか）を、検死（解析とかデバッグとか）し続けているという、ハタから見たら何が面白いのか全く分からないであろうことに血道を上げております。 そういえば先日、社内でデバッグ好きが集まるグローバルグループがありまして、そこに一通のメールが流れてきました。 「ヘイ！みんな！このダンプなんだけど、原因がわかんないんだよ、手伝ってよ！（英語」みたいな感じ。次々とレスが付きます。「えー、俺、この製品のシンボル持ってないわー、だれか持ってるー？（英語」「それならここだよー、アクセスできるかーい？（英語」「で、これって現象なんなのー？（私」「高 CPU さー（英語」みたいな。 どうやら XML のパースが繰り返されてるっぽいと、もっと調べるにはダンプだけじゃ無理でこのあたりのトレースが必要だろうと、そんな感じでおおよその目星がついたところで、一人がある疑問を口にします。「ところでこれ、なんの案件なの？」 「いや、俺の Outlook」 。。。普通なら怒りますよね。なんでお前の Outlook（+ 見たことないカスタムアドインたくさん）をみんなでデバッグしてやってんのかと。でもさらにレスが続きます。「あ、マジで？俺も最近重くてさー、発生条件分かるー？」「あ、俺も俺も。このアドインじゃね？」 ... 変な人たちです。トラブルを見たらデバッグしてみたいという欲望に勝てないという。自分のマシンがブルースクリーンになったら揉み手でフルダンプ出るのを待ってるみたいな。私もそんな中でわちゃわちゃとやっております。 話がだいぶ脱線しましたが、そんな私たちですので、たくさんの人の前でスポットライト浴びて話すのは、あんまり慣れておりません。私自身も、最後に大型イベントに登壇したのは 2000年の TechED だったかな、というレベルです。それ以来長～いことモルグに籠ってわちゃわちゃとやっておりましたのでｗ、セッションにご参加頂ける皆様方には、何卒お手柔らかにお願いします。   もう一つの問題ですが、セッションの 紹介 をパッと見ておわかりいただけるかと思いますが、4人もの人間が入れ代わり立ち代わりで計50分のお話をします。しかも濃い目のネタを。まー、どう考えても時間が足りない！ですのでとにかくデモでパッと見てイメージできるような構成でお送りしたいと思います。私は順番的には最後なのですが、とにかく時間通りに進むように、私の番になったら残り時間2分、なんてことにならないようにと祈っております... 一部の内容については、後日この blog にも掲載しようかと思っておりますので、お楽しみに。   私たちサポートエンジニアは、開発や運用、設計といった事自体は専門ではありません。しかし、トラブルシューティングについては、毎日毎日たくさんたくさん頂くお問い合わせで、かなり、鍛えられています。 どうやらこの製品には仕様書があるらしいと見てみると、内容は "I have a dream" レベルの夢物語。。。「実装に即したもんを持ってこい！」と開発に詰め寄ると、そっと差し出されるソースコードレポジトリのパスとプライベートシンボル。。。あーはいはいわかりましたよ、データベースだかWebサーバーだかアプリケーションだかツールだか知りませんが、所詮プロセスでしょプロセス。デバッグ＆リバースエンジニアリングしてやろうじゃないですか！あるものはおもむろにデバッガをアタッチ、あるものはレポジトリから膨大なソースコードを漁り始める。。。 そんな血沸き肉躍るエンターテイメント、、、をセッションでお話するわけではないんですが（上記の内容はあくまでフィクションであり、実際の個人・団体などには関係しません）、私たちの経験から、何か皆様のお役に立つお話が出来ればと思っています。   なお、私はこの春から、正式に Azure のサポートチームに移り、AppService などの PaaS などなどについてもサポートを担当しています。しばやんさんの下記セッションは個人的にとても楽しみにしています。雲の上にもモルグがあるかはさておき、これからも当 blog をよろしくお願いいたします。
App Service on Linux の最新アップデートと de:code で久し振りにセッションをする話
ではまた。 d99 でした。]]> IE10, IE11 でダウンロードに失敗する事象について https://docs.microsoft.com/archive/blogs/d99/ie10-ie11 Tue, 10 Nov 2015 00:56:13 GMT https://blogs.msdn.microsoft.com/d99/2015/11/10/ie10-ie11/ こんにちは。d99 です。
最近、Web アプリケーションで対象 IE バージョンの移行を検討されているお客様が多いようで、以下のお問合せが増えてきているため、ご紹介します。

 

事象

ASP.NET で作成されたファイルダウンロードページで、IE9 まででは問題なくダウンロードできたのに、IE10 以降では「（ファイル名）がダウンロードできませんでした」とエラーになります。

詳細

後述の原因に合致する場合、当該ファイルダウンロードページでは Response.Close() が使用されています。これを Response.End() に置き換えるとエラーが発生しなくなります。

Response.Close() は TCP 接続を強制的に切断するメソッドで、クライアントに対して正しい応答を返すためには一般的には使用されません（クライアントからの悪意のある要求に対して応答せずに接続を切断する、といった場合に使用されます）。Response.End() は ASP との互換のために残されているメソッドではありますが、応答の終了というイメージに近い動作を行います（この際、HttpModule 等、処理パイプライン全体に処理を中断したことを通知するため ThreadAbortException が発報されます）。

HttpResponse.Close メソッド ()
https://msdn.microsoft.com/ja-jp/library/system.web.httpresponse.close(v=vs.110).aspx

HttpResponse.End メソッド ()
https://msdn.microsoft.com/ja-jp/library/system.web.httpresponse.end(v=vs.110).aspx

原因

当該現象は、下記ブログの記事に該当していると考えられます。

IEInternals : Content-Length and Transfer-Encoding Validation in theIE10 Download Manager
http://blogs.msdn.com/b/ieinternals/archive/2012/07/16/content-length-and-transfer-encoding-validation-in-ie10-download-manager-couldnt-be-downloaded-retry-cancel.aspx


IE9 までは、サーバーからのレスポンスにヘッダー Content-Length が含まれない場合や、"Transfer-Encoding:chunked" が指定されている場合であっても転送データのサイズや終端のチェックを厳密に行っていませんでした。

しかし、IE10 以降のダウンロードマネージャーでは、厳密にチェックを行うよう動作が変更されました。この変更により、レスポンスヘッダーにContent-Length が含まれない場合や、チャンク転送でありながら転送データの終端を示す 0-sized chunk が含まれていない場合にはダウンロードを中断し、情報バーに 「（ファイル名） をダウンロードできませんでした。」を表示します。

対処

前述のとおり、Response.Close() は、クライアントとの TCP 接続を強制切断するメソッドになりますので、0-sized chunk は含まれません。しかし、Response.End() であれば、0-sized chunk が含まれますので、有効な対処となります。もし、Response.End() に伴う ThreadAbortException を発生させたくない場合は、HttpApplication.CompleteRequest() をご利用ください。この場合、処理パイプラインを EndRequest まで進めます。

HttpApplication.CompleteRequest メソッド ()
https://msdn.microsoft.com/ja-jp/library/system.web.httpapplication.completerequest(v=vs.110).aspx

ただし、.aspx 等、応答を返すページハンドラにダウンロードを実装されている場合、HttpApplication.CompleteRequest() ではページコンテンツのレンダリングが避けられません。その場合該当ページの Render と RaisePostBackEvent をオーバーライドし、ダウンロード動作の際には基底クラスの同メソッドを呼び出さない事でこれを避ける事が出来ます。

なお、その他の方法としては、ダウンロード専用のカスタムハンドラを作成するといったものが考えられます。

 

以上です。古い IE の方がいい加減だった、という事例ですね :-)

ではまた。
d99でした。 

]]> [ご注意ください] 12月10日に Windows Update で配信された Visual Studio 2012 対象の更新プログラム KB3002339 をインストールするとシステムのハングアップなどの問題が発生する https://docs.microsoft.com/archive/blogs/d99/1210-windows-update-visual-studio-2012-263 Tue, 09 Dec 2014 23:14:59 GMT https://blogs.msdn.microsoft.com/d99/2014/12/09/1210-windows-update-visual-studio-2012-263/ ※本件は、Visual Studio サポートチームのブログの転載となります。

2014 年 12 月 10 日に公開され、Windows Update で配信された Visual Studio 2012 対象の KB3002339 の更新プログラムをインストールすると、Windows Update が完了しない、システム再起動時に更新が完了せずシステムがハングアップしてしまうという現象が発生することを確認いたしました。

KB3002339
https://support.microsoft.com/kb/3002339/ 

本問題の報告を受け、Windows Update の配信は既に停止いたしましたが、Windows Server Update Services (WSUS) を使用して更新プログラムを配信されているお客様におかれましては、本更新プログラムの配信を停止していただけますようお願い申し上げます。

既に本更新プログラムを適用し、ハングアップなどの現象が発生している環境での復旧方法につきましては、現在調査中です。進展があり次第、Visual Studio チーム記事にて情報公開させていただきます。最新の内容は下記 Visual Studio チームブログをご覧ください。

Visual Studio サポートチームブログ - [ご注意ください] 12 月 10 日に Windows Update で配信された Visual Studio 2012 対象の更新プログラム KB3002339 をインストールするとシステムのハングアップなどの問題が発生する
http://blogs.msdn.com/b/jpvsblog/archive/2014/12/10/12-10-windows-update-visual-studio-2012-kb3002339.aspx

お客様には多大なご迷惑をおかけしておりますこと、深くお詫び申し上げます。

]]> セキュリティ更新プログラム MS14-059 によって ASP.NET MVC のビルドに問題が生じる https://docs.microsoft.com/archive/blogs/d99/ms14-059-asp-net-mvc Thu, 23 Oct 2014 01:10:00 GMT https://blogs.msdn.microsoft.com/d99/2014/10/23/ms14-059-asp-net-mvc/ こんにちは。d99 です。
今回は下記 blog の日本語参考訳を掲載します。

Microsoft Asp.Net MVC Security Update MS14-059 broke my build!
http://blogs.msdn.com/b/webdev/archive/2014/10/16/microsoft-asp-net-mvc-security-update-broke-my-build.aspx

------

先日マイクロソフトは新しいセキュリティ更新プログラム（MS14-059）をリリースしました。本更新プログラムは、Microsoft Update を使用するよう構成された環境に対して自動的に適用されます。該当のセキュリティ更新プログラムに関する情報はこちらです： https://technet.microsoft.com/ja-jp/library/security/ms14-059

残念ながら、本更新プログラムの適用によって、ASP.NET MVC3, 4 を使用した Web アプリケーションプロジェクトで、ビルドに失敗するようになります。失敗する際のエラーは以下の通りです（MVC4 の場合）。

アセンブリが見つかりませんでした"System.Web.Mvc,Version=4.0.0.0、Culture=neurtral,
PublicKeyToken=31bf3856ad364e35、processorArchitecture=MSIL

このエラーは、該当のプロジェクトがグローバルアセンブリキャッシュ（GAC）にあるアセンブリを参照する際に発生します。セキュリティ更新プログラムによって System.Web.Mvc.dll のアセンブリ バージョンがインクリメントされたために、プロジェクトの System.Web.Mvc.dll への参照が解決できなくなりました。

本問題を解決するためには次のいずれかの対処を実施します。

  1. (推奨) NuGET ギャラリーから Microsoft.ASPNET.MVC パッケージをインストールします（これによって当該アプリケーションの web.config に bindingRedirect要素が書き込まれます）。NuGet パッケージ マネージャーを操作するか、または Visual Studio の NuGet コンソールから以下のコマンドを実行します。

    >Install-Package Microsoft.AspNet.Mvc -Version <バージョン> -Project <プロジェクト名>
    ※ MVC 4 のバージョンは 4.0.40804.0、MVC 3 のバージョンは 3.0.50813.1 となります
     
  2. 手動で System.Web.MVC.dll への参照を更新します（この際、GAC 内の dll を参照しないようご注意ください）。参照を一旦削除し、Visual Studio で [参照の追加] – [アセンブリ] ->[拡張] にて Sysytem.Web.Mvc を選択します。バージョンが 4.0.0.1 となっている事をご確認ください。

どちらの場合でも、[参照設定] で System.Web.mvc.dll の [ローカル コピー] プロパティが true に設定されている事を確認してください。これによって、アプリケーションをデプロイできるよう、アセンブリがbin フォルダーに格納されます。なお、NuGet には [ローカルコピー] のプロパティをリセットしてしまうという問題があります。ご注意ください: https://nuget.codeplex.com/workitem/4344

Visual Studio 2012 以前の MVC プロジェクトテンプレートでは、System.Web.MVC.dll アセンブリを GAC またはアセンブリ参照のフォルダーのいずれかから参照していました。最新の MVC テンプレートは、NuGet パッケージのインストールによってアセンブリへの参照を追加しています。これが、対処策 1. が推奨の理由です。現在 NuGet ギャラリーの使用は一般的かと存じます。

なお、Visual Studio 2010 を使用して ASP.NET MVC3 プロジェクトを作成した場合も、同様の現象が発生する場合があります。これは該当のセキュリティ更新プログラムに関する情報にも以下の通り記載されています：

MVC 3.0 RTM がシステムにインストールされている状態で、更新プログラムをシステムにインストールしたところ、Visual Studio 2010 で新しいプロジェクトを作成できなくなりました。この問題を解決する方法を教えてください。 
Visual Studio 2010 用の ASP.NET MVC 3.0 テンプレートは、参照アセンブリ フォルダーにインストールされているアセンブリに依存します。MVC 3.0 用アセンブリの更新されたバージョンがインクリメントされるので、テンプレートが機能しなくなります。この問題を解決するには、Visual Studio 2010 用の MVC 3.0.1 ツール更新をインストールします。 

なぜアセンブリのバージョンをインクリメントしたかですが、これは既にサーバーに配置されているサードパーティ製 Web アプリケーションをセキュリティの脅威から守るためです。この場合、脆弱性のあるアセンブリはGAC に格納されている場合があり、そのアプリケーションでもセキュリティで保護されたアセンブリを実行させるためには、アセンブリのバージョンをインクリメントし、GAC に配置されたアセンブリも更新する必要がありました。

また、一部の ASP.NET MVC5 プロジェクトでも、本事象に関連した影響を受ける可能性があります。Visual Studio にて Web アプリケーションを実行した際に、次のようなエラーが発生する場合があります。

コンパイラ エラー メッセージ: CS0234: 型または名前空間名 'Ajax' は名前空間 'System.Web.Mvc' に存在しません。アセンブリ参照が不足しています。

これは、System.Web.Mvc.dll アセンブリの参照設定で [ローカル コピー] が前述の NuGet の問題にてリセットされている可能性が高いです。

この場合、アセンブリがアプリケーションと共に配置されません。Visual Studio では、GAC にインストールされているアセンブリに対しては [ローカル コピー] を既定で false に設定します。次の MSDN ドキュメントを参照してください：

http://msdn.microsoft.com/ja-jp/library/vstudio/vslangproj.reference.copylocal.aspx
http://msdn.microsoft.com/ja-jp/library/ez524kew%28VS.80%29.aspx

この問題を修正するには、手動で [ローカル コピー] を true に変更してください。

最後に、ASP.NET MVC 4 アプリケーションが次のようなエラーを表示する場合があります。

ファイルまたはアセンブリを読み込めませんでした 'Newtonsoft.Json、バージョン 4.5.0.0 Culture=Neutral、PublicKeyToken=30ad4fe6b2a6aeed' またはその依存関係の 1 つ。

これは、セキュリティ更新プログラムによって更新されたバージョン固有の問題ではなく、ASP.NET MVC アセンブリが GAC にインストールされている場合に発生します。その場合、Newtonsoft.Json.dll アセンブリを解決することができません。アプリケーションのアセンブリ探索パス(bin フォルダーまたはそれと同等のフォルダー) にアセンブリをコピーする事で本問題を解決できます。Newtonsoft.Json 4.5.6 を NuGet ギャラリーからインストールできます。

------

以上、参考になれば幸いです。

ではまた。
d99でした。

]]> ASP.NET の IE10 対応について https://docs.microsoft.com/archive/blogs/d99/asp-net-ie10 Fri, 02 Aug 2013 06:21:00 GMT https://blogs.msdn.microsoft.com/d99/2013/08/02/asp-net-ie10/ こんにちは。d99 です。  
今回は下記の件を取り上げます。

問題
ASP.NET 4.0 までのバージョンでは、ユーザーエージェント解析に問題があり、Internet Explorer 10 の判定に失敗します。その結果、IE10 に対してだけ JavaScript が出力されずクライアントスクリプトが正常に動作しなかったり、CSS が出力されずレイアウトが崩れたり、といった問題が発生します。

ASP.NET が Internet Explorer 10 の検出に失敗する
http://msdn.microsoft.com/ja-jp/library/ie/hh869299(v=vs.85).aspx

原因
ASP.NET のバグです。

対処
緊急修正モジュールのご用意があります。

ASP.NET 4.0 用
http://support.microsoft.com/kb/2600088

ASP.NET 2.0、3.0 3.5 用
http://support.microsoft.com/kb/2600100
http://support.microsoft.com/kb/2608565

備考
このバグは、所謂 WebFrom にだけ影響し、ASP.NET MVC や ASP.NET WebPages （Razor） には影響しません。

 

今回は上記の問題の、緊急修正モジュール以外の対処についてご紹介します。

この問題については以下の4つの対処方法があります。

  1. 緊急修正モジュール（hotfix）を適用する
  2. セキュリティパッチ（MS11-100）を適用する
  3. 手動でシステムのブラウザ定義を書き換える
  4. アプリケーションに IE10 対応のブラウザ定義を加える

1. は、既にご紹介した通りです。緊急修正モジュールは ASP.NET のコアモジュールである System.Web.dll 等のバージョンを更新し、ブラウザ定義ファイル ie.browser 等も IE10 に対応した新しいものに更新します。

2. は、セキュリティパッチに IE10 対応の修正が含まれています。そのため Windows Update で適用されており、問題が発生しなくなっているかもしれません。ただ、これは 1. とは少し異なった修正のため注意が必要です。これについて解説します。

ASP.NET のブラウザ定義ファイルは %windir%\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers などの、.NET Framework インストールフォルダの CONFIG/Browsers サブフォルダにあります。

しかし、ASP.NET は既定ではこのファイル自体を使ってはいません。

ASP.NET はブラウザ判定ルーチンを System.Web.dll の中に持っており、既定ではそれを使っています。上記パスのブラウザ定義ファイルは既定のブラウザ判定ルーチンの内容を示したもので、これをテキストエディタで書き換えただけではそれが反映されません。

反映するためには、aspnet_regbrowsers.exe というツールを使って、上記フォルダの .browser ファイルから判定ルーチンを含む dll を自動生成し、それを GAC にインストールして、既定の判定ルーチンを置き換える必要があります。実際には 「aspnet_regbrowsers.exe  /i」 というコマンドでそれらを全て自動で行いますが、その際に裏で行われているのはそういった動作です。

ASP.NET ブラウザ登録ツール (Aspnet_regbrowsers.exe)
http://msdn.microsoft.com/ja-jp/library/ms229858(v=vs.80).aspx

1. の緊急修正モジュールは、System.Web.dll を更新するので、既定の判定ルーチンが置き換わります。さらにシステムのブラウザ定義ファイル、ie.browser ファイルを更新します。そのため、適用後に aspnet_regbrowsers /i しても修正は維持されます。

しかし、2. の MS11-100 は Sysytem.Web.dll を更新して既定のルーチンは置き換えますが、ブラウザ定義ファイルは IE10 対応に更新されていません。そのため、aspnet_regbrowsers.exe コマンドを実行して既定の判定ルーチンを置き換えてしまっていたり、後に置き換えてしまったりすると、更新されていない ie.browser ファイルによって既定の判定ルーチンが上書きされてしまい、修正が機能しなくなってしまうため注意が必要です。

既定のルーチンを置き換えてしまった場合は、aspnet_regbrowsers.exe /u コマンドで既定の状態 （Sysytem.Web.dll 内のルーチンを使う状態） に戻せます。

3. は、手動でシステムのブラウザ定義ファイルを置き換える方法です。別のテスト環境等に緊急修正モジュールを適用し、それによって更新された ie.browser ファイルを手に入れます。それを用いて、ターゲット環境の ie.browser を書き換え、aspnet_regbrowsers.exe /i コマンドで定義を更新します。

どうしてもバイナリバージョンを更新したくない、かつ、該当環境で動くアプリケーション全てで IE10 の誤判定問題を解決したい、という場合にはこちらの方法になります。比較的運用管理者の方が好まれる方法かもしれません。

4. は、開発者の方向けの対処です。前出のシステムのブラウザ定義ファイル（NET Framework インストールフォルダの CONFIG/Browsers サブフォルダにあるもの）は、更新した上に aspnet_regbrowsers.exe /i するという手間がかかります。しかし、あるアプリケーションでだけブラウザ定義を追加・変更したいのであれば、アプリケーションルート直下に App_Browsers というフォルダを作り、そこにブラウザ定義ファイルを用意する事が出来ます。

ただし、この時使用するブラウザ定義ファイルは、3. のものとは内容が異なります。

ブラウザ定義ファイルは、ツリー状に判定ルーチンが構成されており、アプリケーション毎のブラウザ判定では、システムの持っているルーチンにノードを追加するイメージでしか更新できません。つまり、システムのブラウザ判定が優先され、それで判定できなかった場合、またはそれで判定された結果をさらに細分化するような事しかできません。

従って、アプリ用の IE10 対応ブラウザ定義ファイルを入手する必要があります。これは NuGet で公開されています。

ASP.NET 4.0 用 （ASP.NET Browser Capabilities Update with IE10 and FF5 fixes for .NET 4）
http://www.nuget.org/packages/App_BrowsersUpdate

ASP.NET 2.0、3.0、3.5 用 （ASP.NET Browser Capabilities Update with IE10 fix for .NET 2.0）
http://www.nuget.org/packages/App_BrowsersUpdate.net20

NuGet をコマンドで叩いてもいいですが、もし Visual Studio 2010 以降をお使いであれば、Package Manager を使用してアプリケーションに追加する事が出来ます。下記は Visual Studio 2010 の Package Manager 導入手順ですが、Visual Studio 2012 では [NuGet パッケージの管理] メニューから "IE10" というキーワードで検索すると、上記がヒットすると思います。

.NETで開発モジュール導入が楽々に！ NuGet入門
http://www.atmarkit.co.jp/fdotnet/chushin/nuget_01/nuget_01_01.html

これをアプリケーションに導入しておけば、ターゲット環境に緊急修正が入っているかどうか、セキュリティパッチが入っているかどうか、という事に関わらずアプリケーションで IE10 の誤判定問題に対応する事が出来ます。

 

以上、ご参考になれば幸いです。次回は日本ではややマイナー感のある、ASP.NET WebPages 2 について取り上げる予定です。

ではまた。
d99でした。

]]> また Windows Azure の記事を書きました https://docs.microsoft.com/archive/blogs/d99/windows-azure Tue, 08 Jan 2013 18:54:48 GMT https://blogs.msdn.microsoft.com/d99/2013/01/08/windows-azure/ あけましておめでとうございます d99 です。
以前も「Windows Azure サポートの現場から」に記事を書いた事を告知しましたが、また私の番がやってきました :-)

Windows Azure サポートの現場から > Web ロールで動作するアプリケーションのパフォーマンス チューニング
http://msdn.microsoft.com/ja-jp/windowsazure/jj841097

今回も内容としては Azure 特有のハナシではありません。いつもいつもこんなのでいいのかなとも思いますが、意外とご好評頂いています。


問題のシナリオ
運用中の Windows Azure 上で動作する Web アプリケーションにパフォーマンスの問題が見つかったとします。通常は 1 秒以内で応答が得られるのですが、時折 5 秒以上かかる事があります。

現時点ではユーザーからの申告や監視システム等からのアラートからのみ現象が把握されており、どういった URL でどの程度の遅延が生じているか正確には把握できていません。また、該当の Web アプリケーションは Windows Azure の複数インスタンス上で動作しており、どれか特定のインスタンスでのみ発生している問題かどうかも分かっていません。

まずはパフォーマンス問題の発生箇所と、その状況を明らかにしたい、というのが今回のシナリオです。

「パフォーマンスが悪い」というお問い合わせは少なくないのですが、ボトルネックだけでなく現象の発生している URL も特定されていないという状況でご連絡頂く場合があります。エンドユーザー様からのクレームで発覚し、とにかく何でも良いので手はないかとお困りなんだろうなぁと思って対応させて頂くのですが、もちろん設定一つで爆速というものは無く、ボトルネックはどこかを探していくお手伝いをさせて頂く事になります。

そういった絞り込みってどうやればいいの？というそもそもの疑問を頂戴する事もあるので、今回の記事ではログをクエリーする方法をご紹介させて頂きました。

ではまた。今年もよろしくお願いいたします。
d99 でした。

]]> ASP.NET デッドロック検知機能について (4) https://docs.microsoft.com/archive/blogs/d99/asp-net-4 Fri, 02 Nov 2012 05:10:39 GMT https://blogs.msdn.microsoft.com/d99/2012/11/02/asp-net-4/ こんにちは。
d99 です。いよいよこのシリーズも最後の回です。

今回は前回の方法で採取したダンプファイルを解析してみましょう。ASP.NET の簡単なダンプ解析方法をご紹介します。細かいところが分からなくても「だいたいのイメージ」が分かって頂けるといいかなと思います。

ダンプ解析には、採取時にインストールした Debugging Tools for Windows に含まれる windbg というデバッガを使用します。[スタート] - [すべてのプログラム] - [Debugging Tools for Windows (x86)] - [WinDbg] を起動し、c:\dump にある .dmp ファイルをドラッグアンドドロップします。Worspace に関するダイアログには一旦 [No] と答えておいてください。

image image

今回の場合、現象はハングアップですので、動作が止まっているスレッドを探し出すことになります。一般的な方法としては、まず各スレッドのスタックトレース、つまり関数の呼び出し履歴を表示し、この中から止まっているスレッドを探します。まずは .NET 用のデバッガエクステンションを読み込みます。以下のコマンドを入力して Enter します。

.loadby sos mscorwks

その上で、全スレッドのスタックトレースを表示するコマンドは ~*k、マネージドのみの全スタックトレースは ~*e !clrstack で表示できます。しかしやってみても（シンボルを設定していない事もあり）あまり良く分からない内容が大量に出てきます。

実は、スタックトレースを見るだけでこのスレッドがハングアップしているのか、それとも単に作業を割り当てられるのを待っているなどの問題のない状態なのかを判断するには、それなりの経験が必要です。ダンプが採取できるタイミングというのは各スレッドが一瞬でも止まることができるタイミングなので、基本的にすべてのスレッドはなんらかの理由で止まっています。問題はその停止が動作の流れの中の一時的なものなのか、それとも異常なものなのかを見極める事です。それを間違うと何の問題もないスレッドをハングアップの原因とみなしてしまう事になります。

では、何か良いヒントはないのでしょうか。実は、ASP.NET の比較的シンプルな Web ページであれば、簡単な判別方法があります。先ほど読み込んだ sos デバッガエクステンションのコマンド、!threads でLockCount が 1以上 になっているスレッドは、非常にざっくりと言うと、ASP.NET ページ処理で作業中の可能性が高いスレッドです。

0:028> !threads
ThreadCount: 10
UnstartedThread: 0
BackgroundThread: 10
PendingThread: 0
DeadThread: 0
Hosted Runtime: no
                                      PreEmptive   GC Alloc           Lock
       ID OSID ThreadOBJ    State     GC       Context       Domain   Count APT Exception
  15    1  8e8 000dd3a0   3808220 Enabled  02b19d68:02b1b008 000fdf28     1 MTA (Threadpool Worker)
  19    2  ad0 000e33d0      b220 Enabled  00000000:00000000 000d7098     0 MTA (Finalizer)
  20    3  404 000fa500    80a220 Enabled  00000000:00000000 000d7098     0 MTA (Threadpool Completion Port)
  21    4  ebc 000fd7e8      1220 Enabled  00000000:00000000 000d7098     0 Ukn
  22    5  730 0012d768   380b220 Enabled  06b5f1b4:06b60fe8 000fdf28     2 MTA (Threadpool Worker)
  23    6  eec 0012f960   380b220 Enabled  06b63cf8:06b64fe8 000fdf28     1 MTA (Threadpool Worker)
  24    7   a4 00137188   380b220 Enabled  06b66df0:06b66fe8 000fdf28     1 MTA (Threadpool Worker)
  25    8  6a8 00138230   380b220 Enabled  02b1ce10:02b1d008 000fdf28     1 MTA (Threadpool Worker)
  26    9  d2c 00138da0   180b220 Enabled  02ae3b20:02ae4fe8 000d7098     0 MTA (Threadpool Worker)
  13    a  960 00139b50   880a220 Enabled  00000000:00000000 000d7098     0 MTA (Threadpool Completion Port)

また以前ご紹介した psscor2 には !aspxpages というコマンドもあります。ダウンロードした EXE を実行すると、指定したフォルダに ZIP ファイルが解凍されますので、これをさらに解凍し、その中に含まれる psscor2.dll を Debugging Tools for Windows のフォルダに移動します。.load コマンドで読み込み、!aspxpapegs コマンドを実行してみましょう。

0:028> .load psscor2

0:028> !aspxpages
PDB symbol for mscorwks.dll not loaded
Going to dump the HttpContexts found in the heap.
Loading the heap objects into our cache.
HttpContext    Timeout  Completed     Running  ThreadId ReturnCode   Verb RequestPath+QueryString
0x02ab28f0    19200 Sec        no       142 Sec      25        200   POST /DeadlockTest/test.aspx
...
x02af8438    19200 Sec        no        44 Sec      15        200   POST /DeadlockTest/test.aspx
0x06ae6484    19200 Sec       yes                   XXX        200   POST /DeadlockTest/test.aspx
0x06ae8990    19200 Sec        no       144 Sec      22        200   POST /DeadlockTest/test.aspx
0x06aee8f0    19200 Sec        no       143 Sec      23        200   POST /DeadlockTest/test.aspx
0x06af48f0    19200 Sec        no       143 Sec      24        200   POST /DeadlockTest/test.aspx
Total 70 HttpContext objects

こちらはもっと分かりやすいですね。このコマンドではリクエスト処理中のスレッドを列挙します。ThreadId が XXX のものは単純に言うと処理が終わってしまったものですので（一部例外もあります）、無視してください。これはヒープから HttpContext のクラスインスタンスを列挙し、そのプロパティから状態を出しているため、またガベージコレクトされていない HttpContext クラスインスタンスも表示されてしまうためです。

HttpContext クラス
http://msdn.microsoft.com/ja-jp/library/system.web.httpcontext(v=VS.80).aspx

今回の場合、Running 列の一番大きいものの、ThreadId は 22 ですので、このスレッドのスタックトレースを表示しましょう。~22s というコマンドで 22番 スレッドに移り、!clrstack コマンドで Visual Studio を使って C# でデバッグしている感覚（呼出し履歴ウィンドウの表示）に近い出力を出します。これが .NET の呼び出し履歴、いわゆるマネージドスタックトレースになります。

0:028> ~22s
eax=00000000 ebx=00000000 ecx=000003fc edx=069d0000 esi=00000000 edi=109cf120
eip=7c97845c esp=109cf0e0 ebp=109cf148 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
ntdll!KiFastSystemCallRet:
7c97845c c3              ret

0:022> !clrstack
OS Thread Id: 0x730 (22)
ESP       EIP    
109cf230 7c97845c [HelperMethodFrame: 109cf230] System.Threading.Thread.SleepInternal(Int32)
109cf284 0eba9345 System.Threading.Thread.Sleep(Int32)
109cf288 106407da ASP.test_aspx.Button1_Click(System.Object, System.EventArgs)*** WARNING: Unable to verify checksum for App_Web__mrqmt6b.dll
c:\Inetpub\wwwroot\DeadlockTest\test.aspx:10
109cf2d0 6679f618 System.Web.UI.WebControls.Button.OnClick(System.EventArgs)
109cf2e8 6679f43b System.Web.UI.WebControls.Button.RaisePostBackEvent(System.String)
109cf300 6679f6bb System.Web.UI.WebControls.Button.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(System.String)
109cf308 6609842e System.Web.UI.Page.RaisePostBackEvent(System.Web.UI.IPostBackEventHandler, System.String)
109cf314 66098385 System.Web.UI.Page.RaisePostBackEvent(System.Collections.Specialized.NameValueCollection)
109cf328 660aa65e System.Web.UI.Page.ProcessRequestMain(Boolean, Boolean)
109cf480 660a9ee4 System.Web.UI.Page.ProcessRequest(Boolean, Boolean)
109cf4b8 660a9e11 System.Web.UI.Page.ProcessRequest()
109cf4f0 660a9da6 System.Web.UI.Page.ProcessRequestWithNoAssert(System.Web.HttpContext)
109cf4fc 660a9d82 System.Web.UI.Page.ProcessRequest(System.Web.HttpContext)
109cf510 106401b6 ASP.test_aspx.ProcessRequest(System.Web.HttpContext)
109cf520 660b0256 System.Web.HttpApplication+CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
109cf554 6608332c System.Web.HttpApplication.ExecuteStep(IExecutionStep, Boolean ByRef)
109cf594 6608eb83 System.Web.HttpApplication+ApplicationStepManager.ResumeSteps(System.Exception)
109cf5e4 660828ac System.Web.HttpApplication.System.Web.IHttpAsyncHandler.BeginProcessRequest(System.Web.HttpContext, System.AsyncCallback, System.Object)
109cf600 66085e1c System.Web.HttpRuntime.ProcessRequestInternal(System.Web.HttpWorkerRequest)
109cf634 66085ac3 System.Web.HttpRuntime.ProcessRequestNoDemand(System.Web.HttpWorkerRequest)
109cf644 66084c5c System.Web.Hosting.ISAPIRuntime.ProcessRequest(IntPtr, Int32)
109cf858 79faca45 [ContextTransitionFrame: 109cf858]
109cf88c 79faca45 [GCFrame: 109cf88c]
109cf9e8 79faca45 [ComMethodFrame: 109cf9e8]

呼出し履歴ウィンドウと同様に、関数の呼び出しは下から上です。最終的には一番上の関数を実行中です。ただし停止の原因が一番上にあるとは限りません。例えば、System.Threading.Thread.Sleep() メソッドが一番上にあっていたとしても Sleep() 自体が悪いのではなく、なぜ Sleep() が呼び出されたのか、これはどのくらいスリープしているのかという事が重要です。

ただ今回の場合、意図的にスリープしているのですから、旅はひとまずここまでです。このスタックトレースのおおまかな形を覚えておくと役に立つかもしれません。これは「あるページでスリープさせた時のスタックトレース」であるとともに、「ASP.NET ページ処理までの関数呼び出し履歴」でもあります。前述のように、ダンプファイルから各スレッドがどういった作業中なのかを判断するにはこういった、「あるコードが実行されるまでの流れ」を知っておくと、スタックをパッと見て判別できるようになります。なので、私は初めて触るプログラミングプラットホームでは、まずコードで長期間スリープさせ、デバッガをアタッチしてスタックをみてみるといった事をよくやります。

閑話休題、デッドロックについてはいったんここで区切ります。今後もまたちょっとしたダンプの取り方・見方をちょくちょく紹介していきますので、お楽しみに。

ではまた。
d99でした。

]]> ASP.NET デッドロック 検知機能について (3) https://docs.microsoft.com/archive/blogs/d99/asp-net-3 Mon, 16 Jul 2012 23:11:00 GMT https://blogs.msdn.microsoft.com/d99/2012/07/16/asp-net-3/ こんにちは d99 です。
またもや間が空いてしまいましたが、このネタの続きを。これを完結させませんと先には進めませんので。

前回 「デッドロックが検出されました」 というイベントログをわざと発生させる設定とサンプルプログラムをご紹介しました。

ASP.NET デッドロック 検知機能について (2)
http://blogs.msdn.com/b/d99/archive/2012/02/29/10274250.aspx

今回は、このプログラムを使ってデッドロック検知時にダンプファイルを自動採取してみます。

前回の通り、サーバー環境は、Windows Server 2003、IIS 6.0 + .NET Framework 2.0 を使用します。前回のサンプルを http://localhost/DeadlockTest/test.aspx に配置したとします。前回記載の手順でデッドロック検知のイベントをわざと起こせる事も確認済みです。では、まずダンプファイル採取の設定を行いましょう。

※ 下記手順は、Windows Server 2008 以降では使用できません。これは、IIS と ASP.NET 統合の影響によって、ASP.NET がそもそもデッドロック検出イベントを発生させなくなったためです。2008 以降でどうすれば良いかについては、後日ご紹介する予定です。

ダンプファイル採取の設定手順はサポート技術情報でご用意しています。

IIS 6.0 で ASP.NET がデッドロックになった場合のダンプ ファイルの生成方法
http://support.microsoft.com/kb/828222/ja

Debugging Tools for Windows をインストール（別の環境にインストールし、フォルダごとコピーでも構いません）、バッチファイルやダンプ出力フォルダを用意して、IIS の設定をコマンドラインから変更するだけです。Debugging Tools for Windows は以下から過去のバージョンのものを（バージョン 6.11）をご利用ください。

32 ビット版 Debugging Tools for Windows
http://msdn.microsoft.com/ja-jp/windows/hardware/gg463016

ASP.NET 運用デバッグ入門 1) デバッガのインストール
http://blogs.msdn.com/b/d99/archive/2008/04/01/8347420.aspx

※ 最新版の Debugging Tools for WIndows でもコマンド自体には変更はありません。ただし、最新版は単体ダウンロードでのご用意がなく SDK や DDK に含まれているため、開発機等へ一旦インストールしてからコピーしていて頂くシナリオが多いのかなと思います。

なお、サポート技術情報記載の action.cmd はこのままでも良いですが、少しいじっておくと便利な場合があります。

@if "%_echo%"=="" echo off
setlocal
    set TIMESTAMP=%DATE:~-9%_%TIME%
set TIMESTAMP=%TIMESTAMP:/=_%
set TIMESTAMP=%TIMESTAMP::=_%
set TIMESTAMP=%TIMESTAMP:.=_%
set TIMESTAMP=%TIMESTAMP: =_%
set FILENAME=c:\dump\crash_%TIMESTAMP%.dmp
set LOG=c:\dump\log_%TIMESTAMP%.txt
set COMMAND="C:\Program Files\Debugging Tools for Windows (x86)\cdb.exe" -c ".dump /o /ma %FILENAME%;q" -p %1

echo %COMMAND% > %LOG%
%COMMAND% >> %LOG% 2>&1

endlocal

グレーの部分はパスを変更しただけです。黄色の部分ですが、まず cdb.exe のオプションを /mhf から /ma に変えています。これは /ma の方が多少多くの情報が取れるためです。また、再度の %COMMAND% にオプションを追加しているのは、バッチファイルに間違いなどが合った場合もエラーが log.txt に記録できるようにしているだけです。

サポート技術情報の設定をほどこした上で、前回の再現手順を行います。パフォーマンスモニタで観測すると以下のようになります（下記環境は 2CPU で、同時実行数の上限が5になるように machine.config を調整しています）。

perfmon

IIS はオーバーラップリサイクル（次のプロセスを起動してから、古いプロセスを終了させる）を行うので、デッドロック検知が働いて、新しい w3wp.exe が起動すると見た目上同時実行数が増えたように見えますが、このタイミングでデッドロック検知のイベントログが記録されているかと思います。そして、指定したフォルダに .dmp ファイルと、.txt が出力されます。

さて、次回はこのダンプファイルを素材に、ASP.NET の中身がどのように見えるか、確認してみましょう。

ではまた。
d99 でした。

]]> Windows Azure の記事を書きました https://docs.microsoft.com/archive/blogs/d99/windows-azure-2 Thu, 12 Jul 2012 02:24:00 GMT https://blogs.msdn.microsoft.com/d99/2012/07/12/windows-azure-2/ こんにちは d99 です。
実は私は Windows Azure のサポートチームにも所属していたりするのですが、その関係で Windows Azure に関連して記事を書きました。

Windows Azure サポートの現場から > リモート デスクトップを利用したデバッグ (その 2)
http://msdn.microsoft.com/ja-jp/windowsazure/jj219279

もしよろしければご賞味ください :-) 内容としては Azure 特有のハナシではありません。むしろ普通の Web アプリケーションで有用かなと思います。上記の記事では OutputDebugString() API を紹介しています。

他にそういったデバッグで使い易い API 関数と言えば、DebugBreak() API でしょうか。この関数は、要はアタッチしているデバッガを止めるというもので、以前ご紹介した windbg.exe などのデバッガで任意のタイミングでブレークさせる、というものです。DebugBreak() API のプラットフォーム呼び出し定義は以下のようになります。

[DllImport("kernel32.dll")]
static extern void DebugBreak();

さて、これに対応したマネージドメソッドはないのでしょうか？ 実は System.Diagnostics.Debugger.Break() メソッドがそれに当たるのですが、これが NET Framework 2.0 と 4.0 で動きが少し異なります。.NET Framework 2.0 の Debugger.Break() は、Visual Studio しか止まりません。しかし、.NET Framework 4.0 の Debugger.Break() は結果的に DebugBreak() API を呼び出しますのでネイティブデバッガでも止まります。

まとめると、windbg.exe 等のネイティブデバッガで止めたいなら、.NET Framework 2.0 なら DebugBreak() API をプラットフォーム呼び出し。.NET Framework 4.0 なら System.Diagnostics.Debugger.Break() マネージドメソッド、という事になります。私の同僚には、未だにデバッグブレークといえばなんとかして int 3 を直接書こうとするものもいますがｗ、4.0 であれば Debugger.Break() を使って頂ければと思います。

また、OutputDebugString() API も、System.Diagnostics.Debug.Print() だけでなく、System.Diagnostics.Debugger.Log()  もあります。引数が多いので Windows Azure の記事では紹介しませんでしたが、こちらもデバッガ上にログを出力しますし、Debug.Print() と違ってデバッグビルドかどうかに関わらずログを出力します（デバッガー自体の設定には依存します）。

基本的にはマネージドメソッドを使いつつ、うまく Windows API で補完すると素敵なデバッグライフをお送り頂けるのではないかと :-)

ではまた。
d99 でした。

]]>