2011年02月18日
SSHでディレクトリのファイル一覧を取得
PHPで、SSH接続してディレクトリのファイル一覧を取得するときのメモ。
Fオプションを入れていますので、
ディレクトリの場合はファイル名のあとに'/'が入ります。
ssh2_exec より ssh2_shellを使うべきって話もどこかで読んだような気がしますが
結果を取得するだけならssh2_execのが楽な気がする。
あと、ssh2_auth_pubkey_file って秘密鍵と公開鍵の両方が要るっぽいんですが
・・・そうなんですか（汗
$connection = ssh2_connect('shell.example.com', 22);
if (ssh2_auth_password($connection, 'username', 'secret')) {
$stream = ssh2_exec($connection, 'ls -1F /tmp/');
stream_set_blocking($stream, true);
$file_list = fread($stream, 4096);
fclose($stream);
$file_list_array = explode("\n", $file_list);
} else {
die('Authentication Failed...');
}
Fオプションを入れていますので、
ディレクトリの場合はファイル名のあとに'/'が入ります。
ssh2_exec より ssh2_shellを使うべきって話もどこかで読んだような気がしますが
結果を取得するだけならssh2_execのが楽な気がする。
あと、ssh2_auth_pubkey_file って秘密鍵と公開鍵の両方が要るっぽいんですが
・・・そうなんですか（汗
2011年02月04日
Firefoxセキュリティ証明書 例外の解除
セキュリティ証明書 例外の解除
Firefox3では、セキュリティ証明書に問題がある場合は
「安全な接続ができませんでした」として警告が表示されます。
これは「例外として扱うこともできます」で例外登録することでサイト表示できるようになるのですが、その後。
アドレスバーのところにマウスオーバーすると
『このサイトはあなたがセキュリティ例外として追加しました』
メッセージが表示されるようになるのですが、
これがいつまで経ってもそのまま。
正しい証明書を入れた後でも『このサイトはあなたが～』と出るので気持ち悪い。
1. [ツール(T)] - [オプション(O)...] - [詳細] - [暗号化]タブ - [証明書を表示(S)...] から
「証明書マネージャ」 を起動
2. [サーバ証明書]タブ のところで、該当のエントリを削除
3. FIrefoxを再起動することで、例外の 解除できました！
※ちなみに
<Userフォルダ>\Application Data\Mozilla\Firefox\Profiles\<8文字くらいの文字列>.default\cert_override.txt
にそのリストがあるので、そこから該当エントリを削除しても例外を戻すことができるようです。
Firefox3では、セキュリティ証明書に問題がある場合は
「安全な接続ができませんでした」として警告が表示されます。
これは「例外として扱うこともできます」で例外登録することでサイト表示できるようになるのですが、その後。
アドレスバーのところにマウスオーバーすると
『このサイトはあなたがセキュリティ例外として追加しました』
メッセージが表示されるようになるのですが、
これがいつまで経ってもそのまま。
正しい証明書を入れた後でも『このサイトはあなたが～』と出るので気持ち悪い。
1. [ツール(T)] - [オプション(O)...] - [詳細] - [暗号化]タブ - [証明書を表示(S)...] から
「証明書マネージャ」 を起動
2. [サーバ証明書]タブ のところで、該当のエントリを削除
3. FIrefoxを再起動することで、例外の 解除できました！
※ちなみに
<Userフォルダ>\Application Data\Mozilla\Firefox\Profiles\<8文字くらいの文字列>.default\cert_override.txt
にそのリストがあるので、そこから該当エントリを削除しても例外を戻すことができるようです。
2010年12月21日
xhtmlなモバイルサイトで文字化け
xhtmlなモバイルサイトを構築したところ、なぜか
文字エンコーディングが正しく選択されないというトラブルに見舞われました。
もともとEUC-JPで構築していたんですけど、
モバイルサイトだけShift-JISで作ったわけです。
ローカル環境では問題なく動いていたんですが、
lolipopのサーバーに上げると文字化けしてる・・・。
あれっと思って文字エンコーディングを確認してみたら
EUC-JPが選択されている。
手動でShift-JISに変更すると正しく表示されるんだけど、
自動判別させるとやっぱりEUC-JPが選択されてしまう。
同じファイルの拡張子を.htmlにしておくとちゃんとShift-JISが自動選択されるのに
.phpにするとEUC-JPが選択されちゃうという謎な現象に。
php.iniは、もともとあるEUC-JPのページに影響が出たら嫌なので変更したくない。
.htaccessファイルで制御しようかと思ったら500エラーが出る。
phpのmb関数で適当に初期エンコーディングの設定をしても直らない。
で、下記のおまじないを書いてみたところ
header ("Content-Type: xhtml+xml; charset=SJIS") ;
表示できました！！
こんな感じ。
//S-JISで表示するためのおまじない
header ("Content-Type: xhtml+xml; charset=SJIS") ;
?>
<?php echo '<?xml version="1.0" encoding="Shift_JIS"?>'."\n"; ?>
<!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.0//EN" "http://www.wapforum.org/DTD/xhtml-mobile10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ja" dir="ltr">
<head>
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=Shift_JIS" />
やれやれ良かった。。。
と、思ったら、
なんかPCとdocomoでは表示できるけど
auでは「リクエストされたページは表示できません」とか表示されてる。
おまじないの部分を
header ("Content-Type: text/html; charset=SJIS") ;
に書き換えたらauでも表示できるようになりました。
『[モバイル]3キャリアに対応した正しいContent-Typeとは？ 』
http://jivlog.blog98.fc2.com/blog-entry-26.html
によると、
らしいです。
機種判別しろってかー（汗
とりあえず text/html; でdocomoも表示されてるので、これで暫く様子見します。。。
2010/12/22
ドコモでやっぱりダメでした。CSSが認識されないという。
やっぱり機種判別いるようです。
『携帯サイト docomoのみxmlを出力 php header()』
http://spice-space.net/2010/02/03/%E6%90%BA%E5%B8%AF%E3%82%B5%E3%82%A4%E3%83%88-docomo%E3%81%AE%E3%81%BFxml%E3%82%92%E5%87%BA%E5%8A%9B-php-header/
//S-JISで表示するためのおまじない
if(preg_match("/^DoCoMo/i", $_SERVER['HTTP_USER_AGENT'])){
header ("Content-Type: application/xhtml+xml; charset=Shift_JIS") ;
}else {
header ("Content-Type: text/html; charset=SJIS") ;//その他キャリア＆PC
}
?>
<?php echo '<?xml version="1.0" encoding="Shift_JIS"?>'."\n"; ?>
<!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.0//EN" "http://www.wapforum.org/DTD/xhtml-mobile10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ja" dir="ltr">
<head>
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=Shift_JIS" />
文字エンコーディングが正しく選択されないというトラブルに見舞われました。
もともとEUC-JPで構築していたんですけど、
モバイルサイトだけShift-JISで作ったわけです。
ローカル環境では問題なく動いていたんですが、
lolipopのサーバーに上げると文字化けしてる・・・。
あれっと思って文字エンコーディングを確認してみたら
EUC-JPが選択されている。
手動でShift-JISに変更すると正しく表示されるんだけど、
自動判別させるとやっぱりEUC-JPが選択されてしまう。
同じファイルの拡張子を.htmlにしておくとちゃんとShift-JISが自動選択されるのに
.phpにするとEUC-JPが選択されちゃうという謎な現象に。
php.iniは、もともとあるEUC-JPのページに影響が出たら嫌なので変更したくない。
.htaccessファイルで制御しようかと思ったら500エラーが出る。
phpのmb関数で適当に初期エンコーディングの設定をしても直らない。
で、下記のおまじないを書いてみたところ
header ("Content-Type: xhtml+xml; charset=SJIS") ;
表示できました！！
こんな感じ。
//S-JISで表示するためのおまじない
header ("Content-Type: xhtml+xml; charset=SJIS") ;
?>
<?php echo '<?xml version="1.0" encoding="Shift_JIS"?>'."\n"; ?>
<!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.0//EN" "http://www.wapforum.org/DTD/xhtml-mobile10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ja" dir="ltr">
<head>
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=Shift_JIS" />
やれやれ良かった。。。
と、思ったら、
なんかPCとdocomoでは表示できるけど
auでは「リクエストされたページは表示できません」とか表示されてる。
おまじないの部分を
header ("Content-Type: text/html; charset=SJIS") ;
に書き換えたらauでも表示できるようになりました。
『[モバイル]3キャリアに対応した正しいContent-Typeとは？ 』
http://jivlog.blog98.fc2.com/blog-entry-26.html
によると、
●i-mode ※FOMA 2051/2102V以降のみ
application/xhtml+xml charset=Shift_JIS
●ezweb
text/html; charset=Shift_JIS
●softbank
text/html; charset=Shift_JIS
らしいです。
機種判別しろってかー（汗
とりあえず text/html; でdocomoも表示されてるので、これで暫く様子見します。。。
2010/12/22
ドコモでやっぱりダメでした。CSSが認識されないという。
やっぱり機種判別いるようです。
『携帯サイト docomoのみxmlを出力 php header()』
http://spice-space.net/2010/02/03/%E6%90%BA%E5%B8%AF%E3%82%B5%E3%82%A4%E3%83%88-docomo%E3%81%AE%E3%81%BFxml%E3%82%92%E5%87%BA%E5%8A%9B-php-header/
//S-JISで表示するためのおまじない
if(preg_match("/^DoCoMo/i", $_SERVER['HTTP_USER_AGENT'])){
header ("Content-Type: application/xhtml+xml; charset=Shift_JIS") ;
}else {
header ("Content-Type: text/html; charset=SJIS") ;//その他キャリア＆PC
}
?>
<?php echo '<?xml version="1.0" encoding="Shift_JIS"?>'."\n"; ?>
<!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.0//EN" "http://www.wapforum.org/DTD/xhtml-mobile10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ja" dir="ltr">
<head>
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=Shift_JIS" />
2010年11月24日
いわゆる半角ｶﾅの文字化けについて
いわゆる半角ｶﾅの文字化けについてさらっと調べてみました。
■script_encoding が SJIS のときに文字化けする
mbstring.script_encoding = SJIS の場合、
スクリプトファイルに記載された半角カナが文字化けすることがある。
（この場合、全部じゃなくて一部が文字化けする）
http://blog.y-110.net/log/eid141.html
■半角カナ２つを入力すると文字化けする
例えば「ｱｲ」という文字が「渦」になる。
これは Shift-JISと EUC-JPが誤判定されているため。
Shift-JISでは「ｱｲ（0xB1 0xB2）」だがEUC-JPでは「渦（0xB1B2）」になる。
http://www.shtml.jp/mojibake/hankaku.html
対策としては、エンコーディング情報（キャラクタセット）を明示すること。
■mb_convert_kana など mbstring関数で文字化けする
$str = mb_convert_kana($str, "KV"); などとしたとき、文字化けする。
これは内部でエンコーディング情報が誤判定されているため。
この場合は第３引数でエンコーディングを明示する。
$str = mb_convert_kana($str, "KV", "SJIS-win");など。
"auto"はやっぱり誤判定することがあるので使わない。
■mb_convert_encoding など mbstring関数で文字化けする
ソ, 十, 申, 能, 表 などの文字で文字化けする。
いわゆる5C問題。
■PHPのバグによる文字化け
『PHP の mbstring に関するメモ』
http://www.asahi-net.or.jp/~wv7y-kmr/memo/php_mbstring.html
・PHP 4.3.11, PHP 5.0.0 - PHP 5.0.4
mb_detect_encoding() が失敗する
・PHP 4.4.0 - PHP 4.4.1, PHP 5.0.4 - PHP 5.0.5
mb_encode_mimeheader() 関数が正常に動作しない
■メール送信するときに文字化けする
日本語メールの代表的なエンコードである ISO-2022-JP には、
半角カナ（JIS X 0201 Kana）がそもそも含まれていない。なので原則使えない。
（JIS = ISO-2022-JP ではないことに注意）
＃自力でMIME変換してsend_mail関数使った方がよさそう。
■MySQLのCONVERT関数のバグにより化ける
MySQL 4.1.2以前のバージョンでCONVERT関数により全角-半角変換すると
半角カナが変換されないことがあるようです。
-----------------------------------------------------------------------------------
メモ
・大勢としてwwwには半角カナを使用しても構わない。
過去との互換性のためとはいえ、Unicodeでもサポートされているので当面使用に支障はない。
・メールはISO-2022-JPを使用している限り、半角カナは避けるべき。
エンコードが違えば（例えばUTF-8なら）問題ない。
・どちらかというと、半角カナより機種依存文字（NEC特殊文字、IBM拡張文字）の方が厄介。
＃『mb_convert_encoding と UTF-8 の誤変換問題』（～波線が化ける）というのもある。
http://shain.blog.conextivo.com/2007/07/php_mb_convert_encoding_utf8.html
http://blog.livedoor.jp/dankogai/archives/50488765.html
この場合、「sjis-win」または「eucjp-win」というエンコーディングを使えば
回避できることがある。
・半角カナはエンコードによりバイト数が異なる。
Shift-JIS : 1byte
EUC-JP : 2byte (先頭１バイトに8Eが入る)
UTF-8 : 3byte (先頭２バイトにEFBD, EFBE が入る)
UTF-16 : 2byte
文字数カウントはシステムにより実装がばらばらなので注意すること。
・PHPの文字化けは基本的に自動変換しようとしたときに起きる。
よって、出来る限りエンコードを明示することで回避できることが多い。
・「半角カナは化ける」という話は以下の理由が大きい。
1.メールで使用できない（文字エンコードISO-2022-JPに含まれていないため）
2.Shift_JISの半角カナは、EUC-JP文字列と区別がつかない。
またEUC-JPの半角カナと、Shift_JIS文字列とでも区別がつかない。
よって文字コードの判定ミスが出やすい。
■script_encoding が SJIS のときに文字化けする
mbstring.script_encoding = SJIS の場合、
スクリプトファイルに記載された半角カナが文字化けすることがある。
（この場合、全部じゃなくて一部が文字化けする）
http://blog.y-110.net/log/eid141.html
script_encoding が SJIS の場合, 一旦 EUC に変換されて実行され, 出力時に再度 SJIS に変換されます。
出力は一定のブロックサイズで区切られるのですが,
この際に EUC半角カナの 1バイト目(0x8E)で切られてしまうことがあり, その場合に文字化けが発生していたようです。
■半角カナ２つを入力すると文字化けする
例えば「ｱｲ」という文字が「渦」になる。
これは Shift-JISと EUC-JPが誤判定されているため。
Shift-JISでは「ｱｲ（0xB1 0xB2）」だがEUC-JPでは「渦（0xB1B2）」になる。
http://www.shtml.jp/mojibake/hankaku.html
対策としては、エンコーディング情報（キャラクタセット）を明示すること。
■mb_convert_kana など mbstring関数で文字化けする
$str = mb_convert_kana($str, "KV"); などとしたとき、文字化けする。
これは内部でエンコーディング情報が誤判定されているため。
この場合は第３引数でエンコーディングを明示する。
$str = mb_convert_kana($str, "KV", "SJIS-win");など。
"auto"はやっぱり誤判定することがあるので使わない。
■mb_convert_encoding など mbstring関数で文字化けする
ソ, 十, 申, 能, 表 などの文字で文字化けする。
いわゆる5C問題。
■PHPのバグによる文字化け
『PHP の mbstring に関するメモ』
http://www.asahi-net.or.jp/~wv7y-kmr/memo/php_mbstring.html
・PHP 4.3.11, PHP 5.0.0 - PHP 5.0.4
mb_detect_encoding() が失敗する
・PHP 4.4.0 - PHP 4.4.1, PHP 5.0.4 - PHP 5.0.5
mb_encode_mimeheader() 関数が正常に動作しない
■メール送信するときに文字化けする
日本語メールの代表的なエンコードである ISO-2022-JP には、
半角カナ（JIS X 0201 Kana）がそもそも含まれていない。なので原則使えない。
（JIS = ISO-2022-JP ではないことに注意）
＃自力でMIME変換してsend_mail関数使った方がよさそう。
■MySQLのCONVERT関数のバグにより化ける
MySQL 4.1.2以前のバージョンでCONVERT関数により全角-半角変換すると
半角カナが変換されないことがあるようです。
-----------------------------------------------------------------------------------
メモ
・大勢としてwwwには半角カナを使用しても構わない。
過去との互換性のためとはいえ、Unicodeでもサポートされているので当面使用に支障はない。
・メールはISO-2022-JPを使用している限り、半角カナは避けるべき。
エンコードが違えば（例えばUTF-8なら）問題ない。
・どちらかというと、半角カナより機種依存文字（NEC特殊文字、IBM拡張文字）の方が厄介。
＃『mb_convert_encoding と UTF-8 の誤変換問題』（～波線が化ける）というのもある。
http://shain.blog.conextivo.com/2007/07/php_mb_convert_encoding_utf8.html
http://blog.livedoor.jp/dankogai/archives/50488765.html
この場合、「sjis-win」または「eucjp-win」というエンコーディングを使えば
回避できることがある。
・半角カナはエンコードによりバイト数が異なる。
Shift-JIS : 1byte
EUC-JP : 2byte (先頭１バイトに8Eが入る)
UTF-8 : 3byte (先頭２バイトにEFBD, EFBE が入る)
UTF-16 : 2byte
文字数カウントはシステムにより実装がばらばらなので注意すること。
・PHPの文字化けは基本的に自動変換しようとしたときに起きる。
よって、出来る限りエンコードを明示することで回避できることが多い。
・「半角カナは化ける」という話は以下の理由が大きい。
1.メールで使用できない（文字エンコードISO-2022-JPに含まれていないため）
2.Shift_JISの半角カナは、EUC-JP文字列と区別がつかない。
またEUC-JPの半角カナと、Shift_JIS文字列とでも区別がつかない。
よって文字コードの判定ミスが出やすい。
2010年11月09日
WMIが壊れた
サブマシンの共有フォルダが利用できなくなりました。
しばらく使ってなかったのでファイアウォールかなーとか思い、
ネットワーク接続からローカルエリア接続のプロパティを開いて詳細設定タブを押すと
『この接続のプロパティを表示できません。
Windows Management Instrumentation (WMI) 情報が壊れている可能性があります。
修正するには、システムの復元を使って
Windows をそれ以前の時点 (復元ポイントと呼ばれます) まで復元します。
システムの復元は [アクセサリ] の [システム ツール] フォルダにあります。』
のようなエラーが出てました。
サービスを確認したところ「Windows Management Instrumentation」サービスは
問題なく動いている様子。
検索するとマイクロソフトのサポートページが見つかりました。
http://support.microsoft.com/default.aspx?scid=kb%3Bja%3B823775
方法 1 : コンピュータを以前の復元ポイントに復元する
「個人データ ファイルを失うことなくコンピュータを以前の状態に復元することができます」
って書いてあるけど、
確かにファイルは残るかもしれないけど個人の設定情報は失うだろ・・・とか思いつつ
試してみました。
が、保存領域が少なかったため直近のものしか残ってない。ダメ。
方法 2 : Windows インストールを修復する
これは却下。いくらなんでも乱暴すぎないですか。
他への影響が怖い。
更に検索すると、このページが見つかった。
http://shunichi.hosono.com/2004/10/windows_management_instrumenta.html
方法 ３ : %SystemRoot%\System32\Wbem\Repository フォルダ\Wbem\Repository フォルダのファイルを削除して、ＰＣを再起動する
ページ内のマイクロソフトへのリンクは切れていましたが、
検索すると同様の情報は見つかりました。
http://www.gan.st/gan/blog/index.php?itemid=1341
まずサービスの「Windows Management Instrumentation」を停止させ、
その後に「C:\WINDOWS\system32\wbem\Repository」フォルダを削除するとのこと。
試しましたがダメでした。
というかRepositoryフォルダの中身が復活しない。。。
方法 ４ : イベントログサービスを「有効」にする
サービスを確認しましたが、イベントログサービスは「有効」になってました。
念のため「Event Log」サービスを再起動して
「Windows Management Instrumentation」サービスも起動させてみましたが変わらず。
更に検索すると、「WMI の FAQ: トラブルシューティングとヒント」というページが。
http://technet.microsoft.com/ja-jp/scriptcenter/ff576025.aspx
そこに リポジトリを再構築する、という項目が。
方法３でやった\Wbem\Repository フォルダの内容を手動で再構築できるらしい。
方法 ５ : リポジトリを手動で再構築する
手順としては方法３を行ったあと
レジストリ キー HKLM\Software\Microsoft\WBEM\CIMOM\Autorecover MOFs から
これまでインストールされてきた MOFファイルのリストを取得し、
それらをMofcomp.exe で再コンパイルしていく、といった作業になるらしい。
----------------
Mofcomp C:\WINDOWS\system32\WBEM\cimwin32.mof
Mofcomp C:\WINDOWS\system32\WBEM\cimwin32.mfl
Mofcomp C:\WINDOWS\system32\WBEM\system.mof
Mofcomp C:\WINDOWS\system32\WBEM\wmipcima.mof
Mofcomp C:\WINDOWS\system32\WBEM\wmipcima.mfl
：
----------------
みたいな感じでバッチファイルを作り、実行！
したところコンパイルエラーが…。
mofcomp.logで確認すると
(Tue Nov 09 10:00:00 2010.1390218) : MOF ファイルの解析中: C:\WINDOWS\system32\WBEM\cimwin32.mof
(Tue Nov 09 10:00:00 2010.1391703) : オブジェクト 1 (行 8 - 11 に定義されている) の名前空間を開こうとしてエラーが発生しました:
(Tue Nov 09 10:00:00 2010.1391703) : エラー番号: 0x8004100a, 機能: WMI, 説明: 重要なエラーです
(Tue Nov 09 10:00:00 2010.1391718) : コンパイラによってエラー 0x8004100a が返されました
のようなエラーが延々と。
というか1年前から出ていたようです。
名前空間が開けないってのが、これが原因ですね。。。
とりあえず今回は時間がないので、続きはまた今度にします。
しばらく使ってなかったのでファイアウォールかなーとか思い、
ネットワーク接続からローカルエリア接続のプロパティを開いて詳細設定タブを押すと
『この接続のプロパティを表示できません。
Windows Management Instrumentation (WMI) 情報が壊れている可能性があります。
修正するには、システムの復元を使って
Windows をそれ以前の時点 (復元ポイントと呼ばれます) まで復元します。
システムの復元は [アクセサリ] の [システム ツール] フォルダにあります。』
のようなエラーが出てました。
サービスを確認したところ「Windows Management Instrumentation」サービスは
問題なく動いている様子。
検索するとマイクロソフトのサポートページが見つかりました。
http://support.microsoft.com/default.aspx?scid=kb%3Bja%3B823775
方法 1 : コンピュータを以前の復元ポイントに復元する
「個人データ ファイルを失うことなくコンピュータを以前の状態に復元することができます」
って書いてあるけど、
確かにファイルは残るかもしれないけど個人の設定情報は失うだろ・・・とか思いつつ
試してみました。
が、保存領域が少なかったため直近のものしか残ってない。ダメ。
方法 2 : Windows インストールを修復する
これは却下。いくらなんでも乱暴すぎないですか。
他への影響が怖い。
更に検索すると、このページが見つかった。
http://shunichi.hosono.com/2004/10/windows_management_instrumenta.html
方法 ３ : %SystemRoot%\System32\Wbem\Repository フォルダ\Wbem\Repository フォルダのファイルを削除して、ＰＣを再起動する
ページ内のマイクロソフトへのリンクは切れていましたが、
検索すると同様の情報は見つかりました。
http://www.gan.st/gan/blog/index.php?itemid=1341
まずサービスの「Windows Management Instrumentation」を停止させ、
その後に「C:\WINDOWS\system32\wbem\Repository」フォルダを削除するとのこと。
試しましたがダメでした。
というかRepositoryフォルダの中身が復活しない。。。
方法 ４ : イベントログサービスを「有効」にする
サービスを確認しましたが、イベントログサービスは「有効」になってました。
念のため「Event Log」サービスを再起動して
「Windows Management Instrumentation」サービスも起動させてみましたが変わらず。
更に検索すると、「WMI の FAQ: トラブルシューティングとヒント」というページが。
http://technet.microsoft.com/ja-jp/scriptcenter/ff576025.aspx
そこに リポジトリを再構築する、という項目が。
方法３でやった\Wbem\Repository フォルダの内容を手動で再構築できるらしい。
方法 ５ : リポジトリを手動で再構築する
手順としては方法３を行ったあと
レジストリ キー HKLM\Software\Microsoft\WBEM\CIMOM\Autorecover MOFs から
これまでインストールされてきた MOFファイルのリストを取得し、
それらをMofcomp.exe で再コンパイルしていく、といった作業になるらしい。
----------------
Mofcomp C:\WINDOWS\system32\WBEM\cimwin32.mof
Mofcomp C:\WINDOWS\system32\WBEM\cimwin32.mfl
Mofcomp C:\WINDOWS\system32\WBEM\system.mof
Mofcomp C:\WINDOWS\system32\WBEM\wmipcima.mof
Mofcomp C:\WINDOWS\system32\WBEM\wmipcima.mfl
：
----------------
みたいな感じでバッチファイルを作り、実行！
したところコンパイルエラーが…。
mofcomp.logで確認すると
(Tue Nov 09 10:00:00 2010.1390218) : MOF ファイルの解析中: C:\WINDOWS\system32\WBEM\cimwin32.mof
(Tue Nov 09 10:00:00 2010.1391703) : オブジェクト 1 (行 8 - 11 に定義されている) の名前空間を開こうとしてエラーが発生しました:
(Tue Nov 09 10:00:00 2010.1391703) : エラー番号: 0x8004100a, 機能: WMI, 説明: 重要なエラーです
(Tue Nov 09 10:00:00 2010.1391718) : コンパイラによってエラー 0x8004100a が返されました
のようなエラーが延々と。
というか1年前から出ていたようです。
名前空間が開けないってのが、これが原因ですね。。。
とりあえず今回は時間がないので、続きはまた今度にします。
タグ ：WMI
