---

Amazonが瞬間的にASUS T100TA-DK564Gの値を下げたので衝動買い。案の定、翌日には値を戻してました。

メール、ウェブブラウズ、スケジュール管理に電子書籍、Nexus7 で事足りているのですが、10インチタブレットと&Windows8をタッチパネルで使ってみたかったのが購入理由。とはいえ多くの部分でNEXTGEAR 300 と機能が被る上に性能はNEXTGEARの方が高い、これまで「要らないだろ」と我慢し来たわけです。

で使ってみた結果、やっぱり私には中途半端な性能。いや、悪くはないんですよ。ただNexus7の解像度と携帯性、NEXTGEARの性能に慣れるていると、両者を1台にまとめたいというという気持ちよりも、2台持とうかという気持ちにになってしまいまして。

ただしストアアプリがもっと充実してくれば考えが変わるかもしれません。Modern UIは好きになれそうですが、タッチパネルで従来のWindowsデスクチップアプリは操作しづらい。が、ストアアプリだけで暮らせるようになったらWindows RTでいいんだよな…

そして来週、もう一つの衝動買い品がやってくる(^_^;)

昨日後方を走っていた車が付けていた初心者マークが、色あせてとても年期の入ったもの。代々引き継がれた物だという考え方もあるけど、おそらくずっと掲載しているのでしょう。

この行為に対しては特に法律には規定されていないらしい 。とはいえ法的に優遇措置を受けるわけで、なんか釈然としないなと。

そういえば免許取得後ペーパー期間が長かったので、掲載したことないな > 自分

---

以下の環境下でMSMQによる通信を構築しようとしてはまったので、備忘録。

• 送信側Windows XP、受信側Windows 7
• 両マシンともWork group状態での接続、つまりActive Directory無し
• C#でWindows.Messagingクラスライブラリを使用する

Active Directoryが無いので受信側ではプライベートキュー private$/abcを作成。このマシンローカルではメッセージの送受信が可能なことを確認。

送信プログラムをWindows XPマシンに移し実行。送信先キューにはDIRECT=TCP:192.168.137.1¥private$¥abcを指定。ここで192.168.137.1は受信PCのIPアドレス。System.Messaging.MessageQueueクラスを使うので実際の指定はFormatName:DIRECT=TCP:192.168.137.1¥private$¥abc。

[トラブル その1 ] 送信側のコントロールパネルからOutgoing queuesを見ると、未送信のキューがたまっているが、Statusはいつまで経ってもWaiting to connect。つまり受信側マシンに接続できない状態。

1. 受信側マシンのコマンドプロンプトからnetstat -aと打ち込み、ポート1801がLISTENINGになっているかを調べる。なっていない場合は何かしらの理由で受信側がキューを受け取る状態に無い。
2. ポート1801がLISTENINGの場合、送信側マシンからこのポートにtelnet接続してみる。接続拒否されるなら受信側マシンでファイアーウォールなどが邪魔をしている可能性が高い。
3. 受信側マシンがインターネットに直接接続されているとWindowsが判断した場合、セキュリティー上の理由でHTTP接続しか受け付けないようになる。この場合の対策としては下記のいずれか。
• HTTP接続に切り替える。両マシンにWindows機能の追加からMSMQにHTTPサポートをつけてインストール。送信側から指定する送信先はDIRECT=http://192.168.137.1/msmq/private$/abc
• Control Panel→ Computer Management (コンピューターの管理) → Message Queuing (メッセージキュー。Private QueuesやOutgoing Queuesフォルダを格納しているところ)を右クリック → プロパティ。Server Security (サーバーセキュリティ)タブからEnable hardened MSMQ modeで始まる項目からチェックをはずす(上図)。

私の場合はポート1801がLISTENINGになっていなかったのですが、設定をいじっているうちにLISTENINGになってしまい、どの操作で改善したのか分からず。これでStatusがConnectedになりましたが、いやなパターンだ(-_-;)

