Windows プラットフォーム サポートの佐々木です。

タスク スケジューラにスケジュールした、第 2 週/第 4 週のタスクが、14 日、または 28 日に該当する場合、タスクが 1 週前にずれて実行される動作を確認しており、発生条件詳細や、発生原因については、現在調査中になります。調査状況に進展があり次第、本ブログにて情報をアップデート予定です。

以下は、第 2 週/第 4 週にスケジュールされたタスク (青丸) を例とした、実際のタスクが開始される日 (赤丸)、スケジュールどおりにタスクが実行される日 (緑丸) は、以下のとおりになります。

この動作は、以下の OS で発生する事象であることを確認しております。
・Windows 10 Version 1511
・Windows 10 Version 1607
・Windows 10 Version 1703
・Windows 10 Version 1709

以下の OS では発生しないことを確認しております。
・Windows 7
・Windows 8.1
・Windows 10 Version 1507

回避策

現在、OS の設定変更などによる回避策は確認できておりません。
回避策が判明次第、本ブログにて情報を更新いたします。

恐れ入りますが、タスクのトリガーを [毎週] に設定いただいた上で、現在の日付が第何週目であるかを計算するバッチ ファイルなどを登録いただき、該当する曜日にのみ、開始したいアプリケーションや、スクリプトを実行するなどのご検討をお願いいたします。

事象が再現するシナリオ

本事象が発生するシナリオについて、第 2 週の金曜日が 14 日に該当する 2017 年 7 月を例にして説明します。

1. 新しいタスクを作成します。

[新しいトリガー] 画面にて、以下の設定を行います。
設定: “毎月”
開始: <2017/06/30> <13:00:00>
月: “すべての月を選択”
曜日: <“第 2” “第 4”> <金曜日>

※ タスク作成時の [次回実行時刻] は、”2017/07/14 13:00:00″ になっています。

2. 2017 年 7 月 7 日 13:00 (第 1 金曜日) のタスクの状況です。

※ 13:00 になると、タスクが開始されます。(本来実行される日時ではありません。)
※ [次回実行時刻] は、”2017/07/14 13:00:00″ のままです。

3. 2017 年 7 月 14 日 13:00 (第 2 金曜日) のタスクの状況です。

※ 13:00 になっても、タスクは開始されません。(本来タスクが実行される日時です。)
※ [次回実行時刻] は、”2017/07/28 13:00:00″ に更新されます。

4. 2017 年 7 月 21 日 12:58 (第 3 金曜日) のタスクの状況です。

※ 13:00 になると、タスクが開始されます。(本来実行される日時ではありません。)
※ [次回実行時刻] が、”2017/07/28 13:00:00″ のままです。

5. 2017 年 7 月 28 日 13:00 (第 4 金曜日) のタスクの状況です。

※ 13:00 になっても、タスクは開始されません。(本来タスクが実行される日時です。)
※ [次回実行時刻] が、”2017/08/11 13:00:00″ と表示されます。

8 月 11 日と 8 月 25 日は期待どおりにタスクが開始されます。

こんにちは。Windows プラットフォーム サポートの大川です。
今回は Hyper-V 環境の仮想マシンバックアップのタイムアウトについてお伝えさせていただきます。

仮想マシンの構成変更後や仮想マシン自体を格納しているディスクに障害が発生し、仮想マシンが起動できない場合に備えて、
仮想マシンのバックアップを Hyper-V ホストから取得いただいていると思います。

仮想マシンのバックアップは Hyper-V 環境のバックアップに対応した 3rd party 製のソフトウェアや弊社の製品である
Data Proctection Manager (DPM) やWindows Server バックアップを利用することで取得が可能です。

Hyper-V ホストからバックアップソフトを使用してバックアップを取得する場合、Hyper-V のコンポーネントや VSS が
連携し、整合性のあるバックアップデータが取れるように動作します。仮想マシンバックアップの流れとコンポーネントは
以下のとおりです。

// Hyper-V 仮想マシンのバックアップに関連するコンポーネント
1. バックアップ リクエスター
DPM や Windows Server バックアップなどのバックアップ処理を命令するコンポーネント

2. Hyper-V ホスト上の VSS
VSS を制御するコンポーネント。仮想マシンの vhdx 静止点やスナップショットを取得するコンポーネント

3. 仮想マシン上の統合サービス
Hyper-V ホスト上の VSS と連携するコンポーネント

4. 仮想マシン上の VSS
VSS を制御するコンポーネント。仮想マシン上のデータの静止点やスナップショットを取得するコンポーネント

ここで 1 点注意点があります。それは、”4.仮想マシン上の統合サービス″ にタイムアウト値が存在している点です。
このタイムアウト値は仮想マシン 内での VSS 処理の時間を監視しており、10 分以内に完了しない場合、仮想マシン
内で処理中であっても、Hyper-Vホストに対して後続処理をするように命令をします。その結果、仮想マシン 内の
データは整合性が取られていない状態でバックアップされます。この状態でリストアした場合、仮想マシンの回復
ができない可能性があります。また、この 10 分は固定であり、設定などにより変更することができません。

仮想マシン 内での VSS 処理に時間がかかるケースとしては、以下が考えられます。

1.仮想マシン 内で多くの VSS スナップショットが取得されている場合
2.仮想マシン 内で非常に大きなボリュームに対して、VSS スナップショットが取得されている場合

上記は仮想マシン内のデータの静止点を取る際に、VSS スナップショット作成処理が行われますが、この際に、
仮想マシン 内の “スナップショットの列挙処理” が行われるためです。この “スナップショットの列挙処理” は
仮想マシン内の全てのスナップショットについて ID や属性情報などを取得します。そのため、スナップショットの数が
多い場合には、本処理に時間がかかります。また、各スナップショットにおいて、ボリューム上のどのデータを
保護しているのかも確認しているため、ボリュームサイズの大きさに比例して処理に時間を要します。

もし、本事象が発生した場合には、仮想マシン内のイベントログに以下のイベントがセットで記録されます。

===
ログの名前:         System
ソース:           volsnap
日付:            XXXX/XX/XX XX:XX:XX
イベント ID:       16
タスクのカテゴリ:      なし
レベル:           エラー
キーワード:         クラシック
ユーザー:          N/A
コンピューター:       XXXXX
説明:
The shadow copies of volume \\?…XXX-XXXX-XXXX-XXXXXXXXXXXX} were aborted because volume \\?…XXX-XXXX-XXXX-XXXXXXXXXXXX},
which contains shadow copy storage for this shadow copy, was force dismounted.
===

===
ログの名前:         System
ソース:           disk
日付:            XXXX/XX/XX XX:XX:XX
イベント ID:       51
タスクのカテゴリ:      なし
レベル:           警告
キーワード:         クラシック
ユーザー:          N/A
コンピューター:       XXXXX
説明:
ページング操作中にデバイス \Device\HarddiskX\DRXX 上でエラーが検出されました。
===

===
ログの名前:         System
ソース:           Microsoft-Windows-Ntfs
日付:            XXXX/XX/XX XX:XX:XX
イベント ID:       140
タスクのカテゴリ:      なし
レベル:           警告
キーワード:         (8)
ユーザー:          SYSTEM
コンピューター:       XXXXX
説明:
トランザクション ログへのデータのフラッシュに失敗しました。VolumeId: \\?\Volume{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}、
DeviceName: \Device\HarddiskVolumeXX で破損が発生している可能性があります。
(存在しないデバイスを指定しました。)
===

===
ログの名前:         System
ソース:           disk
日付:            XXXX/XX/XX XX:XX:XX
イベント ID:       157
タスクのカテゴリ:      なし
レベル:           警告
キーワード:         クラシック
ユーザー:          N/A
コンピューター:       XXXXX
説明:
ディスク X が突然取り外されました。
===

上記のイベントがセットで記録されている場合には、タイムアウトが発生している可能性がありますので、
以下の対処策の実施についてご検討いただければと思います。

[対処策1]
仮想マシン内で作成するスナップショットの世代数を減らす。

スナップショットの世代数が増えることに比例して、”スナップショットの列挙処理”  の時間も長くなります。
そのため、vssadmin list shadows コマンドで作成されているスナップショットを確認し、 vssadmin delete shadows
コマンドでスナップショットを削除することをご検討いただければと思います。

Vssadmin list shadows
https://technet.microsoft.com/ja-jp/library/cc788116(v=ws.10).aspx

Vssadmin delete shadows
https://technet.microsoft.com/ja-jp/library/cc788026(v=ws.10).aspx

もし、vssadmin delete shadows コマンドでも削除できないスナップショットが存在する場合は、diskshadows コマンド
にて削除を試してもらえればと思います。diskshadows コマンドについての詳細は以下を参照ください。

vssadmin コマンドでシャドウ コピーが削除できない場合の対処方法について

また、[シャドウ コピーの構成] 画面の設定から作成されるスナップショットは既定では 64 世代まで作成することが
可能になっています。このスナップショットで作成できる既定の世代数は以下のレジストリにて制御が可能ですので、
こちらの設定についてもご検討ください。

// スナップショットの世代数設定
—————————————————————————————————————-
1. [スタート] – [ファイル名を指定して実行] をクリックし、regedit と入力し、OK ボタンをクリックします。

2. 以下のレジストリキーをご確認いただき、クリックします。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS\Settings

3. メニューバーより、[編集] – [新規] を選択し、[DWORD 値] をクリックします。

4. MaxShadowCopies と入力し、Enter キーを押します。

5. 続けて、[編集] – [修正] をクリックします。

6. 設定する世代数を入力し、[OK] をクリックします。

7. メニューバーより、[ファイル] – [レジストリエディタの終了] で終了します。

8. コンピュータを再起動します。
—–

※ バックアップソフトにより作成されたスナップショットは上記のレジストリでも世代数を制御することができません。
その場合は、diskshadow コマンドにより、スナップショットを定期的に削除する必要があります。

[対処策2]
VSS スナップショットを取得している大きなボリュームを縮小する。

