2008/09/24(Wed)MTPモードのトラブル

2008/09/24 16:18 Software::Windows
最近の携帯電話やポータブルプレーヤーには、「MTP(Media Transfer Protocol)モード」という転送方法が数多く採用されている。先日のSH906iにもこの方式が実装されていた。
MTPはMicrosoftが開発した技術仕様で、それぞれのデバイスドライバを必要することなく、マルチメディアデータを標準インストールされているWindows Media Playerで転送することが出来る。DRMもサポートしていることから、マスストレージモードを搭載していない物などにもこのモードがあることが多い。（パナソニック等の製品にはSD-Audioという規格があり、これとは別。）


非常に便利なMTPモードであるが、Windows Media Player絡みのアップデートでうまく動作しなくなることがあるようで、実際に私がハマったので、そのトラブルシュートをご紹介。

現象

Windows Media Playerからは同期デバイスとして認識せず、デバイスドライバでは！マークが表示されている。
（IEEEコントローラが×になってるのは、ノートPCの消費電力削減のため、給電を停止しているからであり、本題とは関係ない。）
mtp01.png

mtp02.png


「ドライバの再インストール」を選んでみると、一見インストールが成功したように見えるのだが、最後に「このINFのサービスインストールセクションは無効です。」と難しいエラーメッセージが表示される。

mtp03.png


解決方法

先ほどもちらっと書いたように、これはWindows Media Playerをアップグレードしてしまうと問題が起こる模様。
色々とググってみたところでは「XPの修復インストールで直った」という情報が出てきたが、さまざまな部分が元に戻ってしまうのでこれは避けたい。
半ば勘に頼ってだが、私の場合は、WMAのエンコーダーに同梱されていた「Windows Media Format 11 runtime」をインストールしてしまったのが原因らしい。
Windows Media Player 10を使っているのに、11用のランタイムを間違えてインストールされてしまったのが原因かな？
Windows Media Player 11を使ってる人はこれをアンインストールしていいのか良く分からないが…。

▼これをアンインストール
mtp04.png



メッセージに従って、どんどん進む。
mtp05.png

チェックをつけて続行。ここのメッセージによると、保護されたファイルのライセンスは削除されるので再度取得せよ、とのこと。私はDRM保護されたファイルは管理していないので問題なし。
mtp06.png

mtp07.png

mtp08.png


ここで再起動

仕上げ

この段階ではトラブルを起こしているドライバが読み込まれているので、デバイスマネージャから一旦問題のデバイスを削除する。
それから、USBケーブルを挿しなおし、今度は認識されることを確認。

mtp09.png

mtp10.png

コメント（22件）

2008/09/14(Sun)screenでデタッチできない 解決編

2008/09/14 21:21 Software::Linux
screenでデタッチできないというのを書いたが、解決法発見。
デタッチできないというよりも、むしろアタッチできないという方が正しい表現だったようだ。

これはscreenの問題ではなく、回線が切れたときにsshセッションが切れず、sshdプロセスが生きたままで、その応答待ちでscreenがattachedから変化しない模様。

以下、対処法。
$ ps x | grep pts | grep sshd
13819 ?        S      0:00 sshd: kero@pts/2
13985 ?        S      0:00 sshd: kero@pts/8
14595 pts/2    S+     0:00 grep sshd

grepが走っているpts/2が現在操作中のポートなので、pts/8を落とす。

$ kill -KILL 13985

$ screen -ls
There is a screen on:
        9120.pts-0.spinel       (Multi, detached)
1 Socket in /var/run/screen/S-kero.

$ screen -r
これで自動的にdetatchされ（autodetatchがonの場合）再アタッチ可能になる。


が、いちいちこんな事やるのが面倒なので、自分以外のsshセッションを片っ端から強制終了するスクリプトを書いてみた。
最近Perlの正規表現にハマってたりなので…。/bin/sh+sedかawk…と思いつつも、慣れてる方が書きやすい。
だいたい検証したけど、killのとこだけは検証してない…。たぶん大丈夫。ちゃんと動きました。
screenの内側から実行しないように注意。
#!/usr/bin/perl
use strict;

(my $tty = `echo -n \$SSH_TTY`) =~ s/\/dev\///;
my $dead = `ps x | grep pts | grep sshd | grep -v $tty | grep -v grep`;
foreach(split(/\n/, $dead)){
    $_ =~ s/^\s*(\d+).+$/$1/;
    print qq|Kill pid=$_...\n|;
    `kill -KILL $_`;
}

参考元:http://subtech.g.hatena.ne.jp/cho45/20070517/1179373075
コメント（0件）