[トラブル その2 ] 送信後、送信側のOutgoing queuesは空っぽであり送信されたっぽいが、受信側には受け取ったキューが見当たらない。

1. 送信側のネットワークケーブルを引き抜きキューを送信。Outgoing queuesにたまっているのを確認後、ネットワークを復活させるとOutgoing queuesが空になるので送信されている模様。
2. 受信マシン上でコントロールパネルからイベントビューアを開き、Applications and Services Logs¥Microsoft¥Windows¥MSMQ¥End2Endを右クリックでプロパティ。Enable loggingにチェックを入れて、再度送信マシンから送信。
3. 正常ならメッセージが来た(Message came over network)とメッセージが受信キューに格納されたの2つがログに残るはず。前者しかない場合、コントロールパネルのComputer Management(コンピューターの管理)から対象の受信キュー(今回ならprivate$/abc)を右クリック→プロパティ、 セキュリティータブでANONYMOUS LOGONユーザーを追加、Send Message (メッセージの送信)に許可を与える (下図)

私の環境ではこれでやっとメッセージがネットワーク経由で送信されました。

[ 参考 ]

• Why does MSMQ "lock" your outgoing queue? (MSDN Blogs)
• Where have my MSMQ messages gone? (MSDN Blogs)

[2016/10/4 追記] HTTP接続でもWaiting to connectの場合、ファイアーウォールが原因の場合があります。外部のマシンからブラウザで受信側マシンにアクセスしてIISのページが表示されなければ可能性大。参考: Windows 7 で IIS を立ち上げた際、Windows ファイアウォールの許可されたプログラムに追加しないと外部デバイスからアクセスできません (ゆめとちぼーとげんじつと)

[2024/3/22 追記] サーバーをマシン名で指定している場合、IPアドレス(10.80.0.123など)指定に変えると通る場合あるようです。受信Windowsのマシン名とDNS上のマシン名を比較チェックをするんだとか。HaProxyとかロードバランサを間に挟んでハマりました。参考: Can't send a MSMQ message to the second DNS name of a server (Stack Exchange)

いつの間にやらスリープから復帰すると数秒後に青画面(BSoD = Blue Screen of Dead)になるように。復元ポイントなどを使って調べてみるとWindows 8.1にUpdate1を入れた後に発生するようになった模様。

が、このBSoD、出た後に再起動するのみで何が起こったのかさっぱり不明。何か解析する方法がないのかと思ってたのですが、やっぱりありました。

まずは下準備。

• Blue Screen View をダウンロード、インストール
• Windows SDKインストーラ をダウンロード・実行。途中インストールする項目を選択できるので、Debugging Tools for Windowsを選択(他のも必要ならどうぞ)
• WinDbgのショートカットがスタートメニューにできるので、管理者権限で実行にチェックを入れておくと後で便利
• Windowsシンボルパッケージのダウンロード から使用しているWindows向けのものをダウンロード・インストール
• マイコンピュータのプロパティから環境変数_NT_SYMBOL_PATH=SRV*C:¥Symbols*http://msdl.microsoft.com/download/symbols を設定

解析手順

1. Blue Screen Viewを実行。過去に発生したBSoDのリストが出る。調べたいものを探し出し、右の方にあるFull Path列の値を記録しておく
2. WinDbgを管理者権限で起動。シンボル読み込みで１～２分かかる。Ctrl+Dでファイル選択になるので、先ほどのFull Pathで示されるファイルを選択(ここで管理者権限でないとファイルが開けない場合がある)
3. 下のコマンドを打ち込む場所に!analyze -vと打ち込む。

6: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

DRIVER_POWER_STATE_FAILURE (9f)
A driver is causing an inconsistent power state.
Arguments:
Arg1: 0000000000000003, A device object has been blocking an Irp for too long a time
Arg2: ffffe00071d81060, Physical Device Object of the stack
Arg3: ffffd001a97db930, Functional Device Object of the stack
Arg4: ffffe000722871a0, The blocked IRP
(以下略)