“スナップショットの列挙処理” はボリュームの大きさに比例しても処理時間が長くなります。そのため、
対象ボリュームを縮小することもご検討ください。ボリュームのサイズがどれぐらいの大きさにより
本事象が発生するのかは環境に依存するところがありますが、これまでの報告事例では数十 TB を超える
ボリュームを利用しているマシンで発生しています。

ボリュームの縮小方法は以下のとおりです。

// ボリュームの縮小方法
—————————————————————————————————————-
1. [スタート] – [ファイル名を指定して実行] をクリックし、diskmgmt.msc と入力し、OK ボタンをクリックします。

2. ディスクの管理画面が開きますので、対象のボリュームを右クリックし、[ボリュームの縮小] をクリックします。

3. 縮小可能なサイズが表示されますので、そのサイズ内に収まるサイズを入力し、[縮小] をクリックします。

4. ボリュームが縮小されたことを確認します。
—–

本ブログが少しでも皆様のお役に立てますと幸いです。

こんにちは、日本マイクロソフトの Windows サポートチームです。
今回は、Windows 10 での UWF (Unified Write Filter) に対して uwfmgr コマンドによる除外設定を行った場合の留意事項についてご紹介します。

<事象>
UWFMGR コマンドにて、パスが長いファイルやレジストリを対象として除外設定を行う場合、登録 (add) 操作は行えますが、削除 (remove) できない問題が発生します。

一例ですが、以下のように長いレジストリ パスに対して、除外設定の登録・削除を行った際、削除時にエラーが発生する場合があります。この現象は異なるレジストリ パスを対象とした場合も文字数によっては同様のエラーが発生します。

– 除外設定を登録 (add) します
uwfmgr registry add-exclusion HKLM\ControlSet001\Control\Power\User\PowerSchemes\381b4222-f694-41f0-9685-ff5bb260df2e\245d8541-3943-4422-b025-13a784f679b7\12345678-1234-1234-1234-12345678901234567890123

– 除外設定を削除 (remove) します
uwfmgr registry remove-exclusion HKLM\ControlSet001\Control\Power\User\PowerSchemes\381b4222-f694-41f0-9685-ff5bb260df2e\245d8541-3943-4422-b025-13a784f679b7\12345678-1234-1234-1234-12345678901234567890123レジストリー キー <Registry> は除外一覧に含まれません – アクションは実行されません。

上述の通り、登録したレジストリ パスを削除 (remove) する際にエラーが発生し、削除することができません。

<原因>
UWF 除外設定の登録 (add) を行うと、パスがノード パスに変換され、内部的なリストに追加されます。削除 (remove) を行う場合、UWFMGR は指定されたパスをノード パスに変換した上で削除を試みますが、この際に UWFMGR が使用するバッファー サイズが十分な大きさを持たないため、ノード パスに変換する時点でバッファーに格納できない部分のパスが切り捨てられます。
この結果、登録 (add) したパスと、削除 (remove) しようとするパスに差異が生じてしまい、削除対象のパスが見つからないと判断された結果、削除に失敗します。

<対処策>
本事象は、以下公開情報にある Windows PowerShell スクリプトで Windows Management Instrumentation（WMI）インターフェイスを使用いただくことで、長いパスに対しても削除  (remove)  の操作が行えます。
スクリプトのサンプルについては、以下公開情報内の “Remarks” にある “Example” を参考としていただき、ご利用環境に合わせてコンピューター名を変更するなどの上ご利用ください。

UWF_RegistryFilter (Industry 8.1)
https://msdn.microsoft.com/en-us/library/dn449297.aspx

こんにちは、日本マイクロソフト Windows サポート チームです。

今回は、Windows 10 にて追加された Windows 10 Version 1709 への更新を促す画面について紹介します。

12 月 7 日に提供された下記の更新プログラムは Windows 10 での out-of-box experience (OOBE) において、最新の Windows 10 Version 1709 へのアップデートができるようにオプションを提供する更新を行います。

OOBE update for Windows 10 Version 1703: December 7, 2017 (KB4054505)
https://support.microsoft.com/en-us/help/4054505/oobe-update-for-windows-10-version-1703-december-7-2017-kb4054505

OOBE update for Windows 10 Version 1607: December 7, 2017 (KB4054507)
https://support.microsoft.com/en-us/help/4054507/oobe-update-for-windows-10-version-1607-december-7-2017-kb4054507

上記の更新プログラムが適用された環境では、アカウント ログオン時の初期セットアップ ( OOBE ) の際に [お使いの PC には、適用可能な更新プログラムがあります] の画面が表示されることがございます。

お客様によっては、Version 1709 への更新のタイミングをご調整いただいていらっしゃると存じます。画面左下の [今は実行しない] をクリックすると更新をスキップすることができます。

なお、[更新する] ボタンをクリックしますと、下記のように更新が開始されます。

更新が開始されるまでの間 [PC の更新中にデスクトップに移動する] をクリックすると、インストールまではデスクトップ操作が行えます。

この画面が表示される OOBE のタイミングは、該当の Windows 10 をオンライン環境でセットアップした時や、前述の更新プログラムが適用されている際に管理者権限を有するユーザーが初めてその端末にログオンされる時に該当します。

更新が不必要である場合、前述の通り [今は実行しない] をクリックし、更新をスキップしてください。また、更新を促す画面の表示自体を抑止されたい場合、大変お手数ではございますが以下いずれかの回避策をご検討ください。

方法 1.

セットアップ時はオフライン環境にて作業を実施ください。

方法 2.

セットアップ後のログオン時の表示は以下のポリシー、レジストリにてログオン時のアニメーション表示を抑止ください。

方法 2-A. グループポリシーを利用する場合

次のグループ ポリシー設定を [無効] に設定します。
[コンピューターの構成] > [管理用テンプレート] > [システム] > [ログオン] > [初回サインインのアニメーションを表示する]

上記ポリシーで設定される値は以下レジストリ値となります。
キー: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
名前: EnableFirstLogonAnimation
値: 0

方法 2-B. 応答ファイルなどでレジストリから設定を行う場合

次のレジストリ値を設定してください。

キー: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
名前: EnableFirstLogonAnimation
値: 0

以上でございます。

本記事におきましては予告なく内容を変更させていただくことがございます。今後、情報のアップデートがあれば、引き続き本ブログ内にてお知らせいたしますので、恐れ入りますがお待ちいただきますようお願いいたします。

＜補足＞
Windows 10 Version 1703 においてはKB4054505 を適用していなくとも、12 月の累積更新プログラム KB4053580 が適用されている環境にて同画面が表示されることがございます。

[参考情報]
Windows 10 の通知とアップグレード オプションを管理する方法
https://support.microsoft.com/ja-jp/help/3080351/how-to-manage-windows-10-notification-and-upgrade-options

Windows 10 への無料アップグレードを紹介いたしております技術情報中に本ブログにて紹介しておりますポリシー、レジストリを記載いたしております。
これらのポリシー、レジストリは Windows 10 においても有効です。

こんにちは、Windows プラットフォーム サポートです。

本稿では、Windows 10 Fall Creators Update 環境で dwm.exe に対してフック処理を行い、ログオン直後にタッチ処理を行うと STOP エラーが発生する恐れがある点についてご紹介させていただきます。

– 現象

Windows 10 Fall Creators Update 環境において、dwm.exe に対してフック処理を行った場合、ログオン直後にタッチ操作を行うと、STOP エラー (0x1: APC_INDEX_MISMATCH) が発生する恐れがあります。

– 原因

Win32kbase.sys ドライバーに起因する問題 (※ 注意 1) の可能性があります。

– 回避策

dwm.exe に対してフック処理の対象から除外 (※ 注意 2) します。

※ 注意 1. 上記現象発生時に win32kbase.sys の問題か確認するためには詳細な調査 (その一つに現象発生時の完全メモリダンプの解析) が必要です。

※ 注意 2. 2017 年 12 月 25 日現在、弊社で確認している問題については修正に向けて調査をおこなっております。進展あり次第更新いたします。

こんにちは、Windows プラットフォーム サポートの 高谷 です。
今回は Chkdsk プログラムの使い方についてご紹介します。

■ そもそも Chkdsk はどんな時に使うのか？

Chkdsk はWindows XP/2000 から実装されたファイル システムの整合性を確認および修復するツールです。ソース:NTFS イベント ID:55 などのファイル システムの破損を示唆するエラーのイベント ログが発生した場合に、Chkdsk　コマンドを使用します。オプションを指定することで、ファイル システムに不整合が発生している箇所を自動的に修復することができます。オプションを設定せずに Chkdsk 読み取り専用モードで実行することで、整合性の確認のみ (エラーの修復は実行しない) を行うこともできるため、比較的使用する機会の多いコマンドになります。

基本的な構文と使用例を以下に示します。

//読み取り専用モードで Chkdsk を行う場合

>chkdsk [Volume:]

例えば、D ドライブのファイル システムの整合性の確認を行う場合は、以下のようになります。

コマンドの例)

>chkdsk D:

※ドライブを指定しない場合は現在のドライブについて処理が行われます。

なお、Chkdsk の動作につきましては、以下情報が公開されております。

参考資料)
“Chkdsk.exe で使用可能な新しいスイッチ /C および /I について”
https://support.microsoft.com/ja-jp/help/314835/an-explanation-of-the-new-c-and-i-switches-that-are-available-to-use-w

ソース:NTFS イベント ID:55 につきましては以下の公開情報をご確認ください。

参考資料)
“ソース : NTFS、ID: 55 のイベント”

■ 実践的な Chkdsk の利用方法について
.

ファイル システムの破損を修復したいときや、ファイル システムの整合性を確認したいときが Chkdsk コマンドの出番となります。事例をもとに、実践的なChkdsk コマンドの利用方法についてご案内いたします。

【状況】ソース:NTFS イベント ID:55 のイベント ログが記録された。

————————————————————-
イベントの種類: エラー
イベント ソース: NTFS
イベント ID: 55
説明:
ディスク上のファイル システム構造が壊れていて使えません。
chkdsk ユーティリティをボリューム (D:) で実行してください。
————————————————————-

1. まずはファイル システムの整合性を確認したい。