2008/09/13(Sat)バッチファイルで時計表示

2008/09/13 17:56 Software::Windows
あるステータスをバッチファイルで延々流し続けたいときに、パッと見て、その行のレコードが何時何分何秒のデータかを分かりやすくしたかったので、バッチファイルで時計を表示するコードを書いてみた。

とまぁこれが、結構面倒で^^;
time /Tコマンドでは、秒まで出てきません。
秒は%time%という変数を使うことまで1/100秒単位までご丁寧に出てくれるのですが、はっきり言って無駄…

で、これを使わざるをえないことに。
結構XPだったり2000だったりで出力に差があるらしいのですが、ここはXP x64 SP2ベースで書きます。
自分の場合は、24時間制で0補完済みの2桁ごとで区切られた数が得られたので、「あぁ、substringかけるだけじゃん～」と思ったら……

実は厄介でした。0の扱いが。
先頭に0がついた、06といった数字は、8進数の6を表すような解釈をするらしく、秒の部分だけを切りだして変数に入れる(set /aでは式の評価が行われる)と、システムの時計が8秒と9秒のとき、"無効な数字です"と文句を言われます。

というわけで、結構苦肉の策。
@echo off
set n=-1
:LOOP
set /a t=%time:~6,1%
if %t% == 0 (set /a s=%time:~7,1%) else (set /a s=%time:~6,2%)
if %s% == %n% goto LOOP
set /a n=%s%
echo %time:~0,8%
goto LOOP
実行結果
17:53:40
17:53:41
17:53:42
17:53:43
17:53:44
17:53:45
17:53:46
17:53:47
17:53:48
17:53:49
…
もっとスマートに書けるのかもしれんが……。あぁ、とりあえず外部アプリのsleep.exeとか、JSを開く手はナシで。
ちなみに、ping -n [止めたい秒数] localhost >NULという書き方も紹介されてましたが、なんか1秒置きにうまく動いてくれませんでした。


まったくもって、Linuxのbashは賢すぎる。
あっちなら
echo -e "`date "+%Y/%m/%d %H:%M:%S"`"
なんて手軽に書ける。曜日や"1日前"、なんてのもお茶の子さいさい。
あぁ、こんな表現使うの久々…（笑）
コメント（1件）

2008/09/12(Fri)BSOD 0x35 NO_MORE_IRP_STACK_LOCATIONS with KIS 解決法

2008/09/12 21:20 Software::Windows
BSOD中間まとめで書いたが、このKaspersky Internet SecurityとWindowsファイル共有が相性悪くて、BSOD 0x35 NO_MORE_IRP_STACK_LOCATIONSで止まる件について解決法が分かった。
この話がマイナーな事を考えると、Windows XP x64 SP2限定の話で、x86には全く関係ないのかもしれない。

MSKBを探し回った結果

0x35エラーが引っかかったが、ドメイン参加ではないのでドメインにログオンしようとすると、「 STOP 0x00000035 NO_MORE_IRP_STACK_LOCATIONS」エラー メッセージを表示することがあります。は関係ない。
SP2も適応済みであり、mup.sysのバージョンは公開されているパッチよりもずっと新しかった。

mup.png


Kaspersky Laboを探しまわった結果

このエントリが引っかかって、
I should also mention, I tried changing HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Klif Start key to 2 (currently still set that way), and that did not help. I then added to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters an IRPStackSize key, started at 15, ran it up to 50, but that also did nothing.
というのがあったので、ダメ元で、
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\KLIF]
"Start"=dword:00000002
に変更。元々は、
"Start"=dword:00000001
でした。
このStartの値が何を示すかというのは、MSKBによると0x01の方が0x02よりローレベルな段階で起動する模様。
ゆえに、エラーが起こった時はKernel Panic=BSODとなるわけですか…。ふむ。

とりあえず、結果からいえば、これで直った。
この変更を加えても、一応Firewallは正常に動作しているようで、未定義のルールについてはちゃんと警告出してきているし、Sambaのやり取りも問題なくなった。


一件落着。
今回はBSOD系のエラーでも、すごくマイナーな物だったから余計に苦労したな…。

追記 2008/09/15

x86にKIS7をインストールしている場合でもStart=0x01だが、こちらはBSODにならない。
ということは、x64環境の場合だけの問題のようですね。

追記 2008/12/03

しばらく使ってたら、また青くなった。
今度は、ここを変更してみた。
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\kl1]
"Start"=dword:00000002
現状とりあえず安定しているようなので、↑でダメだった人はやってみてください。
コメント（0件）