4. Arg1のメッセージからIRP(Interrupt Request Packet:割り込み要求パケット)の問題と分かる。引き続きコマンド!irp (Arg4の行にある16進数)を入力

6: kd> !irp ffffe000722871a0
Irp is active with 23 stacks 21 is current (= 0xffffe00072287810)
 No Mdl: No System Buffer: Thread 00000000:  Irp stack trace.  Pending has been returned
     cmd  flg cl Device   File     Completion-Context
(中略)
>[ 16, 2]   0  1 ffffe00071de67c0 00000000 00000000-00000000    pending
       ¥Driver¥usbaudio
Args: 00041100 00000001 00000001 00000002
 [ 16, 2]   0 e1 ffffe00071d77060 00000000 fffff80371b302d8-ffffe00072611510 Success Error Cancel pending
       ¥Driver¥ksthunknt!PopRequestCompletion
Args: 00041100 00000001 00000001 00000002

5. 行頭に>の付いている行近辺から、usbaudioがIRPに対して返答してないらしいと分かる

ネットで調べるとusbaudioは文字通りUSB接続のスピーカーなど音関係のUSB装置に関係するらしい。確かにUSBスピーカーは繋いでいるのですが、これのドライバは挿せば勝手にインストールされるもので作成者はMicrosoft。いくらなんでもMicrosoftがこんなへまするとは考えづらい。

なんにしろUSB関連が臭いということでUSB装置を抜き挿ししてスリープを実行、Lenovo Multimedia Remote with Keyboard N5902という無線キーボードの通信に使うUSBモジュールを抜くとスリープ復帰後も落ちないことが分かりました。この無線キーボード、あまり使ってないのでこの際取り外しましょう。

[参考]

• ブルースクリーンで強制終了した原因を解析して教えてくれるフリーソフト「BlueScreenView」(Gigazine)
• WinDbg (Windows Debugger) の使用方法 (Crystal-Creation)
• Bugcheck: DRIVER_POWER_STATE_FAILURE (9f) (Geek Stuff)

[2014/5/12 追記]原因はオンボードのRealtek High Definition audioの録音モニタ出力(録音中の音をスピーカーに出力する)にUSBスピーカーを設定していた可能性が高いです。現在モニタ出力先を規定のデバイスに変更して様子見中。日立ICカードリーダ は相変わらず繋ぐとスリープ明けにBSoD出ます。

近頃のWindowsには復元ポイントなんてのがあるのであまり神経質になることもないのですが、なにか大きな変更をかける時はそのパーティションまるごとのバックアップを取る習慣にしてます。PCIeスロットに何か挿す時とか、最近ではWindows 8.1 Update1を入れる時とか。

バックアップ方法もいくつかありますが、私の場合はUnix系OSを使います。dd は使ってないHDDスペースも保存対象にしてバックアップファイルのサイズが大きくなってしまうためntfscloneを使うことが多いのですが、Knoppix 7.0.2では使えなくなってしまってます。どうやらNTFSをKnoppix上でマウントする機能だけ残し、その他ツール類は外されてしまったみたいです。

マシンがネットに接続された状態ならntfscloneは後からインストール可能で、コマンドシェルから以下のコマンドを打ち込めばいいです。

sudo aptitude update
sudo apt-get install -t unstable ntfs-3g ntfs-3g-ng-

ntfs-3g-ng-の最後のマイナスは重要で、(ntfscloneなどが除外された)ntfs-3g-ngをアンインストールして、(ntfscloneなどを含む)ntfs-3gをインストールするというのが上のコマンドです。

Knoppixにoverlayイメージが設定されてないとKnoppix起動時に毎回これを実行することになります。設定されてないとKnoppix起動時に毎回数秒だけ入力画面が現れますので、そこにoverlayイメージのサイズをMBで入力すれば作成してくれます。ntfscloneだけの目的なら30MBあれば十分でしょう。

参考

• Re: Ntfsclone in knoppix 7.0.2 (Debian-Knoppix mailing list)