整合性を確認したい場合は、オプションを付けず、読み取り専用モードで実行します。
オンラインでエラーのチェックを行うため、ユーザーが使用中のボリュームでも実行可能です。
結果として対象ボリュームのファイル システムの整合性確認の結果が出力されます。

コマンドの例)

>Chkdsk D:

実行結果において、以下のように表示された場合は、そのボリュームの整合性には問題がなかったことを示しています。

————————————————————-
Windows でファイル システムのスキャンが終了しました。
問題は見つかりませんでした。
これ以上の操作は必要ありません。
————————————————————-

2. ファイル システムの整合性を確認の上、修復も同時に行いたい。

修復まで行う場合には、2 通りの実施方法があります。状況に合わせて使い分けを行いますが、特に理由がなければ /f で十分修復が可能です。/r では膨大な時間を要する場合があります。

2-1. /f のオプションを使用する。

Chkdsk /f で実施する場合は、オフラインでボリューム内のエラーを修復する動作となりますので、ボリュームの一時的な解除が必要となり、ユーザーは対象のボリュームにアクセスすることができない状態となります。

コマンドの例)

>Chkdsk D: /f

2-2. /r のオプションを使用する。

chkdsk /f がインデックスの修正のみを行うのに加えて、ディスクに物理的な破損箇所があるかを検出する (および、該当箇所を使用しないようにマークするなどの) 物理セクターに対する処理が行われるためchkdsk /f より、非常に長い時間を要します。

コマンドの例)

>Chkdsk D: /r

■ /scan および /spotfix オプションについて (Windows Server 2012 以降のみ)
.

ここまでは Windows Server 2008 R2 までの一般的なChkdsk の実行方法について述べました。ここからはWindows Server 2012 以降の OS に新たに追加された /scan および /spotfix というオプションについてご説明いたします。Chkdsk /scan を実施した後に、Chkdsk /spotfix を合わせて行うことで、Chkdsk /f と同等の修復作業を、より短い時間で行うことができるのが特徴です。

– /scan
読み取り専用モードと同じく、オンラインでエラーのチェックを行います。オンライン状態で修復が可能なエラーについては修復を行い、オンラインで修復できないその他のエラー情報については、メタ ファイルに保存されます。

– /spotfix
chkdsk /scan で発見されたオンラインで修復できないエラーについて、オフラインで修復が行われます。chkdsk /spotfix オプションによるオフライン修復では、chkdsk /scan オプションの結果として必要であると判断された領域のみ修復処理が実施されます。そのため、従来の chkdsk /f による修復処理よりも早期に完了する事が期待できます。

参考資料)
“chkdsk の刷新と新しい NTFS 正常性モデルの追加”
http://blogs.msdn.com/b/b8_ja/archive/2012/05/16/chkdsk-ntfs.aspx

■ よくあるお問い合わせ (FAQ)
.

Q1. Chkdsk に失敗するときはどうしたらいい？

Chkdsk に失敗する場合、残念ながらファイル システムを修復する方法がございません。
ディスクのフォーマット、またはシステム バックアップからのデータ リストアによる復旧をご検討くださいますようお願いいたします。

Q2. Chkdsk が終わらないときはどうしたらいい？

Chkdsk を実行すると、(特にChkdsk /f や /r の場合) 長い時間処理を行います。環境にも依存しますが、容量が大きい場合は数日程度かかる場合もございます。さらに、Chkdsk を一旦開始すると、Windows OS 側で中断させる方法がありません。可能な限りChkdsk による修復処理をお待ちいただく事を推奨します。
また、以下の理由から、強制的に終了させる (電源を落とす) ことも推奨しておりません。

1) 対象ボリュームに配置されているフォルダーやファイルのセキュリティ情報が破損し、アクセス権が不正となる (アクセス権の消失)

2) 修復が完了しないため、次回起動時にも Chkdsk による修復処理が行われる。

セキュリティ記述子のチェックおよび修復のフェーズ (フェーズ 3 に該当) に途中で停止した場合、上記 1) が発生する可能性があります。
また、システムの電源を強制的に停止した場合には、NTFS ファイル システム内のトランザクション機能などを用いてファイル システム上の正常性を保つための内部動作が自動的に行われますが、上述の 1) にあたる事象が “Chkdsk.exe” の強制停止により発生した場合には、次回以降の Chkdsk で修復する事は困難となりますので、バックアップ データからの復元などをご実施いただく必要があります。

再起動時自動的に行われる Chkdskを、実施しないようにしたい場合、以下のコマンドにてChkdskをスキップすることが可能です。
※注意：設定を解除しない限りChkdskはスキップされ続けます。

>Chkntfs /x <ボリューム>

例) C ドライブに対して、再起動時に Chkdsk を実行しない場合
>Chkntfs /x C:

参考) 起動時に Chkdsk を実施しない設定を解除するとき
>Chkntfs /d

参考資料)
“Autochk”
https://technet.microsoft.com/en-us/library/cc771787(v=WS.10).aspxaspx

補足) Chkdsk の動作について
Chkdsk の動作は 5 段階のステージで構成されています。
オプションを付けない読み取り専用モードでの実行はステージ 3 まで実行し、/f オプションはステージ 4 まで、/r オプションはステージ 5 まで実行します。

– ステージ 1 : マスタ ファイル テーブル (MFT) 内の各ファイル レコード セグメント (FRS) の検証
– ステージ 2 : ボリューム内のフォルダーの検証
– ステージ 3 : 各ボリュームのセキュリティ記述子の検証
– ステージ 4 と 5 ( オプションのステージ ) : ボリューム内の全てのセクターの読み取り、安定性の確認

Q3. Chkdsk の時間の見積もり方法について教えてほしい。

最後に、Chkdsk の実行時間の見積もり方について、ご説明します。
Chkdsk にかかる時間は、ボリュームの状態、ファイルの数、システムのスペックに依存するため、事前の予測が非常に困難です。
ただし、読み取り専用モードで Chkdsk を実行し、その時間をベースに見積もる方法があります。実際に修復を行う場合には、読み取り専用と比較して 2 倍程度の時間がかかるため、読み取り専用の結果を基に目安の時間を算出する場合には、2 倍程度をお見積りください。

今回は Chkdsk についてご紹介させていただきましたが、いかがでしたでしょうか。
本ブログが少しでも皆様のお役に立てますと幸いです。

こんにちは、Windows プラットフォーム サポートの大川です。
今回は Windows Server バックアップ時に記録される Disk 153 の警告イベントについてお伝えさせていただきます。

まずは、Windows Server バックアップについてですが、本機能は Windows Server 2008 から OS に標準で付属している
バックアップ機能です。システム状態やデータのバックアップ、システム全体の回復を行うためのベア メタル回復などの
機能を提供します。

Windows Server バックアップでバックアップを行うと、バックアップ データは vhd ファイルに保存されます。
バックアップ処理中は、OS が vhd を一時的にマウントし、データが保存されていきます。このとき、マウントされた vhd は
通常のハードディスクドライブのように認識されますので、他のハードディスク ドライブと同様に内部的にディスクを管理する
ための番号が付与されます。バックアップの処理が完了すると、vhd がアンマウントされます。大まかなバックアップ処理の流れ
は以下のとおりです。

// バックアップ処理の概要
—————————————-
バックアップ開始
↓
バックアップ元のシャドウ コピー作成
↓
vhd マウント
↓
データ バックアップ
↓
vhd アンマウント
↓
バックアップ先のシャドウ コピー作成
↓
バックアップ終了
—————————————-

※”バックアップ元のシャドウ コピー作成” はデータの静止点を確保するため、 “バックアップ先のシャドウ コピー作成” は
     バックアップ データの世代管理のために行われます。

上記の概要に記載させていただいたとおり、”vhd マウント” や “vhd アンマウント” などの vhd に対する処理が発生しますが、
このタイミングにより、以下のような Disk 153 の警告イベントが記録される場合があります。

—————————————-
ログの名前:         System
ソース:           Disk
日付:            XXXX/XX/XX XX:XX:XX
イベント ID:       153
タスクのカテゴリ:      なし
レベル:           警告
キーワード:         クラシック
ユーザー:          N/A
コンピューター:       XXXXXXXX
説明:
ディスク X (PDO 名: \Device\XXXXXXXX) の論理ブロック アドレス XXXXXXX で IO 操作が再試行されました。
—————————————-

Disk ID: 153 警告イベントは、対象ディスクに対してデータの取得等を試みた際に、何等かの原因により I/O 要求が
完了せず再処理を実行した際に記録されるイベントです。リトライでも回復されない場合などの問題が生じた場合には、
その上位ドライバーやアプリケーション側に影響が発生します。

もし、Windows Server バックアップがエラーになった場合、バックアップ処理の I/O 要求に問題が発生していた可能性が
考えられますので、Disk 153 のイベントは無視できません。しかし、バックアップに関連したエラーやその他アプリケーション
などのエラーも記録されていない場合には、I/O のリトライ処理により、I/O 要求が正常に終了していると考えられます。
この場合、システムへの影響はありませんので、Disk 153 のイベントは無視可能と判断が可能です。そのため、本イベントを
無視いただくか、監視対象外にするなどについて検討いただければと思います。

なお、この事象が発生している対象ディスクが Windows Server バックアップで利用している vhd であるのかは、
以下から判断することが可能です。

// Disk 153 のイベントが vhd に対して発生しているかの判断
—————————————-
1. Disk 153 が発生しているのが、Windows Server バックアップ処理中に発生している
2. Disk 153 の説明に記載されている “ディスク X” の番号が、通常運用時にディスクの管理画面には存在しない番号である
   ※通常運用時とは、バックアップ処理などを行っていない状態を指しています。
—————————————-

ディスクの管理画面は以下の手順で開くことが可能です。

// ディスクの管理画面の起動手順
—————————————-
1. [スタート] – [ファイル名を指定して実行] を選択します。

2. diskmgmt.msc と入力し、[OK] をクリックします。

3. ディスク X の部分を確認します。

—————————————-

本ブログが少しでも皆様のお役に立てますと幸いです。

