[お知らせ] de:code に登壇します

こんにちは、d99 です。 そういえば blog をまったく更新しておりませんでした。この blog のダッシュボードを開きましたら、いささか賞味期限の切れた下書きエントリが並んでおり、先ほど泣く泣く消しました。ASP.NET Web フォームと IE11 とか、ASP.NET セッション状態と Redis とか… POSTするとしても全部リライトですね。いやはや… さて、今回なぜ久しぶりに blog を書こうと思ったかというと表題の通りです。そして、ネットを徘徊しておりましたら atsushieno さんが以下のように私たちのセッション、「ハードコア デバッギング~Windows のアプリケーション運用トラブルシューティング実践」に言及してくださっており、こ、これは!と久しぶりに blog を書こうかなと思った次第です。 (お知らせ) Xamarinを支える技術 at de:code2017 わたしの裏番組でやっているWindowsアプリケーションの実践的なデバッグ・トラブルシューティング手法などが紹介されるセッションに興味があるわけですが 上記エントリで言及されているように、セッションにはセッションレベルがあり、私たちもレベル500に設定してみました。澤さんにセッション内容をレビューして頂いたのですが、「君たちのセッションは変態による変態のためのセッションですからまぁ頑張ってください」という、激励なのか諦観なのか反応に困るようなコメントを頂いております。hahaha   問題が二つ。   まず、我々サポートのエンジニアは日の当たるところにあまり出てきません。 まぁまったくゼロではないんですが、基本的には地下のモルグ(品川の某フロア)から一日中一歩も出ることなく、次々と運ばれてくるシステムやアプリケーションのご遺体(ダンプとかトレースとか)を、検死(解析とかデバッグとか)し続けているという、ハタから見たら何が面白いのか全く分からないであろうことに血道を上げております。 そういえば先日、社内でデバッグ好きが集まるグローバルグループがありまして、そこに一通のメールが流れてきました。 「ヘイ!みんな!このダンプなんだけど、原因がわかんないんだよ、手伝ってよ!(英語」みたいな感じ。次々とレスが付きます。「えー、俺、この製品のシンボル持ってないわー、だれか持ってるー?(英語」「それならここだよー、アクセスできるかーい?(英語」「で、これって現象なんなのー?(私」「高 CPU さー(英語」みたいな。 どうやら XML のパースが繰り返されてるっぽいと、もっと調べるにはダンプだけじゃ無理でこのあたりのトレースが必要だろうと、そんな感じでおおよその目星がついたところで、一人がある疑問を口にします。「ところでこれ、なんの案件なの?」 「いや、俺の Outlook」 。。。普通なら怒りますよね。なんでお前の Outlook(+ 見たことないカスタムアドインたくさん)をみんなでデバッグしてやってんのかと。でもさらにレスが続きます。「あ、マジで?俺も最近重くてさー、発生条件分かるー?」「あ、俺も俺も。このアドインじゃね?」 … 変な人たちです。トラブルを見たらデバッグしてみたいという欲望に勝てないという。自分のマシンがブルースクリーンになったら揉み手でフルダンプ出るのを待ってるみたいな。私もそんな中でわちゃわちゃとやっております。 話がだいぶ脱線しましたが、そんな私たちですので、たくさんの人の前でスポットライト浴びて話すのは、あんまり慣れておりません。私自身も、最後に大型イベントに登壇したのは 2000年の TechED だったかな、というレベルです。それ以来長~いことモルグに籠ってわちゃわちゃとやっておりましたのでw、セッションにご参加頂ける皆様方には、何卒お手柔らかにお願いします。   もう一つの問題ですが、セッションの…


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…


[ご注意ください] 12月10日に Windows Update で配信された Visual Studio 2012 対象の更新プログラム KB3002339 をインストールするとシステムのハングアップなどの問題が発生する

※本件は、Visual Studio サポートチームのブログの転載となります。 2014 年 12 月 10 日に公開され、Windows Update で配信された Visual Studio 2012 対象の KB3002339 の更新プログラムをインストールすると、Windows Update が完了しない、システム再起動時に更新が完了せずシステムがハングアップしてしまうという現象が発生することを確認いたしました。 KB3002339https://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 のビルドに問題が生じる

こんにちは。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 への参照が解決できなくなりました。 本問題を解決するためには次のいずれかの対処を実施します。 (推奨) NuGET ギャラリーから Microsoft.ASPNET.MVC パッケージをインストールします(これによって当該アプリケーションの web.config に bindingRedirect要素が書き込まれます)。NuGet パッケージ マネージャーを操作するか、または Visual Studio の NuGet コンソールから以下のコマンドを実行します。 >Install-Package Microsoft.AspNet.Mvc -Version <バージョン> -Project <プロジェクト名>※ MVC 4…


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つの対処方法があります。 緊急修正モジュール(hotfix)を適用する セキュリティパッチ(MS11-100)を適用する 手動でシステムのブラウザ定義を書き換える アプリケーションに IE10 対応のブラウザ定義を加える…


また 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)

こんにちは。 d99 です。いよいよこのシリーズも最後の回です。 今回は前回の方法で採取したダンプファイルを解析してみましょう。ASP.NET の簡単なダンプ解析方法をご紹介します。細かいところが分からなくても「だいたいのイメージ」が分かって頂けるといいかなと思います。 ダンプ解析には、採取時にインストールした Debugging Tools for Windows に含まれる windbg というデバッガを使用します。[スタート] – [すべてのプログラム] – [Debugging Tools for Windows (x86)] – [WinDbg] を起動し、c:\dump にある .dmp ファイルをドラッグアンドドロップします。Worspace に関するダイアログには一旦 [No] と答えておいてください。 今回の場合、現象はハングアップですので、動作が止まっているスレッドを探し出すことになります。一般的な方法としては、まず各スレッドのスタックトレース、つまり関数の呼び出し履歴を表示し、この中から止まっているスレッドを探します。まずは .NET 用のデバッガエクステンションを読み込みます。以下のコマンドを入力して Enter します。 .loadby sos mscorwks その上で、全スレッドのスタックトレースを表示するコマンドは ~*k、マネージドのみの全スタックトレースは ~*e !clrstack で表示できます。しかしやってみても(シンボルを設定していない事もあり)あまり良く分からない内容が大量に出てきます。 実は、スタックトレースを見るだけでこのスレッドがハングアップしているのか、それとも単に作業を割り当てられるのを待っているなどの問題のない状態なのかを判断するには、それなりの経験が必要です。ダンプが採取できるタイミングというのは各スレッドが一瞬でも止まることができるタイミングなので、基本的にすべてのスレッドはなんらかの理由で止まっています。問題はその停止が動作の流れの中の一時的なものなのか、それとも異常なものなのかを見極める事です。それを間違うと何の問題もないスレッドをハングアップの原因とみなしてしまう事になります。 では、何か良いヒントはないのでしょうか。実は、ASP.NET の比較的シンプルな Web ページであれば、簡単な判別方法があります。先ほど読み込んだ sos デバッガエクステンションのコマンド、!threads でLockCount が 1以上 になっているスレッドは、非常にざっくりと言うと、ASP.NET ページ処理で作業中の可能性が高いスレッドです。…


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 ビット版…


Windows Azure の記事を書きました

こんにちは 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…


Windows 認証 Web アプリで、突然認証ダイアログが出るようになる問題について

こんにちは d99 です。 弊社の会計年度は7月始まりなので、実は今日から新年度です。今年もよろしくお願いします。前回予告したように、今回も最近お問い合わせの多い事例について取り上げます。 現象は、Windows Server 2008 R2 (Windows 7) 上で動作している、Windows 認証を使用した Web アプリケーションで、今まで問題なく動作していたにも関わらず、急に認証ダイアログが表示されるようになる、というものです。 認証ダイアログが表示される原因は多岐にわたるため確認すべき内容が多く、一般的には調査に時間がかかる事で知られています。しかし、Windows Server 2008 R2 では、下記の既知の不具合があり、これによって突然認証ダイアログが表示される現象が発生します。この不具合は 2011 年 8 月に公開されましたが、昨今、世界的にお問い合わせが増加しています。 Users cannot access an IIS-hosted website after the computer password for the server is changed in Windows 7 or in Windows Server 2008 R2 http://support.microsoft.com/kb/2545850/en-us 現象の特徴 この現象をクライアント側から見てみましょう。 この現象はクライアントで認証ダイアログが表示される現象として表面化します。さらに、表示された認証ダイアログに正しいアカウント情報を入力しても、認証が通らないということが挙げられます。たとえドメイン管理者のアカウント情報を入力したとしても、認証は通りません。 次に、サーバー側から見てみましょう。 まず、IIS7.5 であることが条件です。IIS 7.5…