meltdown対策パッチをあてたら、WHEA-Logger 19 「内部パリティ エラー」 が爆発してしまった人へ
ちょっと席を外して戻ったら、いつの間にかPCが落ちている。
故障を疑ってイベントログを開くと、ログが変なもので埋まっている。
最近、こんな目にあうことが多いな…、全くWindowsってやつはよぉ…
と想ったので調べてみた。
調べたら、英語圏に偉い人がいたのでわかったけど、日本語のページが出てこなかったのでなんとなく書いて置いておくことにしたよ。
症状
このブログエントリは、下記の特定の場合についてのみ記載されています。
あてはまらない方は、対応を実行しても直らないと思いますのであしからず…。
- Windows OS。
- 2018年1月の、Meltdown/Spectre 対策パッチ （KB4056891/KB4056892/KB4056894 等）をインストールした。
- 対策パッチのインストール後、主に起動時・再起動時に、下記のイベントログが複数回（ときには爆発的な回数で）記録される。
ソース：WHEA-Logger、 イベントID：19
ユーザー：LOCAL SERVICE
「修正されたハードウェア エラーが発生しました。
エラー ソース: 修正されたコンピューター チェック
エラーの種類: 内部パリティ エラー （後略）」
2018年1月の脆弱性ってのはCPUの処理内に存在するので、根本的にはCPUを変える必要がある。んが、そうは言っても何か対策しなくちゃなので、CPUがそのままでも、パッチを当てたOSには「マイクロコード」を実行させることにした。
…んが。 機種や構成によっては、副作用でこんな状況に陥るみたいですね、コレ。
手っ取り早い対応方法（暫定対応）
結論から書くと、レジストリを1件追加すると黙ります。
ものすごくお急ぎの方はこれだけ実行してください （＾＾；）
管理者権限のコマンドプロンプトへコピペ ↓
|
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 1 /f |
マイクロソフトのサイトにも同様の対応が記載されていますが、そのまま書いたんじゃブログの意味がない。 上記コマンドのパラメータ値はサイトとは異なる物になっています。
スイッチの意味
さきほどのレジストリは、リンク先にもある通り「パッチの効果を殺す」スイッチです。
つまりパッチが当たっていない状態と同じになるので、そりゃー黙るわけですが、要するに脆弱性対策されなくなったよ、ということは覚えておくべきです。
何を殺すのか？ については記載がないけれど、海外の有難い人が分析してくれました。
https://forums.lenovo.com/t5/forums/v3_1/forumtopicpage/board-id/tp01_en/thread-id/121585/page/2
01-11-2018 09:48 AM の書き込みがそれ。
マイクロソフトは、レジストリ値「FeatureSettingsOverride」に「3」をセットせよと言ってますが、これを二進数に直すと「11」。
この左側の「1」がmeltdownの無効スイッチで、右側の「1」がspectreの無効スイッチだと言ってくれてます。ひええ。
この両方の無効スイッチをON側 (=1、つまりマイクロコードの対策をOFF) にすることで、冒頭の副作用であるところの WHEA-Logger エラーは解消するんだが、実はこのエラーに影響するスイッチは片方だけ、らしい。
まとめると、「FeatureSettingsOverride」にセットする値は
|
00 = 十進の0 ：WHEAエラー出る、meltdown対策=有効, spectre対策=有効 |
ってことになる。
対策効果を最大限失わず、でもエラーは消したい、っていう場合はマイクロソフトの言うとおりの「3」ではなく、少なくともmeltdown対策だけは有効を維持する「1」が必要十分だよ、と先のリンクの回答者さんは言っているようです。
そして自分のところのPCも、この設定値「1」で確かにエラーが出なくなり、予期せぬダウンから解放されたのでした。 見ず知らずの回答者様ありがとう！
暫定対応ですよ！
というわけで、パッチ適用後に WHEA-Logger が爆発してしまった不運なPCは、spectre対策を無効にすることで動作が復帰するわけです。
じゃー、いつまで無効にしておくのさ？
というとアレだ。 次のパッチが出るまでだろうね。 待ってる！
そして、次のパッチの効果を消さないためにも、今回変えたレジストリのことは忘れちゃいけないんだ。 きっと。
面倒くさいなあもう……。
スポンサー
Windows10 1709 用 リモートサーバー管理ツールで「DNS」が消えてしまったら
中小 Active Directory 管理者の皆様こんにちは。
Windows10のメジャーアップデートを実行すると「リモート管理ツール」が居なくなるっていうアレ、毎回毎回どうにかならんですかね。 しかも、再インストールするとコンポーネントが欠けてるとか… KB出てるけど、要するに不具合でしょ(^-^#)ﾋﾞｷｨ
というわけでそういう話題です。
KB出てるけど、そちらで効果がなかった場合はこちらで回復してくださいませ。
症状
「リモートサーバー管理ツール」がインストールされたWindows10をアップデートすると、ツールが消される。 これ自体は仕様なので、アップデート後のバージョンに適合する管理ツールを取得してインストールすれば良い。
https://www.microsoft.com/ja-JP/download/details.aspx?id=45520
んだけど、現時点でカレントの「1709用（WindowsTH-RSAT_WS_1709-x64.msu）」を実行すると、なぜか「DNS」が欠けた状態でインストールされるんだ…。(^-^#)
管理ツール「DNS」の実ファイル名は「%SystemRoot%\system32\dnsmgmt.msc」。なんだけど、これ自体がPC内に存在しない。つまり、インストールされていないというわけ。
このとき「Windowsの機能」を確認すると、チェックボックスはONになっている。OFF->ONしても状況は変わらず、効果なし。
普通の対処法
該当するKBが出てます。
自動翻訳がガタガタだが、気にせず原語版の通りに実行しましょう(^-^#)
要約すると、まずは更新プログラム「KB2693643」をアンインストール。エラーが出るけど構わずにOKボタンを押し、再起動させて先に進む。
あとの手順はくだくだ書いてもKBの通りなので、ダウンロードからファイルの設置・実行については省略。 要するに、KBに記された下記の3ファイルが、ローカルPCの同一フォルダに並んだ状態にして処理を始めれば良い。
- WindowsTH-RSAT_WS_1709-x64.msu（管理ツールのインストーラー。赤文字は環境にあわせて）
- unattend_x64.xml（KBのサンプルをコピペして保存）
- installx64.bat（KBのサンプルをコピペして保存）
それでもダメだったら？
つまり、自分の環境ではダメだったわけだが(^-^#) ﾋﾞｷﾋﾞｷ
まあ、自分の環境はCBBの都合で、周回遅れの1703にアップデートされてる。
1703に1709のプログラムを実行したから駄目だったのか？ いやそうでもないだろう（きっと）
というわけで先ほどのバッチファイルをじっくり見てみる。
まず、バッチファイルの末尾の行
[rmdir ex /s /q]
を消して再実行すると、バッチファイル内で展開された一時フォルダが消されずに残る。
すると、一時フォルダ（つまり、インストーラー）の階層内にはにちゃんとDNS管理ツールの実体、「dnsmgmt.msc」が存在することがわかった。
なんて長いフォルダ名なんだ（怒）
ともあれ、インストールという処理は要するにファイルコピーなのであるから、この実体をしかるべき場所に置いてやれば良い。
そこにあるファイル、および依存性があってかつ現在のPCに足りないファイルを、それぞれ下記の場所にコピーする。日本語環境でない人は赤文字部分を自分のロケールへ変更。
- 本体 (dnsmgmt.msc)
場所：(一時フォルダ)\ex\ex\amd64_microsoft-windows-d..er-snapin.resources_31bf3856ad364e35_10.0.16299.2_ja-jp_4a92b34b2bab1df4
コピー先：%SystemRoot%\system32 - 本体が参照するDLLファイル(dnsmgr.dll)
場所：(一時フォルダ)\ex\ex\amd64_microsoft-windows-dns-server-snapin_31bf3856ad364e35_10.0.16299.2_none_946c2f555824ecef
コピー先：%SystemRoot%\system32
コピーしたファイルがdllの場合、置くだけではレジストリに入らないので下記コマンドで登録する。
> cd %SystemRoot%\System32
> regsvr32 dnsmgr.dll
ちなみに、最初にコピーした「dnsmgmt.msc」は中身がXMLなので、これをエディタで見ると、動作に必要なファイル（の、クラスID）がわかる仕組みらしい。
クラスIDが示すファイルが何なのかは、たとえばDNS管理ツールががまともに動く別のPCでregeditを実行して探す（怒）そうするとDLLファイル名が特定できるよ…。
以上で動作条件がそろったはずなので、Cortanaあたりからフルパスで起動してみる。
[%SystemRoot%\System32\dnsmgmt.msc]
そうすると、アイコンは怪しいながらも一応DNSコンソールが起動するようになった。管理できるようになったよ母ちゃん！
ところで右ペイン、前からこんなアイコンだっけ？ 忘れたけど、中身が使用に耐えればいいや…。
あとはショートカット類とスタートメニューのなんちゃって登録をする。
「管理ツール」の一覧に出すには、
- さきほどの dnsmgmt.msc をコピーして、デスクトップにショートカットを作成
- 作成したショートカットを、「DNS」とでもリネームする
- [コントロール パネル\システムとセキュリティ\管理ツール]の場所に管理者でペースト
スタートメニューに出すには、普通に右クリックして登録。あ、名前が「dnsmgmt」で登録されてしまった。 もっとWindowsに詳しければこのへんを正しく登録して、自動で復活するようにできるんだろうけど、もうそのへんは諦める。
DNSマネージャーが使えればいいんだ…。 もういいんだ…。
最後に
ところで、最新の1709を使っている人を含め、この面倒くさい不具合って何だったの？
KB出すのもいいけど、おおもとの配布ファイルも直してくださいお願い。
スポンサー
サーバーが更新できない… Windows Update エラー 0x800F0922 を消すまでの話
Windows Server 2012 R2 のうち1台が、何をどうやってもアップデートできなくなった…。
失敗コードは 0x800F0922。 何を試しても 0x800F0922。
報告され続けるエラー。 再起動にクレームする利用部門。
マイクロソフト様のご指導を戴いてもなお更新できないサーバーに悩むこと3か月、最終的に極々限られた状況にあてはまることがわかり、やっと解決したのでブログを置いておきます。
適応事例
このブログは、下記の条件にあてはまる場合に奏功します。
- Azure仮想マシンである
- 下記の一般的な事項を全部試した後でも、アップデートが失敗し続けて絶対に治らない
- 最新のWindows Update エージェントをスタンドアロンでインストールする
- 問題の更新プログラムを探し、スタンドアロンでインストールする
- テンポラリファイル (C:\Windows\Temp) を全部消す
- SFCコマンドで修復する
- DISMコマンドで修復する
- Windows Update コンポーネントをリセットする
なんか、条件の1行目を見た途端に「あぁ～…」となりそうですが、解決したからまぁいいです。
Azure VMじゃない御方がこのエントリを見ていたら、2行目以降を頑張ってお試しください。
原因と対応方法
Azureの Windows VM では特定のエージェントサービスが稼働しており、そのサービスに関する某レジストリが「何らかの理由で」破損すると、今回のサーバーのように Windows Update できなくなります。
これは純粋にマイクロソフト環境の問題なので、こんなブログでどーこー言わなくても、ちょうど先日新しいドキュメントが公開されていました。（自分のような "踏んじゃったユーザー" が続出したからだろうね！）
こちらをご覧くださいませ↓
https://blogs.technet.microsoft.com/jpaztech/2017/05/16/troubleshooting-patch-installation-failure/
といって終わるのもめんどーくさいので、リンク先を読むのが面倒な人向けに（まさに自分のことなんだがｗ）手順を簡単に抜粋します。
- Azure ゲストエージェントのインストーラーをダウンロードしておく
http://go.microsoft.com/fwlink/?LinkID=394789&clcid=0x409 - c:\Windows\Logs\CBS 以下のログを検索し（行数が多いのでgrep推奨）、下記の記載を見つける
EventAITrace:Provider Microsoft-WindowsAzure-Diagnostics (中略) is missing channels under the channelreferances registry key. 中略の部分には、レジストリキー値が入ります。何種類かある場合はすべて控えておきます。
- レジストリエディタで下記パスを開き、
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Publishers
その下にあるキー群から先ほど控えたキー値を見つけ、削除する - 手順1で取得した Azure ゲストエージェントを再インストールする（再起動不要）
- Windows Update してみる
すると……
ナオッター！
自分は最後の手順のとき、Windows Update ではなく 更新プログラムのスタンドアロンインストールを試しましたが、まぁ公式ドキュメントに情報もあることだし、いきなりアップデートを検索しても大丈夫なんだろうなと思います。
スポンサー
Win8.1でも… BitLockerのPIN入力時に画面真っ青
メーカーリカバリーの古いWindows8を、8.1にアップデートした。
さんざん更新したので、ディスククリーンアップで現れるシステムファイルを全処分した。
遅い言われると嫌だったので、念をいれてデフラグもした。
…きっと、そのなかのどれかが駄目だったんだろうな。
最終的にBitLockerを有効化して再起動したところで、"真っ青で何もない画面" に出会ったわけです。ぐぬぬ～。
現象
この状況は、BitLockerでPINを入力するように設定したPCが、PIN入力画面ではなく「全部真っ青」な画面を表示するというもの。
入力欄が無いので大変ショッキングですが、構わずにPINを入力すると、一応起動するよ…。
入力欄が透明、または背景色で塗りつぶされている状況のようです。
Win10ならば、過去のとある更新プログラムに関連してこの状況が起きることがわかっており、対応策もおっけーです。
→ これ
しかし、今回問題が起きているのはWindows8.1。
Win10用の更新プログラムは当てられず、かといって、先のURLに記載のある代替コマンド
> bfsvc.exe %windir\boot /v
をそのまんま実行しても効果がない。
どうする？
再構築なのか？ …という前に１つだけ試してみたら、うまくいったので書いておきます。
Windows8.1で「PIN入力時の真っ青画面」を直す
Windows10についての、先のURLには重要なヒントが書かれています。
「コンピューターの起動に必要なフォントファイルがシステム パーティションに正しく同期されていることを確認します」と。
つまり、現在のシステムパーティションが正しくない。不足したものを補えば直る。
これと同じことを Windows8.1 の流儀で実行すればいいんじゃないかな。
そうだ。bcdbootコマンドでシステムパーティションを修復する方法が、ちょうどこの部分に相当するはずだ。
というわけで、BitLocker の PIN入力で画面真っ青になったWindows8.1の対応はこんな感じです。
あ、当然ながら「現在のOSが（起動画面以外は）最新で正常」という前提に立っているので、怪しい場合は実行を避けてください。
- まず、現在のBitLockerを解除（次の手順の障害になると思われたので）
- Win8.1ブートメディアから起動して、コンピューターの修復モードでWinPE（コマンドプロンプト）に入る
画面パス：「コンピューターを修復する→トラブルシューティング→詳細オプション→コマンドプロンプト」 - 情報を確認後、システムパーティションをフォーマットする
> diskpart
> list volume
結果はこんな感じ。環境により結果が異なるので、Windowsパーティションのドライブ文字と、システムパーティションのボリューム番号を特定しておく。
以下は赤文字の部分を環境にあわせて読み替えてください。
> select volume 2 ←システムパーティションを選択
> format FS=FAT32 LABEL="SYSTEM" QUICK ←既存と同じ設定でクイックフォーマット
> exit -
Windowsパーティションの情報をシステムパーティションへコピーする
>bcdboot c:\windows /l ja-JP
→「ブートファイルは正常に作成されました」と表示されたら、WinPEを抜けて再起動。 - Windowsが起動したら、あらためてBitLockerを有効化してみる。
PINを設定して… 再起動…
… ナオッター！(；´Д｀)
後から思えば、大げさに修復モードにしなくても、ログインしたまま最後の手順4だけ実行すれば良かったんじゃね？ という気もするけれど、まあいいか…大は小を兼ねるってことで…。
スポンサー
ウィンドウが点滅し続けて往生した人イルー？
特定の環境と「Symantec Endpoint Protection 14 RTM」を組み合わせると、大変な目にあったよーという話。
おおもとのSymantecが問題を認識しているので、いずれ治る問題ではありますが、ここにたどりつくまで大変苦悩したので何となく記載します。
現象
- 起動直後から、何をやってもウィンドウが点滅し続けて（フォーカスが移り続けて）作業にならない。
- イベントログ（アプリケーションログ）が、大量の「esif_assist_64.exe」Application Error ログで埋まり続ける。
要するに、ほぼ使用不可能です。フォーカスを奪われ続けて操作にならんので、状況確認もままなりません。
アプリケーションログはこんな感じ
|
障害が発生しているアプリケーション名: esif_assist_64.exe、バージョン: 0.0.0.0、タイム スタンプ:（略） |
この状況に陥ったPCを "一時的に" 使用可能にするには、下記のプロセスを（できればリモートPCから）KILLすると良いです。
・esif_assist.exe
・esif_uf.exe
この現象が現れる環境
下記が重なったときに現れます。
かなりマイナーな条件だろうけど、踏む人は踏むんだよね…。 そう、自分。（溜息）
- ウィルス対策ソフトが Symantec Endpoint Protection 14（初期出荷バージョン）で、「アプリケーションとデバイス制御」のポリシーを有効にしている
- Windows 8.1 以降、64ビットOS
- Intel(R) Dynamic Platform and Thermal Framework がインストールされている
原因と（当面の）対応方法
Symantecが、問題の事象を認めています。
Intel(R) Dynamic Platform and Thermal Framework に権限がなくてスキャンできないんですって。
下記、一応日本語のURLですが、当ブログ作成時点では英語のまま出ます。
「後日情報更新するから待っててね」とのことで、当面の対応方法が載っている状態。
https://support.symantec.com/ja_JP/article.TECH236488.html
このURLでは2種類の方法が示唆されていて、おおまかに
|
のどちらかで、現象がおさまります。
PCの場所や台数にもよりますが、(a) は面倒なだけなので (b) がお勧め。
以下、SEPMをお使いの管理者様にだけ通じる画面操作です。
|
今後の対応
今後、SEPMが正しく修正されたら、この例外は不要になるはずなので、リリースノートを確認のうえ削除。
もし、まだ修正されていない方がこのブログを見た場合は、「とりあえずSEPMをバージョンアップしてみる」というのが第一弾の対応になります。
というわけで…
今回は「Symantec Endpoint Protection 14」の初期バージョンに関する問題でした。
いくら「最新版が当たり前」「旧バージョンはダメ」と言われるセキュリティ対策であっても、世の中のすべての環境に最初から対応できるわけではないですね。
何かをバージョンアップする前後は、常に「何かあるかも」と思っておかなくちゃいかんし、だからといって旧版に固執し続けるわけにもゆかんのでした。あー疲れる。
スポンサー
OneDriveの同期監査を過大評価するべからず
「細かすぎるほどのログが出るんです。ともかく逐一の記録が全部取れているので、まずは安心なんですよ。詳しくはテクニカルサポートへ」
…などどいうザックリしたトークで、中小企業担当者への売り込みは大丈夫と思っている（らしき）営業諸兄の多いこと、多いこと。
でもまぁ本当なら正式に使い倒してやんよと思って、新しくなったOffice365 管理センターから OneDrive for Businessまわりの「監査ログ」（管理者とユーザーのアクティビティ）を真面目に見てみたわけです。
欲しいログについて考えてみる
OneDriveへのアクセス経路は主に２種類あります。
- Office365のブラウザ画面から、「メニュー→OneDrive」と進むもの。
ここへは、ドラッグ＆ドロップでアップロードしたり、ブラウザ上でファイルを共有・改廃したりします。 - PCに同期フォルダを作成し、PC上で行う改廃をOneDriveへ常に同期させておくもの。
情報漏洩を気にする側としては、どちらも相当嬉しくない機能ですが、今回主に書くのは後者のほう。OneDrive for Business 同期フォルダのあるPCで、あるファイルを改廃するとします。
「監査ログを取る」といって管理者が思い浮かべるのは、こんな感じじゃないかな。
| yyyymmdd | 新規作成 | 報告書テンプレート.xlsx |
| yyyymmdd | リネーム | ●月●日報告書.xlsx from 報告書テンプレート.xlsx |
| yyyymmdd | ファイルを開く | ●月●日報告書.xlsx |
| yyyymmdd | 上書き保存 | ●月●日報告書.xlsx |
| yyyymmdd | 上書き保存 | ●月●日報告書.xlsx |
| yyyymmdd | ファイルを閉じる | ●月●日報告書.xlsx |
| yyyymmdd | 削除 | ●月●日報告書.xlsx |
実際に取れる内容
実際に同期フォルダで操作を行い、Office365セキュリティパネル「ファイルとフォルダーのアクティビティ」「同期アクティビティ」を検索すると、こんな感じに取れます。括弧内の文言はログをダウンロードした際のオペレーション名。
（画面上は日本語/日本時刻でも、ファイルでダウンロードすると英語/太平洋標準時になるんだよな…orz）
| yyyymmdd | アップロード(FileSyncUploadedFull) | 報告書テンプレート.xlsx |
| yyyymmdd | リネーム(FileRenamed) | ●月●日報告書.xlsx from 報告書テンプレート.xlsx |
| yyyymmdd | アップロード(FileSyncUploadedFull) | ●月●日報告書.xlsx |
| yyyymmdd | 削除(FileDeleted) | ●月●日報告書.xlsx |
ん？ 少なくね？
具体的には、「開く」「閉じる」と「上書き保存」が足りなくね？
そう、少ないです。これはOffice365の監査内容選択画面でも確認できます。
現在、同期に関して取れるログのバリエーションは下記に限られます。
蛇足ですが、同期クライアントが古いとログそのものが出なかったりします。
これに対し、もう１つのアクセス経路、Webブラウザからのアクセスの場合はもう少し細かいバリエーションがあります。
まあこれだけ取れていれば、冒頭の営業ご担当のトークは間違っていない。
ただし、当てはまるのはブラウザ経由で改廃したときだけなんだな。
PC上で改廃して同期する場合と、ブラウザへログインして改廃した場合とで、取れるログが違う。記録のタイミングも違う。このことには注意する必要があります。
OneDrive同期フォルダ上で行う改廃を監査したい時の注意点をまとめるとこんな感じ
- 上書き保存は（オンラインで実行されていても）ログに出ない。
ファイルを閉じてはじめて、「FileSyncUploadedFull」の発生が記録される。 - PCがオフラインであれば、ファイルを閉じても当然アップロードされないので、その時点ではログに出ない。
PCのタスクバー通知領域にある同期クライアントのアイコンをよく見ると、確かにファイルの編集中はずっと「同期中マーク」が出ており、アップロードされていないことがわかります。
そのログは正しいのか？
さて、ここで問題…。
- 上書き保存をしてからしばらく放置し、そしてファイルを閉じた場合、
ログの更新日時はいつになるのか？ - このPCがオフラインで改廃したファイルは、いつの、どんな改廃として記録されているのか？
１も２も、記録されるのは「FileSyncUploadedFull」の発生日時、それだけです。
つまり、実際にユーザーが改廃・保存した日時ではない。
しかも、起動しっぱなしのPCでファイルを開きっぱなしだと、いつまでもログが上がってこない。
さんざん改廃したファイルのはずが、「最後にアップロードされた日時」という、たった1件のログになるわけです。もう一度書くけど、「閉じられた後に、ファイルが壊れていなければ、オンラインになった後で」という条件つきで。
「細けえことはいいんだよ」って言えるだろうか？
すわ、なんらかの事故が起きた。 ユーザーAの勤務状況と、受付端末の改廃履歴を突き合わせたくなった。
彼がその場で真面目に勤務していれば、間断なく報告書が更新されているはずだ。報告書はOneDrive同期フォルダを経由して、クラウドへ逐次アップロードされているから安心。
そんな風に思って、取り寄せてみた受付端末のログは、そして最新であるはずのクラウド上のファイルは……。
………。
ってなことになるんですけど。
今のところ、「強力な監査ログ」なーんて宣伝されても、あまり都合のいい想像をしないほうが良いですわよ奥様。
監査ログをうたうものが現れたら、それが何を監査するのか、自分の期待値と合っているのか、よくよく確認するこってす。合っているならハッピーです。
そして、ある日に失望したとしても、はたまたホッと安心したとしても、この手のサービスは勝手にバージョンアップしやがるので、折に触れて確認を怠らないこってす。
めんどくさい！
スポンサー
Surface専用 ロックのはずれないTPMをクリアするコマンド
少し古いですが、Surfaceサポートに聞いた内容です。
Surface 3 / Surface Pro 3 の複数台で再現と成功が重なったので記載してみます。
！Surface以外では大変ヤバイと思われるので実行しないでね！
！Surfaceであっても、お手元の状況確認と実行判断は自己責任です！
適応事例
インストールメディアから新規構築した Surface 3 / Surface 3 Pro Windows8.1 で、BitLockerを有効化すると
「TPM が辞書攻撃に備えてタイムアウト期間に入っています」
のメッセージになり、どうしてもロックがはずれない場合。
当方では、Win10プリインストールやWin10構築済みのSurfaceをフォーマットし、Win8.1+ドメイン参加・OSアップデート済 とした後の複数台で再現し、後述のコマンドで回復しました。
理由は不明です。 というか、調査していない (^_^;) ﾜｶﾘﾏｾｰﾝ
そんなときのお助けコマンド。
対応コマンド
サポートから貰った内容そのままです。
冒頭にも記しましたが、コマンドとキーは固有値が盛り盛りなので、他メーカーや他機種で実行すると致命的なことになるかもしれません。
新規構築しただけの Surface 3 / Surface 3 pro (Windows8.1 +Update) で問題が発生した時に限り、お試しください。
- 管理者モードでコマンドプロンプトを起動
- > powershell で PowerShell モードに入る
- 下記 3 行のコマンドを、1 行ずつ順番に実行する
> $Tpm = Get-WmiObject -class Win32_Tpm -namespace "root\CIMv2\Security\MicrosoftTpm"
> $ConfirmationStatus = $Tpm.GetPhysicalPresenceConfirmationStatus(22).ConfirmationStatus
> if($ConfirmationStatus -ne 4) {$Tpm.SetPhysicalPresenceRequest(22)} - 再起動 (途中で F12 の押下を求められた場合は、押す)
- 再度ロックアウト画面にならず、BitLocker の設定が実行出来ることを確認する
スポンサー