皆さん、こんにちは。Windows サポート チームです。
本日は、コンピューター起動時のプリブート画面での文字入力に関する情報を紹介します。

BitLocker ドライブ暗号化機能で、OS がインストールされているドライブ (例えば C:) を暗号化している場合、コンピューター起動時のプリブート画面において、パスワードや PIN、回復パスワード (48 桁の数字のパスワード) などの入力が必要になることがあります。

Windows 10 Creators Update (1703) では、お客様からのご要望を基に、OS 起動前のプリブート画面での文字入力において、NumLock が有効になるよう動作を変更いたしました。

ただ、この変更により、一つのキーにアルファベットと数字が刻印されているようなキーボードでは、NumLock が有効になっていると、アルファベットではなく数字が入力されるため、パスワードや拡張 PIN (※) の入力の際に、意図せず入力誤りを起こす可能性があります。
※ 拡張 PIN：数字だけでなく、アルファベットの大文字、小文字、記号、スペースなどが使用できます

このような場合は、キーボード上の [NumLock] キーを押して、NumLock を解除してから文字を入力してください。

また、BitLocker のパスワードや PIN の入力画面では、[Insert] キーを押すと、実際に入力した文字が表示されるようになります。
そのため、[Insert] キーを押して、正しく入力されていることを確認することで、パスワードや PIN の入力誤りを防ぐことができます。

例えば、PIN の入力画面において、

[Insert] キーを押すと、入力した文字が確認できます。
(ここでは、拡張 PIN を使用しています)

なお、OS としては、NumLock が有効になるように設定していますが、コンピューターのハードウェアやファームウェアの動作によっては、OS 起動前のプリブート画面での文字入力で、NumLock が無効になっている場合もあります。

NumLock が無効になっている動作について詳細を確認する場合は、お使いいただいているハードウェアのメーカー様に動作をご確認ください。

こんにちは。Windows プラットフォーム サポートです。

Windows 7 SP1 もしくは Windows Server 2012 にて Windows 8.1/Windows Server 2012 R2 以降で生成された XPS ファイルを印刷すると以下のエラーが発生する事象が報告されております。

上記事象の発生条件およびシナリオは以下のようになります。

[前提条件]
Windows 7 SP1 に下記 KB2670838 が適用されていること。

KB2670838: Windows 7 SP1 および Windows Server 2008 R2 SP1 用のプラットフォーム更新プログラムについて
https://support.microsoft.com/ja-jp/help/2670838/platform-update-for-windows-7-sp1-and-windows-server-2008-r2-sp1

※ Windows Server 2012 の場合は標準状態で発生します。

[シナリオ]
1. Windows 8.1/Windows Server 2012 R2 以降の OS でメイリオ + Italic(斜体) + Bold(太字)のフォントを含む WEB サイトを XPS ファイルに印刷する、または前述の書体を含むデータを XPS 形式で保存する

2. 上記で生成された XPS ファイルを Windows 7 SP1 + KB2670838 適用環境もしくは Windows Server 2012 から印刷する

3. 上記エラーポップアップが表示され印刷が失敗する

本件は Windows 7 SP1 用の KB2670838 内及び Windows Server 2012 に標準で含まれる XPS 関連ライブラリの問題となり、Windows 8.1 / Windows Server 2012 R2 以降では発生しない問題となります。

[対処策]
Windows 7 SP1 の場合は KB2670838 のアンインストールにて対処できます。Windows Server 2012 の場合は大変申し訳ございませんが Windows Server 2012 R2 へのアップグレードが対処となります。

こんにちは、日本マイクロソフト Windows サポートの高谷です。
今回はWindows Server 2012 以降でのデフラグ処理とスラブ統合の動作についてご紹介します。

■ デフラグ処理とは？

.
デフラグ処理は、ハード ディスクに保存されたデータの配置を整理し、最適化を行うことを指します。最適化を行うと、より効率的にファイルの作成やファイルへのアクセスができるようになります。

公開情報)
“ハード ディスクを整理するには (ディスク デフラグ)”
https://support.microsoft.com/ja-jp/help/880438

最近では仮想技術が進歩し、シン プロビジョニング対応ディスク (仮想プロビジョニング対応ディスク) が普及してきました。シン プロビジョニング対応ディスクでは、必要な量の記憶域が必要なタイミングでストレージから割り当てられる動作をとるため、従来のデフラグ処理を行う必要がありません。
一方で、ストレージから記憶域を割り当てられる記憶域を効率的に利用するために、スラブ統合という概念が生まれました。

■ スラブ統合とは？

.
シン プロビジョニング対応ディスクの特徴として、必要なタイミングで必要な分の領域がストレージから割り当てられる仕組みになっています。
割り当ては “スラブ” と呼ばれるストレージ割り当ての管理単位で行われ、データのサイズに合わせてスラブが必要な個数、仮想ディスクに対して割り当てられます。

例) 100 GB の仮想プロビジョニング対応ディスクを 1 つ作成した場合、ストレージから100 GB の利用可能な記憶域が即時に割り当てられるわけではなく、初めは最小限のサイズでディスクが作成され、その後、必要に応じて 100 GB まで拡張される動作を取ります。

日々の運用の中でデータの変更や削除が発生した場合に、使用率の低いスラブや空のスラブが発生しますので、ストレージの記憶域を効率的に利用するためには、スラブ内のデータを整理し、空になったスラブをストレージへ返却する必要があります。このスラブの整理とストレージへの返却の動作を、”スラブ統合” と呼びます。

“最適化” という意味合いにおいては、デフラグ処理とスラブ統合は同じことを指しているため、実施のコマンドも同じく defrag を使用し、付加するオプションで動作を切り替えます。

■ Defrag のコマンドについて

.
Defrag には様々なオプションがあります。オプションによって、従来のデフラグ処理を行うか、スラブ統合を行うかを指定することができます。コマンドの使用方法について本節ではご紹介します。

1. 従来通りのデフラグ処理 (ハード ディスクに対する最適化処理)を行いたい場合

オプションなし、もしくは /D オプションを付加し、その後に対象のドライブを指定することで従来通りのデフラグ処理を対象ドライブに対して実行します。実際の現場では、すべてのドライブに対してデフラグ処理を行う場合も多いため、その場合は /A オプションを付加します。

例) 物理サーバーのハード ディスク ドライブ “C ドライブ” に対して従来のデフラグ処理を行う

>Defrag /D C:　(もしくは ＞Defrag C: )

例) 物理サーバーの全てのドライブに対して従来のデフラグ処理を行う

>Defrag /C /D

2. シン プロビジョニング対応ドライブに対してスラブ統合を行いたい場合

スラブ統合を行いたい場合は、/K のオプションを付加します。

例) 仮想サーバーのシン プロビジョニング対応ドライブ “C ドライブ” に対してスラブ統合を行う

>Defrag /K C:

なお、スラブ統合は、シン プロビジョニング対応ディスクに対してのみ行われますので、物理ディスクや容量固定の仮想ディスクの場合は実行されません。

■ Windows Server 2012 以降でのデフラグ処理について

.
Windows Server 2012 以降では、メンテナンス タスクの一環として、スラブ統合の処理がタスク スケジューラに規定で組み込まれています。

タスクは、[タスク スケジューラ] -> [タスク スケジューラ ライブラリ] -> [Microsoft] -> [Windows] -> [Defrag] に “SchduledDefrag” として存在していることを確認できます。

[トリガー] タブは空欄となっておりますが、内部ロジックにより、週 1 回の頻度でタスクが実行されております。[操作] タブでは、defrag コマンドのオプションが登録されています。/K のオプションが付加されていますので、従来のデフラグ処理ではなく、スラブ統合が実行されています。従って、既定の “SchduledDefrag” のタスクでは、一般的なローカル ディスクであるハード ディスク ドライブに対して最適化は行われていません。ハード ディスク ドライブに対して、従来のデフラグ処理による最適化を定期的に行いたい場合は、既定のタスクではなく、新規のタスクを作成して実行する必要があります。

■ “ドライブのデフラグと最適化” ツールについて

.
タスク スケジューラからではなく、[管理ツール] 内の [ドライブのデフラグと最適化] ツールからも各ドライブの最適化の状況や、前回の実行日などを確認することが可能です。
[スケジュールされた最適化] の項目では、タスク スケジューラと連動した、既定の “SchduledDefrag” タスクの実行/停止の設定や頻度の変更ができます。このツールで最適化を “オフ” にすると、タスク スケジューラ側でも、タスクが無効化されます。

■ よくあるお問い合わせ “ソース：Defrag、ID：257 のエラーのイベント ログについて”

.
Windows Server 2012 以降では、スラブ統合が既定でスケジュールされていますが、スラブ統合はスラブのサイズが 8 MB 以下の場合には実行されません。
スラブ サイズが十分に小さい (8 MB 以下) 場合、使用率の低いスラブが発生しにくいため、スラブ統合を実施せずともストレージを効率よく利用できていると判断します。
システムへの影響は全くないため、本エラーのイベント ログは無視していただいて構いません。

公開情報)
“Windows Server 2012 以降の OS でイベント ログに、エラー Microsoft-Windows-Defrag ID:257 (0x8900002D) が記録される”

上記の公開情報では、defrag コマンドのオプションをスラブ統合からトリム処理のみへ変更することでエラーを回避する方法をご紹介しております。
これ以外にも、タスク スケジューラの “SchduledDefrag” タスクそのものを無効化することでも回避できます。

■ スラブ サイズの確認方法と変更方法について

.
以下の Windows PowerShell のコマンドでスラブ サイズを確認することができます。

PS>Optimize-Volume -DriveLetter X -SlabConsolidate -WhatIf -Verbose
※X は対象ボリュームのドライブレター

公開情報)
“Optimize-Volume”
https://technet.microsoft.com/ja-jp/library/hh848675(v=wps.630).aspx

なお、スラブ サイズはストレージによって決まっておりますので、OS 側から変更することは出来ません。また、スラブ サイズを OS 側から確認する上記の PowerShell コマンドについても、ストレージによってはスラブ サイズが表示されない場合もあります。ご了承ください。

