kkamegawa's weblog

Visual Studio,TFS,ALM,VSTS,DevOps関係のことについていろいろと書いていきます。Google Analyticsで解析を行っています

Azure App Service障害発生時のダンプ解析とシンボル管理

blog.shibayan.jp

App Serviceだけではないけど、障害が発生してダンプの解析をしなければならない場合がたまにあります。

ダンプ解析するにはそのモジュールのシンボル(pdb)ファイルを取っておかないといけないのですが、障害解析ができない場合に限って、シンボルをちゃんと管理しているという話をとんと聞きません。特にCやC++のネイティブモジュールであればシンボルがあると、ないとではかなり大変さが違います。

VSTS(Visual Studio Team Services)のPackage管理機能のライセンス(Enterprise Subscriptionを持っている人には入っています)があれば、VSTSのシンボルサーバー機能が使えます。どうやって使うのか紹介します。

シンボル設定初期値
シンボル設定初期値

オプションからシンボルを選択して、右上の赤枠アイコンをクリックします。

VSTS選択
VSTS選択

シンボルサーバーとしてライセンスがあるVSTSを選択します。

VSTSシンボルサーバー追加
VSTSシンボルサーバー追加

このように追加されます。

ビルド定義にシンボル発行を追加
ビルド定義にシンボル発行を追加

Publish Symbol PathタスクのPublish Symbolsにチェックすると、pdbファイルを自動的にVSTS内に保存します。保存先はVSTS内か、ファイル共有が選べます。

前書いたように、ビルド結果はRetain Policyに従って自動削除されます。シンボルも同じ制御を受けるので、ビルド結果が削除されると自動的にシンボルも削除されます。うっかりプロダクションにリリースしたファイルを削除しないように気を付けてください。

Azure App Serviceのプランによってはダンプが採取できます。

ダンプ収集
ダンプ収集

ダウンロードしたミニダンプをダウンロードして、Visual StudioやWinDbgで開くと、VSTSもシンボルサーバーとして扱われるので、自動的にシンボルが検索されます。

ダンプを開く
ダンプを開く

今までファイル共有などでシンボル管理はタイへだったと思いますが、VSTSのシンボルサーバー機能はダンプ解析する時大変便利なので、ぜひ使ってください。

書籍レビュー:PowerShell実践ガイドブック

ちょうど読みたかったPowerShell実践ガイドブックのレビュワーをマイナビ出版さんが募集されていたので、応募したところ、見事当選しました。シェルに引っ掛けて貝殻が表紙になっているので、貝殻本だそうです。

貝殻本(と呼んで欲しいと書かれてた)とインサイドWindowsが同時に来た!

私のバックグラウンド

Windows PowerShellは1.0のころから注目していて、公私ともにぼちぼち使っていました。バッチファイルがどうも嫌だったんですね。単純に並べるだけならまだしも、制御文を考え出すとちょっとつかいたくないな、と。

ほんとうはC#がよかったけど、当時はC#スクリプティングもなかったし、似たような構文でかけるかも、ということでPowerShellという名前になったころからぼちぼち使い始めました。

第一章でPowerShellとどう付き合っていくか、という分類でいえば、「.NETのクラスライブラリを簡単に呼び出したい(&クラスライブラリの挙動確認をしたい)」あたりが近いでしょうか。

Linuxでbashでそこそこのシェルスクリプト書いてプロダクションとして使ったことがありますが、どうしてもなじめなかった。まさに書かれているように、=とかifの後などに空白入れちゃいけないなどの、ルール(?)になじめなかった。とはいえ、これはほかの人がWindows(PowerShell)に移ってきても同じだと思いますので、どっこいどっこいでしょう。

よかったところ

特に1,2章が圧巻でした。PowerShell Coreとは何なのか、また何故Windows PowerShellをメンテナンスフェーズにして、新しいPowerShell Coreを作ることにしたのかという事情やBash、コマンドプロンプトとの違い、検索TIPSやデバッグを丁寧に書かれていて、ここだけで本書の実に半分近くを占めています。

PowerShellなんて昔やったよ!という方が今のPowerShellを勉強しなおすために読み直すのもいいと思います。実際、私も忘れていたところや、あいまいな知識のままだったところ、PowerShell 4.0以降で追加された機能をもう一度参照できてとても勉強になりました。やっぱり本をまとめて読むのはいいですね。

わかっているけど、構文忘れたときはWebでの検索もいいのですが、全くゼロベースの知識から始めるときはこうやってちゃんと挙動や仕様を逐一まとめてくれた本はとても助かります。

また、検索のノウハウやデバッグの基本なども書かれているのは非常にいいと思いました。こういうの教えてもらわないといつまでも無駄な時間を使いますしね。特に「メッセージを英語で」検索するの重要です。本書でも書かれていますが、英語圏には圧倒的なリソースがあるので、解決に至るまでの時間も短くなります。