今回はデフラグ処理とスラブ統合の動作について、ご紹介させていただきましたが、いかがでしたでしょうか。
本ブログが少しでも皆様のお役に立てますと幸いです。

2018 年 1 月の更新プログラムを適用すると、CoInitializeSecurity の呼び出しが失敗する事象を確認しております。現在、マイクロソフトは、本事象の対策版のリリースに向け全力を尽くしております。

本ブログは、ユーザー様への影響度を鑑みまして、本件の対策状況などについて、タイムリーに情報を発信することを目的としています。
そのため、掲載内容は、随時更新いたしますことご理解をいただけますようお願いいたします。

概要

2018 年 1 月の更新プログラムには以下の通り既知の問題が含まれており、その影響により、CoInitializeSecurity の呼び出しが失敗し、一部アプリケーション等が起動できない等の報告を確認しております。

原因

CoInitializeSecurity を呼び出すときに、認証レベルとして RPC_C_AUTHN_LEVEL_NONE を渡すと呼び出しが失敗することがあります。
失敗時に返されるエラーは STATUS_BAD_IMPERSONATION_LEVEL です。

回避策

本問題につきましては、次段 “影響を受ける更新プログラム一覧” に記載させていただきます更新プログラムを、一時的にアンインストールいただくことで回避することが出来ます。
現時点において、更新プログラムのアンインストール以外に、事象を回避する方法はございません。

尚、更新プログラムのアンインストール後、Windows Update の自動更新により、更新プログラムが適用される場合があります。
このような状況を回避する場合には、自動更新を無効する必要がございます。
以下ブログにおいて Windows Update の自動更新を無効にする方法をご案内させていただいております。
Professional 以降のエディションであれば、Windows 10 / Windows Server 2016 以外の Windows Version でも同様の手順にて Windows Update の自動更新を無効にすることができます。

Windows 10 / Windows Server 2016 でも Windows Update の自動更新は止められます
https://blogs.technet.microsoft.com/jpwsus/2017/09/08/wecanstop-wu/

影響を受ける更新プログラム一覧

2018 年 1 月 4 日 KB4056892 (OS ビルド 16299.192)
適用対象: Windows 10 version 1709 (※)
https://support.microsoft.com/ja-jp/help/4056892/

2018 年 1 月 4 日 KB4056891 (OS ビルド 15063.850)
適用対象: Windows 10 Version 1703 (※)
https://support.microsoft.com/ja-jp/help/4056891/

2018 年 1 月 4 日 KB4056890 (OS ビルド 14393.2007)
適用対象: Windows 10 Version 1607, Windows Server 2016, Windows 10 Mobile, released in August 2016 (※)
https://support.microsoft.com/ja-jp/help/4056890/

2018 年 1 月 4 日 KB4056888 (OS ビルド 10586.1356)
適用対象: Windows 10 Version 1511 (※)
https://support.microsoft.com/ja-jp/help/4056888/

2018 年 1 月 4 日 KB4056893 (OS ビルド 10240.17738)
適用対象: Windows 10 Enterprise released in July 2015 (※)
https://support.microsoft.com/ja-jp/help/4056893/

January 8, 2018 KB4056895 (Monthly Rollup)
適用対象: Windows 8.1, Windows Server 2012 R2 Standard
https://support.microsoft.com/ja-jp/help/4056895/

2018 年 1 月 4 日 KB4056898 (セキュリティのみの更新プログラム)
適用対象: Windows 8.1, Windows Server 2012 R2 Standard
https://support.microsoft.com/ja-jp/help/4056898/

2018 年 1 月 5 日 KB4056896 (マンスリー ロールアップ)
適用対象: Windows Server 2012 Standard
https://support.microsoft.com/ja-jp/help/4056896/

2018 年 1 月 4 日 KB4056899 (セキュリティのみの更新プログラム)
適用対象: Windows Server 2012 Standard
https://support.microsoft.com/ja-jp/help/4056899/

(※) ご利用の Windows 10 のバージョン情報を確認する方法に関しましては、以下 URL に手順をご紹介しております。ご参考いただけますと幸いです。

Windows のバージョン確認方法
https://blogs.technet.microsoft.com/askcorejp/build-check/

こんにちは。Windows プラットフォーム サポートです。

本稿では、WSFC 環境の NFS サーバーで特定の条件下においてフェールオーバーした場合、STOP エラー 0x9e が発生する現象について確認しております。

[現象]
Windows (Storage) Server 2012/Windows (Storage) Server 2012 R2/Windows (Storage) Server 2016 の Windows Server フェールオーバー クラスタリング (WSFC) 環境で、NFS サーバーに対して、40 台以上の NFS クライアントからロックを保持し、正しくロックを解放しないまま疎通が取れなくなった状態で、NFS サーバーのフェイルオーバーを連続して 2 回実施した場合、STOP エラー 0x9e (USER_MODE_HEALTH_MONITOR) が発生する可能性があります。

[原因]
この現象は以下のシナリオで発生します。

1. NFS クライアントからクラスター ノード A 上の NFS サーバーにアクセスし、ファイルをロックします。
その後ファイルのロックを解放しないままネットワークから切断します。このような端末が 40 台存在すると想定します。
2. ノード A からノード B に NFS サーバーをフェイルオーバーします。
3. ノード B で NFS サーバーが起動後、ロックを保持する各 NFS クライアントに UDP 111 番ポートでの通信を試みます。
4. さらにノード B で NFS サーバーを別のノードにフェイルオーバーします。

上記の項番 3 でファイルのロックを解放しなかったクライアントに通信を試行してレスポンスを待機する間、項番 4 で NFS サーバーをオフラインにしようとする処理が項番 3 の完了待ちとなります。
この完了待ちにて 20 分以上時間を要した場合、クラスターの Health Monitoring のタイムアウト (20 分間) により STOP エラー 0x9e (USER_MODE_HEALTH_MONITOR) が発生します。
これは、ロックを未解放のクライアントに対して一台当たり最大 30 秒待機するため、NFS サーバーから疎通できないクライアントが約 40 台存在すると 20 分処理以上の時間を要するために発生します。

[回避策]
フェールオーバーの実施前に NFS サーバーで保持されているロックを強制的に解放することで回避できます。

– 現在オープン中のロックを確認するコマンド

Get-NfsClientLock

– 全てのロックを解放するコマンド

Revoke-NfsClientLock -Path *

– 影響について

上記回避策を実施した場合、NFS サーバー側ではロックが強制的に解放され、クライアントで側はロックを保持していると認識された状態となります。
この場合、別のクライアントが同一のファイルに対するロックを要求した際には、別のクライアントがロックを保持することができます。
また、最初にロックを保持していたクライアントから、そのファイルへのアクセスを行った場合に、クライアントアプリケーションによってはエラーが発生する等の影響が考えられます。
既にオフラインになっているクライアントについては、ロックの強制解放を行っても影響はありません。

[状況]
現在、調査中です。

本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。

こんにちは。Windows プラットフォーム サポートです。

現在、CPU の脆弱性（Meltdown/Spectre）に関連したお問い合わせを、多くいただいております。

弊社にいただいております良くあるお問い合わせや、公開情報についてまとめさせていただきました。本ページは今後も随時更新される予定です。

なお、本件につきましては以下の弊社公開情報も合わせてご確認ください。

（脆弱性全般の情報)

• ADV180002 Guidance to mitigate speculative execution side-channel vulnerabilities

（クライアント向け、サーバー向け適用ガイド）

• Windows Client Guidance for IT Pros to protect against speculative execution side-channel vulnerabilities
• Windows Server guidance to protect against speculative execution side-channel vulnerabilities
  

（ウイルス対策ソフトとの互換性について）

• Important Windows security updates released January 3, 2018, and antivirus software

（パフォーマンスへの影響について）

• Understanding the performance impact of Spectre and Meltdown mitigations on Windows Systems

（一部の AMD デバイスでの問題について）

• Windows operating system security update block for some AMD based devices

（Hyper-V 環境での対応手順について）

• Protecting guest virtual machines from CVE-2017-5715 (branch target injection)

FAQ 

[更新プログラムの検出について]

Q. ウイルス対策ソフトとの互換性を確認する QualityCompat のレジストリキーの用途は？

A. アンチウィルス アプリケーションが Windows のカーネルメモリに対してサポートされていない呼び出しを行う場合に発生する互換性の問題があり、この呼び出しの結果として、STOP エラー (ブルースクリーンとも呼ばれる) が発生し、デバイスが起動できない場合がございます。

このような互換性のないアンチウィルスアプリケーションによる問題を防ぐために、弊社では、2018 年 1 月 3 日にリリースいたしましたセキュリティ更新プログラムにつきましては、以下のレジストリを更新プログラムの検出条件としており、本レジストリの設定がない場合、Windows Update 及び WSUS による更新では当該の更新プログラムが検出されない仕組みとなっております。

キー：HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\QualityCompat

名前：cadca5fe-87d3-4b96-b7fb-a231484277cc

種類：REG_DWORD

値： 0x00000000

なお、本設定自体は CPU の脆弱性の問題に対する緩和策を含んでいる、今月の更新プログラムを Windows Update 及び WSUS にて検出するための設定であり、この設定自体が CPU の脆弱性の問題と直接の関係はありません。

Q. 更新プログラムを手動で適用しますが、QualityCompat を設定する必要はありますか？

A. Microsoft Update カタログからダウンロードした msuファイルを直接実行する場合、本レジストリの設定に関わらず、更新プログラムが適用されます。更新プログラムの適用前にウイルス対策アプリケーションが互換性を保持しているか、事前にお使いのウイルス対策プロバイダーに問い合わせの上、実施ください。

[更新プログラムの適用について]

Q. パッチ適用の前提条件はありますか。

A. 今回の更新プログラム固有の条件ではありませんが、一部の OS バージョンでは更新プログラム適用の前提が必要になります。

Windows 7 及び Windows Server 2008 R2では Service Pack 1 が適用されている必要があります。

Windows 8.1、Windows Server 2012 R2 及び Windows Storage Server 2012 R2 では KB2919355 が必要となります。

KB2919355 の適用にはさらに、KB2919442が前提となりますので、未適用の場合には、KB2919442を先にインストールください。

Windows 10 及び Windows Server 2016 には前提条件はございません。

Q. Windows Server 2008 と Windows Server 2012 ではどんな対策を取ることができますか？

A. 1/10 11:00 時点では、Windows Server 2008 及びWindows Server 2012 のセキュリティパッチは引き続きリリースを検討中でございます。

以下、公開情報からの引用となりますが、リリースに関する情報のアップデートがあり次第ご連絡いたします。

Windows Server を投機的実行のサイドチャネルの脆弱性から保護するためのガイダンス

https://support.microsoft.com/ja-jp/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution

—– 抜粋 —–

Q3: Windows Server 2008 および Windows Server 2012 プラットフォームで更新プログラムを入手できないのはなぜですか。 修正プログラムはいつ入手できる予定ですか。

A3: ソフトウェアの更新プログラムでハードウェアの脆弱性に対処することは非常に困難であり、古いオペレーティング システムに緩和策を提供するには大幅なアーキテクチャの変更が必要です。 マイクロソフトは影響を受けるチップの製造元との協力を継続し、緩和策を提供する最善の方法を調査しています。 

—– 抜粋 —–

[緩和策の有効化について]

Q. CPU の脆弱性の対策には、Windows の更新プログラム適用のほかに対策は必要ありますか？

A. 今回の脆弱性は CPU の脆弱性であり、利用できるすべての保護を受けるためには、OEM デバイスの製造元からリリースされた該当するプロセッサ マイクロコードまたはファームウェアの更新プログラムも適用する必要があります。

（詳細については、デバイスの製造元にご照会ください。）

Q. クライアント OS については、パッチ適用のみで Windows 上の緩和策が有効化されますか？

A. はい、パッチ適用のみで緩和策が有効化されます。

Q. サーバ OS については、パッチ適用のみで緩和策が有効化されますか？

A. いいえ、FeatureSettingsOverride および FeatureSettingsOverrideMask のレジストリを有効化しない限り、緩和策が有効化されません。更新プログラム適用と合わせてレジストリ設定を実施ください。

Q. 更新プログラムを適用せずに、FeatureSettingsOverrideとFeatureSettingsOverrideMaskのレジストリの変更だけ実施する必要はありますか？

A. 更新プログラムを適用しない場合上記レジストリの設定を実施いただく必要はございません。

Q. 更新プログラムの適用とレジストリ（FeatureSettingsOverrideとFeatureSettingsOverrideMask）の変更の順番はどっちが先でも問題ないですか？

A. はい、どちらが先でも問題ありません。ただし、FeatureSettingsOverride と FeatureSettingsOverrideMask の設定反映には再起動が必要となります。緩和策を有効化する際に 1 度の再起動としたい場合は、更新プログラム適用後の再起動とレジストリ設定後の再起動のタイミングを合わせてください。

Q. HyperVのホストとゲストへはどのように対応したらよいですか？

A. Hyper-V 環境への対応策については、以下をご確認ください。

– 公開技術情報

Protecting guest virtual machines from CVE-2017-5715 (branch target injection)

https://docs.microsoft.com/ja-jp/virtualization/hyper-v-on-windows/CVE-2017-5715-and-hyper-v-vms

[システムへの影響について]

Q. 更新を適用後、パフォーマンスは低下しますか？

A. ご利用の環境によりましては、パフォーマンスの低下が発生する可能性があります。具体的な影響内容はハードウェアの世代やチップ製造元の実装方法により異なりますため、実際の環境で発生するパフォーマンスの影響を評価し、必要に応じて調整いただくことを推奨いたします。

こんにちは。Windows プラットフォーム サポートです。

KB4056895 適用の Hyper-V ホストから KB4056895 未適用の Hyper-V ホストに対して仮想マシンのライブマイグレーションを実行するとイベントログに Hyper-V-VMMS ID:24004 が記録され、失敗する場合があります。

—————————————
ログの名前: Microsoft-Windows-Hyper-V-VMMS/Admin
ソース: Hyper-V-VMMS
日付: XXXX/XX/XX XX:XX:XX
イベント ID: 24004
タスクのカテゴリ: なし
レベル: エラー
キーワード: N/A
ユーザー: SYSTEM
コンピューター: XXXXXXXX
説明:
仮想マシン ‘XXXX’ は、物理コンピューター ‘XXXX’ でサポートされていないプロセッサー固有の機能を使用しています。
異なるプロセッサーを持つ物理コンピューターにこの仮想マシンを移行できるようにするには、仮想マシン設定を変更して、
仮想マシンで使用されるプロセッサー機能を制限します。(仮想マシン ID XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX)
—————————————

※ 未適用の Hyper-V ホストから適用した Hyper-V ホストへのライブマイグレーションは成功します。

Hyper-V の役割をインストール行うと、CPU の機能はハイパーバイザーでサポートしている機能のみ有効となり動作いたします。
KB4056895 ではこのハイパーバイザーでサポートする CPU 機能が追加されており、その結果適用 Hyper-V 環境と未適用の Hyper-V 環境で使用する CPU 機能に差が生じることがあります。

CPU の機能レベルに差が生じた場合、プロセッサの新しい命令セットに対応できず、ライブマイグレーションに失敗する場合があります。

クラスター環境では、全クラスター ノードでソフトウェア更新プログラム含めて同一構成であることを推奨しております。
そのため、KB4056895 未適用の環境に KB4056895 を適用いただくことで本事象は対処お願いします。

KB4056895 を直ぐに適用可能な環境ではない場合には、仮想マシンの設定で、プロセッサーの互換性を有効化することでも対処可能です。

以下、設定方法となります。

1. フェールオーバー クラスター マネージャーを起動します。

2. 左ペインの [役割] を選択し、中央ペインの仮想マシンリソースを右クリックし [設定] を選択します。

3. [プロセッサ] の [互換性] を選択し、[プロセッサ バージョンの異なる物理コンピューターへ移行する] を選択します。

本 Blog が少しでも皆様のお役に立てれば幸いです。

いつも弊社製品をご利用いただきまして誠にありがとうございます。
Windows プラットフォーム サポートの石田です。

ボリューム シャドウコピー機能を (VSS) をご利用いただいている環境にて Stop エラーが発生した際の対応についてご案内させていただきます。

事象:
ボリューム シャドウコピー機能を利用しているシステムでは volsnap.sys ドライバーの問題でブルースクリーンが発生し以下の Stop エラーメッセージが記録されることがございます。

STOP 0x000000d1 (0xfffff80050130b70, 0x0000000000000002, 0x0000000000000008, 0xfffff80050130b70)

第１引数、第４引数の値は環境によって異なります。

原因:
volsnap.sys ドライバーの実装の不具合により、設計上本来ページアウトされないことが前提である本ドライバ内の関数のコード領域が、実際にはページアウトされてしまうことが原因となります。

本不具合につきましては、2018年1月19日時点では、”対象OS”のいずれにおきましても修正モジュールは作成されておりません。

なお、全てのSTOP 0xD1エラーの原因が、本不具合によるものとは限りません。本不具合と関係しない問題に起因して、STOP 0xD1 が発生する可能性も考えられます。

回避策:
DisablePagingExecutive レジストリー値を設定しカーネルモジュールがページアウトされないようにします。

1. コマンドプロンプトを管理者モードで起動します。
2. 以下のコマンドを実行します。
   reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v DisablePagingExecutive /t REG_DWORD /d 0x1
   ※すべて 1 行で実行します。
3. システムを再起動します。

回避策の実施後はドライバのコード部分がメモリからページアウトされなくなりますので、実施前と比較して、利用可能メモリが減る可能性がございます。

対象 OS:
Windows Server 2008 R2 / Windows Storage Server 2008 R2
Windows Server 2012 / Window Storage Server 2012
Windows Server 2012 R2 / Windows Storage Server 2012 R2
Windows Server 2016 / Window Storage Server 2016
Windows Server 1709

参考:
DisablePagingExecutive
https://technet.microsoft.com/en-us/library/cc959492.aspx

本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。

こんにちは。 Windows サポートの水上です。
今回は、よくあるお問い合わせのひとつである、デスクトップ ヒープの枯渇について、ご紹介します。

サーバーやデスクトップ PC を運用するにあたって、次のような事象が発生したことはないでしょうか。

• 他のアプリケーションは正常に動いているのに、アプリケーションの起動やバッチ処理に失敗する。
• イベント ID 243 や 244 が記録される。
• 例外コード 0xc0000142 でイベント ID 1000 が記録される。

上記のような事象は、デスクトップ ヒープの枯渇により生じている可能性があります。
デスクトップ ヒープの上限サイズはレジストリで変更が可能なため、設定変更により事象を解消できる可能性があります。

ただ、 “デスクトップ ヒープの枯渇” という現象が具体的にどういうものなのか疑問に思われる方も多いのが実情です。
実際に、マイクロソフトにいただくお問い合わせの中でも、デスクトップ ヒープの枯渇とはいったい何なのか詳しく説明してほしいとのご意見をよく頂戴します。
そこで、今回は、デスクトップ ヒープが何なのかについてもご説明したうえで、デスクトップ ヒープ枯渇の回避方法についてご紹介します。

もくじ

1. デスクトップ ヒープとは何か
2. デスクトップ ヒープのサイズ上限とデスクトップ ヒープの枯渇
3. デスクトップ ヒープ枯渇の回避 – デスクトップ ヒープのサイズ上限の拡張
4. デスクトップ ヒープ枯渇の原因調査
5. おわりに

デスクトップ ヒープとは何か

デスクトップ ヒープとは、 Windows 上で作成されるデスクトップに紐づけられる、ウィンドウやメニューなどの情報を格納する領域です。