読み方

順序だてて書かれているので、読みやすくはあるのですが、それでもボリュームがある本なので、すでにWindows PowerShellを使いこなしている方であれば、1章を軽く見るだけで、2章,4章を読めばいいかなと思います。

これからPowerShellを始めるんだけど、という方はまず1章,2章でいいでしょう。少しずつ練習して、少し疑問が出てきたり、エラーをもっとちゃんと処理したい、よい書き方を学びたいという方は3章飛ばして、4章読んでから自分のスクリプトを改造するのもいいんではないでしょうか。

もっと書いてほしいところ

PowerShellといえばやはりMSによるスクリプティングのシステム管理を想定しているので、今はPowerShell CoreベースのDSC実装がないことによる運用がなかったのは(著者も書かれていましたが)もっと読みたいところでした。今後DSCの実装が出てきたときに改めて第二版や分冊といった形で出してもらえるといいかなと思います。

とはいえ、ないものをねだっても仕方ないので、今ならAnsibleなんかもあっても面白いかもしれないですね(ベータはあるのかな…)。

個人的にPowerShellに期待しているところといえば、REST使った外部WebAPIをたたくことによる自動化と、WinRM(これはWindows PowerShellですが)による複数マシンの制御なので、そういった本が別にあってもいいかなと思います。

MSが作っているのに、PowerShell Coreの活用はAWSのほうが先行しているという何とも皮肉な図ですが、AzureはWindows PowerShellようにリリースしているモジュールをそのうち合わせてくるのでしょうか。

ちょっと気になったところ

長いスクリプトは動かしてないので、その部分の正誤はわからないですが、少し気づいたところなど。次の版で直してもらえたらいいかなという程度で、本書の良さを損なっているわけではありません。

82ページ

コマンドプロンプト(MSDOS)
コマンドプロンプトはMSDOSではないですね。その後ではちゃんと「DOSではない」と書かれているので、あえてそう書かれているのかもしれませんが。あと、Windows PowerShellはメンテナンスフェーズと書かれているのに、エクスプローラにあるというのはちょっと説得力が弱いかなぁと思いました。

コマンドプロンプトのおそらく内蔵コマンドに関しては強化されることはないかもしれませんが、CUIを動かすシェルとしての強化はWSLと連携して続いていますしね。

132と136ページ

132ではSYNTAX(たぶんPowerShellの表示結果から)だが、136ページではシンタックスとカタカナ読みになっているのはわざと?

190ページ

void型を使うと、処理結果を戻り値のないことを表現できます
→少しへんな日本語

191ページ

「配列の節で説明しているので」
→ここに限らないのですが、後半では章レベルになるものの、参照が書かれているのですが、前に戻ってみるときに探さないといけないので、ちゃんと節番号で書いてもらえると助かります。

218ページ

リスト2-244に変数だけあって結果がない

222ページ、232ページ

「あえて一節を設けて」
→2.7なので、書くなら「一項」?

245ページのリスト2-292

PowerShellの実行結果ではなく、dotnet coreになってる。たぶんリスト2-291が間違い(実行できないソースのまま掲載)して、ずれてる。

268ページ

モジュールを任意の方法で読み込んだり、自動的な〜
→だりが一つしかない

322ページ

リスト3-69の前のところと文のつなぎがよくわからない

3.4の認証のところ

Windows PowerShellには証明書を使った認証もあるので、その言及があってもよかったかなぁ。

495ページ

初期値の説明がですます調(ほかはである調)

495ページその2

メソッドの説明の「記述できます、」の句点誤り

547ページ

5.1.6の内容は例外の再スローを避ける話なのに、タイトルがちょっと違う気がします。最初タイトルだけ見て内容とあわなくて?となったけど、ソース見て理解できました。

567ページ

Get-process のtypo

PowerShell実践ガイドブック クロスプラットフォーム対応の次世代シェルを徹底解説

PowerShell実践ガイドブック クロスプラットフォーム対応の次世代シェルを徹底解説

PowerShell実践ガイドブック ~クロスプラットフォーム対応の次世代シェルを徹底解説~

PowerShell実践ガイドブック ~クロスプラットフォーム対応の次世代シェルを徹底解説~

Visual Studio 2017でMStestが実行できない場合の対処(System.Runtime, Version=4.1.1.0または依存関係の1つが読み込めないエラー)

二日ほどドはまりしました。Visual Studio 2017(15.7.1)でフル .NETでプログラムを作っていたのですが、ある日からMSTestを使ったUnit testの実行時こんなエラーが出るようになりました。

実行プログラム 'executor://mstestadapter/v2' の呼び出し中に例外が発生しました: 
ファイルまたはアセンブリ 'System.Runtime, Version=4.1.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'、
またはその依存関係の 1 つが読み込めませんでした。指定されたファイルが見つかりません。