デスクトップ ヒープの根底には、セッション、ウィンドウ ステーション、デスクトップの 3 つの概念があります。
あるユーザーがログオンすると、 Windows の内部ではユーザーのためにセッションが新たに作られます。
(例外として、サービスやタスクの起動のような非対話型の認証が生じた際には、新たなセッションは作られず、共用のセッション Session 0 が使用されます。)
セッションの内部にはウィンドウ ステーションが作成され、ウィンドウ ステーションのさらに内部にデスクトップが作成されます。
デスクトップ上には、実際にユーザーに見えるウィンドウやテキスト ボックスのようなオブジェクト (ユーザー オブジェクト) が作成されますが、このユーザー オブジェクトの情報を保持するのに使用されるのが、デスクトップ ヒープです。

+++ 参考 +++
セッション・ウィンドウ ステーション・デスクトップの概念については、下記ページでも詳細に触れられています。

“USER オブジェクトと GDI オブジェクト – 第 1 部”
https://technet.microsoft.com/ja-jp/windows/mark_16.aspx
++++++++++

デスクトップ ヒープの新規割り当てができなくなると、ウィンドウなどの GUI に必要なデータ構造を作成することができなくなり、アプリケーションの起動失敗などが発生します。

余談とはなりますが、上述のとおり Windows ではユーザーごとにセッションが作成され、セッション稼働中ウィンドウ ステーションは配下のデスクトップを切り替えながら画面に出力しています。
この仕組みには、次のようなメリットがあります。

• 同一デスクトップ内の GUI の管理に際し、デスクトップ ヒープを介したデータやコードの共有が容易かつ安全にできる。
• セッション・デスクトップごとのメモリの境界が明確であり、異なるセッション・デスクトップの影響を受けにくい。
  特に、ログオン画面や UAC のプロンプト画面は専用のデスクトップを使用しているので、通常のデスクトップの影響を受けにくく、セキュリティ上の脅威を緩和できる。

デスクトップ ヒープのサイズ上限とデスクトップ ヒープの枯渇

Windows Server 2008 以降 (Windows Server 2008 R2, Windows Server 2012R2 や Windows Server 2016) では、対話型・非対話型のデスクトップ ヒープのサイズ上限が、既定値が以下のように設定されています。

    対話型: 20480 KB
    非対話型: 786 KB

なお、対話型デスクトップとは、通常一般ユーザーが使用するデスクトップで、物理的な画面やキーボードを通じてユーザーとのやり取りが可能なデスクトップです。
一方で、非対話型デスクトップは、サービスやログオン状態にかかわらず実行するように設定されているタスクなど、ヘッドレスの状態で動作するプロセスが使用するデスクトップとして用意されます。

ここで重要なことは、非対話型デスクトップのヒープ サイズ上限は、対話型よりも小さく設定されており、対話型のデスクトップ ヒープよりも枯渇しやすいということです。
本来非対話型のセッションでは GUI を必要としないため、非対話型デスクトップのサイズ上限を厳しくすることは合理的な設計と言えますが、
アプリケーションの挙動次第では、内部的に作成される GUI オブジェクトによりデスクトップ ヒープが消費されてしまうため、結果としてデスクトップ ヒープが枯渇しやすくなってしまうのです。
現に、マイクロソフトのサポートには年間数十件ほどのペースでデスクトップ ヒープの枯渇に関するお問い合わせを頂戴しますが、そのほとんどで非対話型デスクトップ ヒープの枯渇が問題となっています。

デスクトップ ヒープが枯渇すると、新たなユーザー オブジェクトを作成することができなくなるため、ウィンドウなどの GUI の維持に必要なデータが配置できず、結果としてアプリケーションの起動失敗や、サービスによりバックグラウンドで実行されるバッチ処理の実行失敗につながります。

殊によくあるのが、大量のバッチ処理をサービスとして並行実行することで、デスクトップ ヒープが枯渇し、バッチ処理の実行が途中で失敗してしまうというケースです。
cmd.exe と cmd.exe に付随して起動される conhost.exe は、非対話型デスクトップ上でもそれぞれウィンドウやメニュー バー、キャレットを持つため、デスクトップ ヒープを若干 (一般的には数 KB) 消費します。
そのため、非対話型のセッションで多数のバッチ処理を並行して実行すると、小さな消費の積み重ねでデスクトップ ヒープを消費しきってしまい、結果としてデスクトップ ヒープが枯渇した状態になります。

+++ 検証 +++

バッチ処理の並行実行による非対話型のデスクトップ ヒープの枯渇は、下記のように無限ループするバッチ ファイルを使用して簡単に再現することができます。

重要: 下記は事象の理解の補助のために紹介するものであり、一般ユーザーによる実施を意図したものではありません。
本手順を実際に実行したことによるシステム・データへの損害につきましては、責任を負いかねます。

1. 下記一行が書かれたバッチ ファイル cmd-loop.bat をデスクトップ上に作成します。

   start cmd.exe /K %USERPROFILE%\Desktop\cmd-loop.bat

2. タスク スケジューラーにて、 cmd.exe を引数 "/K %USERPROFILE%\Desktop\cmd-loop.bat" で実行するタスクを作成します。
   タスク作成の際には、 [全般] タブの [セキュリティ オプション] の項目で [ユーザーがログオンしているかどうかにかかわらず実行する] が選択されていることを確認します。
3. 作成したタスクを手動で実行します。

手元の検証環境で実際に検証したところ、下記事象が確認できました。

1. タスク マネージャー上で大量の conhost.exe がセッション ID 0 で稼働しているのが見える (実際には 111 個稼働している)。

2. システムのイベント ログにイベント ID 243 が記録される。

3. 事象発生時のダンプを解析すると、 Session 0 (非対話領域) のとあるデスクトップのヒープが枯渇状態となっている。

   ****************
> !dskheap -s 0
Winstation\Desktop Heap Size(KB) Used Rate(%)
------------------------------------------------------------
WinSta0\Default 20480 0% // 各セッションにかならず作られる対話型デスクトップ。 Session 0 は非対話型ユーザー セッションなので、原則として使用されない。
WinSta0\Disconnect 96 4%
WinSta0\Winlogon 192 2% // ログオン画面で使用するデスクトップ。
Service-0x0-3e7$\Default 768 2% // サービスとして利用されるデスクトップ。サービスの実行ユーザーごとにデスクトップが異なる。
Service-0x0-3e5$\Default 768 0%
Service-0x0-3e4$\Default 768 0%
Service-0x0-53f57$\Default 768 99% // タスクが実行されているデスクトップ。非対話型。ヒープの使用率が 99 % と枯渇状態。枯渇がどのウィンドウ ステーション・デスクトップで発生するかは、システムの稼働状況に依存。
****************

デスクトップ ヒープ枯渇の回避 – デスクトップ ヒープのサイズ上限の拡張

デスクトップ ヒープ枯渇の回避方法としては、次の 2 通りが考えられます。

1. デスクトップ ヒープの枯渇を引き起こしているアプリケーションの改修
2. デスクトップ ヒープのサイズ上限の拡張

デスクトップ ヒープのサイズ上限を拡張する方が工数も圧倒的に少なく行えるため、お問い合わせいただいたケースのほとんどでは、サイズ上限の拡張により事象を回避しています。
中には、デスクトップ ヒープの枯渇が発生することを見越して、サーバー構築時の一手順としてデスクトップ ヒープのサイズ上限を拡張しておくお客様もいらっしゃいます。

デスクトップ ヒープのサイズ上限は、下記のレジストリ項目で変更することができます。

場所：HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SubSystems
名前：Windows
種類：REG_EXPAND_SZ
データ： SharedSection=XXX,YYY,ZZZ の部分

SharedSection の 1 番目の値 (XXX): 全てのデスクトップに共有されている標準ヒープ
SharedSection の 2 番目の値 (YYY): インタラクティブ (対話型) デスクトップ ヒープの値
SharedSection の 3 番目の値 (ZZZ): ノン インタラクティブ (非対話型) デスクトップ ヒープの値

上記 SharedSection の 2 番目や 3 番目の値を大きくすることで、デスクトップ ヒープのサイズを大きくすることができます。

当該箇所は、長いレジストリ値の一部に含まれていますので、レジストリ エディターで確認する際には、手動でカーソルを動かして表示させる必要があります。
また、 SharedSection に誤った値 (たとえば数字以外の文字列) を指定すると、システムが正常に起動しなくなるので、注意してください。

デスクトップ ヒープ拡張の際には、一般的に、既定値の 2 倍から 3 倍を目安に、徐々に大きくすることをおすすめしています。
値を大きくすることですぐに何か問題が生じるようなことはありませんが、上述したように、上限が緩和され、デスクトップ ヒープが肥大化するようになると、かえってパフォーマンスの低下 (デスクトップ ヒープの使用による空きメモリの逼迫や並行するプロセスの増加による処理遅延) を引き起こす可能性があります。
そのため、事象の解消とパフォーマンスへの新たな影響を見ながら、段階的にデスクトップ ヒープのサイズを拡大するようお願いしています。

デスクトップ ヒープ枯渇の原因調査

デスクトップ ヒープの消費状況や枯渇の原因の調査の際には、まず完全メモリ ダンプの採取が可能であるかどうかをご確認いただければと思います。

Windows Server 2003 や Windows XP の時代には、 Desktop Heap Monitor と呼ばれるツールが一般公開されており、デスクトップ ヒープの状況を簡単に調査することが可能でした。
一方で、 Windows Server 2008 / Windows Vista 以降では、古いツールが使用できなくなっています。

Windows Server 2008 / Windows Server 2008 R2 の場合は、デバッガーや LiveKD を使用してお客様環境でも調査がある程度できましたが、
Windows Server 2012 以降の場合は、完全メモリ ダンプをご採取いただき、デスクトップ ヒープの観点でのダンプの解析をマイクロソフトのサポートにご依頼いただく必要があります。

調査を迅速に進めるためにも、デスクトップ ヒープ関連の問題を調査したい場合は、こちらの記事を参考に完全メモリ ダンプを採取し、マイクロソフトのサポートまで解析をご依頼ください。

おわりに

デスクトップ ヒープの枯渇は、特にバックグラウンドでのバッチ処理を行うようなサーバー環境で起きやすく、デスクトップ ヒープ枯渇に関する調査は多くお問い合わせを頂戴するトピックにもなっています。
他方、デスクトップ ヒープ枯渇の原因調査にはダンプの採取が必要となる場合が多く、原因調査のハードルは高めであるといえます。

デスクトップ ヒープの拡張は、すぐにシステムの稼働に影響を与えるような作業ではありません。
マイクロソフトが把握している事例においても、デスクトップ ヒープを 2 倍から 3 倍程度増やしたことで他の問題が発生したとの報告はない状況です。
そこで、

• 他のアプリケーションは正常に動いているのに、アプリケーションの起動やバッチ処理に失敗する。
• イベント ID 243 や 244 が記録される。
• 例外コード 0xc0000142 でイベント ID 1000 が記録される。

このような事象が発生した際には、まずは上記でご紹介したレジストリ変更を実施し、事象が回避できるかどうかをお試しいただければと思います。
デスクトップ ヒープの拡張でも事象が解消しない場合には、お気軽にマイクロソフトのサポートにご相談いただければ、課題解決にむけ可能な限りご支援させていだきます。

アプリケーションの起動やバッチ処理に失敗する問題について、詳細な調査をご希望の場合は、まずは完全メモリ ダンプのような再起動を伴う情報採取が可能かどうかをご確認いただいたうえで、マイクロソフトのサポートにお問い合わせいただけますと幸いです。

こんにちは。Windows プラットフォーム サポートです。
Windows Server 2016 Hyper-V クラスター環境でクラスターの検証を実行した際に、Hyper-V 統合サービスのバージョン検証で以下の警告が発生することがあります。

—————————————–

Hyper-V 統合サービスのバージョンの検証

結果 : 警告
警告 : 次の仮想マシンはホスト コンピューターと一致しない統合サービスを実行しています。この仮想マシンまたはホスト コンピューターの統合サービスを更新して、同じバージョンにする必要があります。

—————————————–

[原因]
Windows Server 2012 R2 Hyper-V 以前の環境は、ゲスト OS の統合サービスとホスト OS の統合サービスのバージョンと一致させることを推奨しております。
(ホスト OS の統合サービスバージョンが更新された場合に、ゲスト OS の統合サービスバージョンを更新させることを推奨しております)

そのため、Hyper-V クラスター環境では、クラスターの “クラスターの検証” にて仮想マシンの統合サービスのバージョンを検証しており、
ホスト OS とゲスト OS の統合サービスのバージョンが一致しているかを確認しております。

しかしながら、Windows Server 2016 Hyper-V 環境では、Windows Server 2012 R2 Hyper-V 以前の環境とは異なり、ゲスト OS の統合サービスはホスト OS の統合サービスのバージョンとの一致させる必要はなくWindows Update により最新を適用することを推奨しております。
(ホスト OS 側の統合サービスのバージョンは廃止され、統合サービスのバージョンは “0.0” となります)

そのため、”クラスターの検証” で行う仮想マシンの統合サービスのバージョン確認を行うと、Windows Server 2016 Hyper-V では
ホスト OS の統合サービスのバージョンが 0.0 のため、常にゲスト OS の統合サービスのバージョンと不一致となり、上記の警告が出力されます。

[対処について]
クラスターの検証で上記の警告が発生しても、クラスターの操作や動作等に影響を与えないことから無視してください。

本 Blog が少しでも皆様のお役に立てれば幸いです。

皆さん、こんにちは。Windows プラットフォーム サポートの吉田です。

robocopy コマンドでファイル コピーを実行した際、LOG オプションで出力されるログに戻り値が記録されますが、今回は戻り値の結果の詳細についてご紹介します。

まず、robocopy コマンドでは以下のベースとなる戻り値があります。

戻り値 0: コピーする必要がないため、何も実施しなかった
戻り値 1: ファイルのコピーが成功した (フォルダーのコピーは含まれません)
戻り値 2: 余分なフォルダー、ファイルが確認された (コピー元にはなく、コピー先だけにある)
戻り値 4: 同じ名前で別の種類のファイルが存在した (コピー元はフォルダーで、コピー先はファイル、またはその逆)
戻り値 8: コピーに失敗した (リトライした結果を含みます、また /L では実際にコピー処理を行わないため、実質 8 以上の戻り値は出力されません)

このそれぞれの戻り値は LOG オプションでカウントされる場所は以下となります。

0 と判定されたファイル、フォルダーはログ中の “スキップ” にカウントされます。
1 と判定されたファイル、フォルダーはログ中の “コピー済み” にカウントされます。
2 と判定されたファイル、フォルダーはログ中の “Extras” にカウントされます。
4 と判定されたファイル、フォルダーはログ中の “不一致” にカウントされます。
8 と判定されたファイル、フォルダーはログ中の “失敗” にカウントされます。

しかし、robocopy の Log ファイルをご覧いただいた事のある方であれば、戻り値が 9 以上となっている結果をご覧いただいたことがあるかもしれません。
これは、複数のファイル、フォルダーをコピーされる場合に別々の結果となった場合に、足し算された値が返されるためです。

例えば、戻り値が [1] の場合には、robocopy によって処理されたファイルが、すべて正常に “コピー済み” と判断された場合です。
戻り値が [3] の場合、robocopy によって処理されたファイルの中に、戻り値 1 である “コピー済み” と戻り値 2 である “Extras” と判断されたファイルが混在する場合に記録されます。
つまり、戻り値が [1] 以外となっている場合には、正常にコピーが完了しなかったファイルが存在していることを表します。

以下に、[1] 以外のそれぞれの戻り値の結果をご紹介いたしますので、ご参考願います。

戻り値 3: 一部のファイルのコピーに成功したが、一部、Extras と判定された。(1 + 2)
戻り値 5: 一部のファイルのコピーに成功したが、一部、不一致 と判定された。(1 + 4)
戻り値 6: ファイルのコピーに成功しておらず、Extras または 不一致 と判定された (2 + 4)
戻り値 7: 一部のファイルのコピーに成功したが、一部 Extras または 不一致 と判定された (1 + 2 + 4)
戻り値 9: 一部のファイルのコピーに成功したが、一部 失敗 と判定された (1 + 8)
戻り値 10: ファイルのコピーに成功しておらず、Extras または 失敗 と判定された (2 + 8)
戻り値 11: 一部のファイルのコピーに成功したが、一部 Extras または 失敗 と判定された (1 + 2 + 8)
戻り値 12: ファイルのコピーに成功しておらず、不一致 または 失敗 と判定された (4 + 8)
戻り値 13: 一部のファイルのコピーに成功したが、一部 不一致 または 失敗 と判定された (1 + 4 + 8)
戻り値 14: ファイルのコピーに成功しておらず、Extras、不一致 または 失敗 と判定された (2 + 4 + 8)
戻り値 15: 一部のファイルのコピーに成功したが、一部 Extras、不一致 または 失敗 と判定された (1 + 2 + 4 + 8)

戻り値 16: ヘルプを表示したときにセットされます。また、存在しないフォルダーなどを指定するなど、引数が不正な場合にも記録されます。

このように、戻り値での結果では、すべてのコピー対象についてどのような結果が判定されたかを全体で把握するのみとなりますため、詳細な結果は LOG オプションによる出力結果を確認する必要がございますのでご留意願います。

以下は参考となりますが、/LOG オプションによる出力結果例となります。

——————————————————————————-
ROBOCOPY     ::     Windows の堅牢性の高いファイル コピー
——————————————————————————-

  開始: Mon Jan 22 22:14:52 2018

   コピー元 : \\dc\share\
コピー先 : c:\dest\

    ファイル: temp*.txt

オプション: /TS /FP /BYTES /S /E /COPY:DAT /DCOPY:T /PURGE /NP /IT /MT:4 /R:6 /W:10 

——————————————————————————

                       2    \\dc\share\
新しいファイル                 0 2018/01/22 07:19:05    \\dc\share\temp01.txt
0%
2018/01/22 22:14:52 エラー 32 (0x00000020) ファイルをコピーしています \\dc\share\temp01.txt
プロセスはファイルにアクセスできません。別のプロセスが使用中です。

新しいファイル                 0 2018/01/22 07:19:12    \\dc\share\temp02.txt
100%  10 秒間待機しています…
新しいファイル                 0 2018/01/22 07:19:05    \\dc\share\temp01.txt 再試行しています…
2018/01/22 22:15:02 エラー 32 (0x00000020) ファイルをコピーしています \\dc\share\temp01.txt
プロセスはファイルにアクセスできません。別のプロセスが使用中です。

10 秒間待機しています… 再試行しています…
2018/01/22 22:15:12 エラー 32 (0x00000020) ファイルをコピーしています \\dc\share\temp01.txt
プロセスはファイルにアクセスできません。別のプロセスが使用中です。

10 秒間待機しています… 再試行しています…
2018/01/22 22:15:22 エラー 32 (0x00000020) ファイルをコピーしています \\dc\share\temp01.txt
プロセスはファイルにアクセスできません。別のプロセスが使用中です。

10 秒間待機しています… 再試行しています…
2018/01/22 22:15:33 エラー 32 (0x00000020) ファイルをコピーしています \\dc\share\temp01.txt
プロセスはファイルにアクセスできません。別のプロセスが使用中です。

10 秒間待機しています… 再試行しています…
2018/01/22 22:15:43 エラー 32 (0x00000020) ファイルをコピーしています \\dc\share\temp01.txt
プロセスはファイルにアクセスできません。別のプロセスが使用中です。

10 秒間待機しています… 再試行しています…
2018/01/22 22:15:53 エラー 32 (0x00000020) ファイルをコピーしています \\dc\share\temp01.txt
プロセスはファイルにアクセスできません。別のプロセスが使用中です。

エラー: 再試行が制限回数を超えました。

——————————————————————————

                  合計     コピー済み      スキップ       不一致        失敗    Extras
ディレクトリ:         1         0         1         0         0         0
ファイル:         2         1         0         0         1         0
バイト:         0         0         0         0         0         0
時刻:   0:01:00   0:00:00                       0:00:00   0:01:00

       終了: Mon Jan 22 22:15:53 2018