ターゲットフレームワークを 4.5から4.7.2までいろいろ変えても駄目。どうもNuGetからライブラリーを追加してからのようで、プロジェクトテンプレートから作ったような足し算するような素のプロジェクトでは起きません。

csprojの 方法: 自動バインディング リダイレクトを有効/無効にする | Microsoft Docsを無効にするという方法も駄目。探しまくったら対処方法がありました。

github.com

  • MSTestのプロジェクトテンプレートに追加されているMicrosoft.VisualStudio.TestPlatform.TestFrameworkと同Extensionsを削除する
  • 代わりに参照からC:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\ReferenceAssemblies\v2.0\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll" を追加する

「単体テストを作る」から作ったMSTestの参照状態。

f:id:kkamegawa:20180516142712p:plain

この状態だと実行できないですが、Microsoft.VisualStudio.TestPlatform.TestFrameworkで始まるアセンブリを二つ消して、前述のC:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\ReferenceAssemblies\v2.0\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dllを追加します。

こんな感じになっていれば実行できるはずです。少なくとも私は大丈夫でした。

f:id:kkamegawa:20180516142521p:plain

デバッグに便利な拡張機能RevDeBug

はじめに

RevDebugという会社から「RevDebugってツールあるんだけど」と案内が来たので、試しに使ってみました。ProfilingTime Machineデバッグ情報の共有とかはチーム開発するときに便利そうです。

.NET Core 2.0以降や.NET Framework 4.5以降のサポートだそうです。既知の問題もちょっとあるのでこれに該当する人は少し待ちましょう。

Requirements for RevDeBug

  • いくつかのC# / VB.NET 15.0構文をサポートしていない
  • ASP.NET Core/ASP.NET MVCのUnhandled exceptionsが記録されない
  • ASP.NET Coreのhttpリクエストが記録されない
  • References with aliases other than global are not supported.
  • アンチウィルスのAvastを使っている場合、デバッグが記録されないので、ホワイトリストに入れて

Value Prompts

Value Prompts

これは無償版でも使える機能ですね。いちいちローカルやウォッチウィンドウを開かなくても変数の上に現在の値を表示してくれます。OzCodeにも同じような機能があります。

Monitoring

Monitoring

すべての例外を一か所のウィンドウで確認する機能ですね。メニューのReDebugからExceptions/Searchを表示します。

Profiling

Profiling

  • 実行範囲の上位10メソッドを円グラフで表示
  • もっとも呼び出されている上位5メソッドを棒グラフで表示
  • エディタの行番号の隣に処理時間に応じて色付けされる
  • RevDeBugメニューのPerformanceをクリックすると、呼び出し回数、処理時間をまとめて表示するウィンドウが表示

結構便利そうですね。

Time Machine

Time Machine

IntelliTraceをもっと便利にしたTime Machineといえばいいんでしょうか。矢印記号をクリックすれば前後のステップに移動できます。State Dataを使って、現在ステップの状態も取れます。マルチスレッドなどでは便利そうです。

Call StackScope Stackでは任意の呼び出し元に移動できます。Scope StackはVisual Studioにない機能のはずなので、(やめたほうがいいけど)多段呼び出しになっているような場合はうれしいですね。

Session Recording

Session Recording

以前やったデバッグ、あれどうだったっけ?と思うことはないでしょうか?Session Recordingを使えば、デバッグの記録ができます。IntelliTraceでも同じような感じですね。まだ深く使ってないので、どちらが、とはいえないですが、これもやはり高速なディスク上に保存するといいと思います。これは単独で使うものではなく、どちらかといえば、次の共有機能とセットでしょう。

記録ファイルは%userprofile%の下、具体的には以下の場所に入っています。

%userprofile%\documents\RevDeBug\SolutionName\Recordings

Share your recordings and save them for later use by others

Share your recordings and save them for later use by others

最近Visual Studio Codeでは複数の端末間で同じコードのデバッグができるようになりましたが、時差があるような場所にいる人にデバッグを頼むとか、オフラインの場所ではそれも難しいですね。そんなとき、このSession Recordingで記録した情報を送れば環境によらず同じデバッグができます。特にマルチスレッド関係のデバッグは端末によっておきたり起きなかったりが発生するため、大変有用だと思います。

リモート環境でのデバッグ情報も保存して共有できるので、特にクラウド環境とかのデバッグ情報を共有するのは便利そうです。

そのほか

Kubernetisのコンテナーデバッグ、AzureやAWSでの.NET Coreアプリデバッグ、AWS Lambdaのデバッグなどもサポートしているようです。Lambdaで.NET Core使っている人はどうでしょう?

チュートリアル用のプロジェクトも公開されています。