syghの新フラグメント置き場

プログラミングTipsやコード断片の保管場所です。お絵描きもときどき載せます。

Windowsセキュリティ認証とネットワークパスワード

Windows ソフトウェアTips

Windowsで共有フォルダーにアクセスする場合、セキュリティ認証のためのパスワード入力を求められることがあります*1。

しかし、PCを再起動／シャットダウンするなどして、ログオンセッションが終了すると、再度入力が必要になってしまいます。

コマンドプロンプトでセキュリティ認証を実行する場合、以下のようにnetコマンドを使うことができます。

net use \\<IPアドレスもしくはホスト名>\<共有名> /user:<ユーザー名> <パスワード>

再入力の手間を省く方法として、コマンドをバッチファイルに書き込んでおいて、バッチファイルをスタートアップに登録する手法もあるのですが、パスワードを平文でテキストファイルに書き込むのはセキュリティ上のリスクがありますね。

代わりに「資格情報マネージャー」(Credential Manager) を利用するとよさそうです。

www.mtecweb.com

Windows 10の場合もコントロールパネルからアクセスできます。

ちなみにTortoiseGitなどもWindowsのセキュリティ認証を使用しますが、あろうことか認証ダイアログで誤ったパスワードを入力してしまった場合でも、その誤ったパスワードが資格情報マネージャーに記録されてしまいます。以後、認証ダイアログが出ずに接続が延々と失敗し続けてしまう現象が発生します。誤ったパスワードを削除する場合、コントロールパネルの資格情報マネージャーから各情報セットを削除する必要があります。

*1:同一ユーザー名で同一パスワードの場合、パスワード入力なしに透過的にアクセスできます。

Visual C++コンポーネントの復旧

Visual Studio ソフトウェアTips

Visual Studio 2015 Update 3がインストールされているWindows 7 x64環境において、Python Tools for Visual Studioを2017年1月版に更新した後、Visual C++プロジェクトを含むソリューションファイルを開くと、

インストール コンポーネントがないため、プロジェクト 'XXX' を読み込めませんでした。修正するには、以下の選択をして Visual Studio セットアップを起動してください:
Install Visual C++ 2015 Tools for Windows Desktop

というエラーメッセージが出るようになりました。VC++プロジェクトは「利用不可」と表示されます。

しかし、Visual C++のプロジェクトテンプレート群はインストールされていて、Visual Studioのバージョン情報にもVisual C++コンポーネントは表示されます。どうやら、何らかのファイルが破損するなりして、VC++コンポーネントが正常に認識されていない模様。

[プログラムと機能]からVisual Studioのインストールウィザードを使って[修復]インストールしても改善しません。
[変更]インストールでコンポーネントのインストール状態をチェックしたところ、なぜか[プログラミング言語]→[Visual C++]配下のコンポーネントのチェックがすべて外れていました。

チェックを入れ直してインストールを実行すると、問題が解消されました。

一度「利用不可」状態になってしまったプロジェクトは、.suoファイルにアンロード状態が記録されてしまうようなので、コンテキストメニューから[プロジェクトの再読み込み]を実行して状態をリセットすればOK。

たぶんPython Toolsを更新したときに一部のVC++コンポーネントが勝手に削除されてしまったのだと思われます。ひどいバグですね。

Visual Studio 2015のコード整形機能のバグ

Visual Studio ソフトウェアTips

Visual Studioのコードエディターでは、C#コードを入力する際、ペースト時や閉じ中カッコ0x7Dあるいはセミコロン0x3Bを入力したタイミングなどで自動的にフォーマット（コード整形）が発動し、タブや空白などが自動調整されます。以前のバージョンのVisual Studioでは、C++コードでは明示的なフォーマット機能（ショートカット：Ctrl+K, Ctrl+F）のみをサポートしていましたが、Visual Studio 2015では、C++でもC#に近いオートフォーマットがデフォルトで発動するようになりました。
ただし、VS2015のソースコードエディターは、Update 3時点でもオートフォーマットのバグをいくつか抱えています。大半はVS2013時点では存在していなかったリグレッションです。VS2017は試していないので、不具合が修正されているかどうか、それとも依然として存在するかどうかは分かりません。なお、たとえMS Connectに不具合報告しても、VS2015では修正されず、どうせ新しいバージョンでしか修正されないことが分かり切っているので、報告するつもりはありません。また、せっかくユーザーが報告した不具合のチケットを、あろうことか勝手に削除することがあるようなので、MS Connectにはもう報告しないつもりです。傲岸不遜で恥知らずなMSにはもう協力したくありません。

フォーマット機能は、コーディング規約にそぐわないコードを整形するときは便利なのですが、意図しない形に勝手に自動整形されてしまうとイライラの原因になるだけです。また、明示的なフォーマットと、自動フォーマットとで整形結果が異なるときもあります。特にC#のラムダ式まわりで違いが具現化するのでイライラします。オートフォーマットが嫌いな人は、Visual Studioの設定で無効化しておくのが無難だと思います。

例1 (C++)

OpenGLやDirect3Dで頂点バッファの初期データを定義するときによくある例です。

namespace
{
    struct MyVertex { float X, Y, Z; float Color[4]; };
    // 以下の行をカット＆ペーストすると、Z の後ろのコンマと Color の間の空白がなくなる。
    const MyVertex Vertex1 = { 0.0f, +0.5f, 0.0f, { 1.0f, 0.0f, 0.0f, 1.0f } };
}

例2 (C++)

MFCが自動生成するコードとしてよく見られるものを、抽象化した例です。

class CMyDialog
{
public:
    CMyDialog() {} // 標準コンストラクター

// ダイアログ データ
    enum { IDD = 1 };
};

上記コードに対して明示的なフォーマットを実行したときに期待される動作は「// ダイアログ データの行が1レベルだけインデントされること」ですが、実際にフォーマットを実行しても何も起こりません。一方、カット＆ペーストすると、// ダイアログ データが// 標準コンストラクターの開始桁位置と揃うように勝手にタブ文字および空白が挿入されてしまいます。

例3 (C++, C#)

void MyFunc()
{
    const int MyConst = 0; // 定数。
    // 処理。
    if (false) {}
}

上記コードに対して明示的なフォーマットを実行したときに期待される動作は「何も変更されないこと」ですが、C#の場合は、// 処理。が// 定数。の開始桁位置と揃うように勝手にタブ文字および空白が挿入されてしまいます。また、C++においても、カット＆ペーストするとC#同様に勝手な整形が実行されてしまいます。
行末尾のコメントを禁止するコーディング規約を採用している場合はこの問題に遭遇することはないと思いますが、勝手に桁位置を揃えられてしまうとイライラしますね。

例4 (C#)

class MyClass
{
    // ここで
    // #if false
    // #
    // と入力すると、既存の #region および #endregion のインデントが消失する。
    #region Fields
    int field;
    #endregion
}

通常、#regionおよび#endregionは対象となるコードブロックのインデントレベルに合わせてインデントされますが、このバグが発動するとインデントが消失します。

他にも、

    {
        ...
    }

というブロックを含むC++ソースファイルをフォーマットすると、なぜか

    {
        ...
}

というようにブロックのインデントが消失することもあります。このバグは発動条件が不明で、まったく同じソースなのに現象が出たり出なかったりと不安定です。確かVS2012か2013あたりまでは、少なくともこういった不安定な挙動を示すことはなかったように記憶しています。

Windows Updateとの戦い（2018年春の陣、休止状態解除の亡霊）

Windows ソフトウェアTips

Windows 10 1703にて、2018-04-18にいくつかのセキュリティアップデートを適用したら、勝手にWindowsの休止状態 (hibernation) が解除されて復帰する（PC電源が勝手に入る）問題が多発するようになりました。休止状態はメモリ内容をストレージに保存してPC電源を落とすので、スリープよりも復帰に時間がかかりますが、休止中に停電が発生しても復帰ができるというメリットがあるので、就寝前にいつも使っています。

以前、休止状態の解除が頻発して困っていたときに、キーボードやマウス、ネットワークアダプターが原因かもしれないと思って、デバイスマネージャーにて[このデバイスで、コンピューターのスタンバイ状態を解除できるようにする]のチェックをすべて外していたので、これらのデバイスが原因である可能性は最初から除外しました。

まず、コマンドプロンプトを管理者権限で起動*1し、powercfg コマンドで前回の復帰の理由を調べます。

Microsoft Windows [Version 10.0.15063]
(c) 2017 Microsoft Corporation. All rights reserved.

C:\WINDOWS\system32>powercfg -lastwake
スリープ状態の解除履歴カウント - 1
スリープ状態の解除履歴 [0]
  スリープ状態の解除元カウント - 1
  スリープ状態の解除元 [0]
    種類: スリープ解除タイマー
    所有者: [SERVICE] \Device\HarddiskVolume2\Windows\System32\svchost.exe (SystemEventsBroker)
    所有者によって示された理由:

イベントビューアーのシステムログで「Power-Troubleshooter」を検索すると、以下のレコードが2018-04-20 05:35:00 (JST) に記録されていました。

システムは低電力状態から再開しました。

スリープ時間: 2018-04-19T16:44:22.759254000Z
スリープ解除時間: 2018-04-19T20:34:53.450160600Z

スリープ状態の解除元: タイマー - svchost.exe

「スリープ解除タイマー」とは何者でしょうか？　調べてみると電源オプションで無効化できるそうです。

[コントロール パネル] > [ハードウェアとサウンド] > [電源オプション]にて、現在選択されている電源プランの[プラン設定の変更] > [詳細な電源設定の変更]をクリック。
[電源オプション]ダイアログで、[スリープ] - [スリープ解除タイマーの許可]が[有効]になっていました。コイツを[無効]に変更して[OK]または[適用]ボタンをクリック。

これで一安心……と思いきや、やはり休止状態が勝手に解除されてしまいました。

もう一度powercfgとイベントビューアーで調べます。

Microsoft Windows [Version 10.0.15063]
(c) 2017 Microsoft Corporation. All rights reserved.

C:\WINDOWS\system32>powercfg -lastwake
スリープ状態の解除履歴カウント - 1
スリープ状態の解除履歴 [0]
  スリープ状態の解除元カウント - 0

イベントログには2018-04-21 04:38:25 (JST) に記録があります。

システムは低電力状態から再開しました。

スリープ時間: 2018-04-20T17:57:22.602822200Z
スリープ解除時間: 2018-04-20T19:38:20.464928200Z

スリープ状態の解除元: 不明

はい原因不明でした。

UpdateOrchestratorタスクグループ

タスクスケジューラで確認したところ、UpdateOrchestratorのRebootタスクが指定日時をトリガーとして登録されていました。
UpdateOrchestratorはWindows Updateに関わるタスクグループらしく、スリープや休止状態の勝手な解除を発生させる諸悪の根源です。UpdateOrchestratorを組み込んだMSのエンジニアは、本当に頭のおかしいキチガイでしょう。Windows 8.1からWindows 10に更新した後、しょっちゅうコイツに悩まされていましたが、ここ最近は小康状態だったので油断していました。1703でWindows Updateによる再起動前のリマインダーや、更新の一時停止（最大35日間）をできる機能が追加されたので、再起動の回数自体も減っていました。
ひとまずRebootタスクの[条件]にて、[タスクを実行するためにスリープを解除する]のチェックを外しておきましたが、次回のWindows Update後にはまた勝手に復活していることでしょう。なお、1709ではこの設定がUIから変更できなくなっているそうです。ユーザーにさらなる不自由を強いるとは許せませんね*2。

しかし、UpdateOrchestratorのRebootタスクを修正しても、やはり休止状態が勝手に解除されてしまいました。解除元は相変わらず不明です。

WindowsUpdateタスクグループ

WindowsUpdateのAutomatic App Updateタスク*3およびScheduled Startタスクを修正すると改善されるとの情報あり。前者は4時間ごとに無期限に繰り返すよう設定されていました。後者は指定日時をトリガーとして登録されていました。
しかし、[タスクを実行するためにスリープを解除する]はともにチェックが外れていました。
ほかに、AUSessionConnectというタスクも登録されており、これは[タスクを実行するためにスリープを解除する]にチェックが入っていました。
ひとまずAutomatic App UpdateタスクとAUSessionConnectタスクを無効化しておきました。Scheduled Startタスクは無効化しても、一定時間経つと勝手に有効化されるようです。なお、AUSessionConnectは[タスクを実行するためにスリープを解除する]のチェックを外して[OK]をクリックしても、なぜか以下のようなメッセージが表示されて、変更を反映できません。

---------------------------
タスク スケジューラ
---------------------------
タスク スケジューラ サービスが利用できません。タスク スケジューラはサービスへの再接続を試行します。
---------------------------
OK
---------------------------

しかし、Automatic App UpdateタスクとAUSessionConnectタスクを修正・無効化しても、やはり休止状態が勝手に解除されてしまいました。解除元は相変わらず不明です。

powercfgコマンドを使って、スリープ解除元のデバイスとタイマーを列挙してみます。

Microsoft Windows [Version 10.0.15063]
(c) 2017 Microsoft Corporation. All rights reserved.

C:\WINDOWS\system32>powercfg -devicequery wake_armed
NONE

C:\WINDOWS\system32>powercfg -waketimers
[SERVICE] \Device\HarddiskVolume2\Windows\System32\svchost.exe (SystemEventsBroker) によって設定されたタイマーは 04:33:06 (2018-04-24) で有効期限が切れます。
  理由:

デバイスは案の定存在しませんでしたが、タイマーが存在するようです。しかし「理由」が分からないのでタスクの特定ができません。

Windowsのタスクキャッシュ

Windowsの各タスクの設定情報自体は "%WinDir%/System32/Tasks" 配下にXMLファイル（拡張子は無し）の形で保存されていますが、レジストリ "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache" 上にもバイナリキャッシュが保存されているようです。またキャッシュのほうが優先されるらしく、XMLファイルを直接編集＆保存してWindowsを再起動しても変更内容が反映されません。タスクスケジューラのUIによる変更を確定しようとしたときにエラーとなるのは、おそらくキャッシュが破損しているからではないかと推測されます（4月のWindows Updateで破損した？）。しかしレジストリエディターでキャッシュを削除しようとしても、タスクスケジューラのサービスによってロックされているらしく、削除操作が拒否されます。また、タスクスケジューラのサービスはユーザーが停止させることができません。

セーフモードで起動してキャッシュを消そうかとも考えましたが、いい加減疲れたので、休止状態の勝手な復帰現象の原因追及はひとまずここまでとします。結局、休止状態にした後はPC電源スイッチを切る（｜→○）という原始的な方法で対処することにしました。電源スイッチのあるオーソドックスな自作デスクトップ機でよかった。

もう少し追跡してみます。Tasksフォルダー配下のすべてのファイルを対象に、

<WakeToRun>true</WakeToRun>

をグローバル検索してみたところ、前述のAUSessionConnect以外にいくつか引っかかりました。

このうち、rempl\shell と UpdateOrchestrator\AC Power Download はタスクが有効（準備完了）になっていたので、前者は[タスクを実行するためにスリープを解除する]のチェックを外し、後者は無効化しました。それ以外はすでに無効になっているので放置することにします。

Microsoft Windows [Version 10.0.15063]
(c) 2017 Microsoft Corporation. All rights reserved.

C:\WINDOWS\system32>powercfg -waketimers
システムにアクティブなスリープ解除タイマーがありません。

ようやくタイマーがなくなりました。ひとまずこれで様子見とします。

グラフィックスドライバーの勝手な更新

休止状態の解除問題とは直接の関係はありませんが、Windows Updateの履歴を見ると、2018-01-21に、NVIDIA GeForceドライバーが384.94から388.13に許可なく勝手に更新されていました。グラフィックスドライバーは特に相性問題を起こしやすく、たいていのパワーユーザーはドライバーの更新に慎重になるのですが、これが勝手に更新されるとなるとかなり困ります。以前はデバイスドライバーの更新に関してはオプショナル（任意）だったはずなのですが……
ひとまずグループポリシーでデバイスドライバーの更新を無効化する（[Windows Updateからドライバーを除外する]を[有効]に構成する）ことで対処しました。

Windows 10更新アシスタントの無限復活

3月頃には「Windows 10更新アシスタント」が勝手にインストールされて、1709のダウンロードが始まる事案が発生しました。更新アシスタントはコントロールパネルで削除しても無限に復活する、まさにゾンビのように厄介なアプリです。グループポリシーでは無効化できず、以下のサイトを参考にしてようやく抑制できました。
www.atmarkit.co.jp

MSはどうしても1709の導入ベースを増やしたがっているようですが、だからといってユーザーの許可なく勝手にアプリをインストールするなんて破廉恥極まりないですね。年2回の大型アップデートスケジュールも、無理やりスケジュールを守ろうとして品質の確保ができなくなってしまっているのが目に見えています。機能追加のためのアップデートとスケジュールではなく、スケジュール遵守のための無理な機能開発になってしまっていて、目的と手段が完全に入れ替わってしまっていますね。お粗末としか言いようがないです。そもそも大型アップデートにより追加あるいは削除される機能のうち、大半は誰も望んでいない変更です。しかも新機能はことごとくオプトアウトなのも始末が悪いです（余計な機能がデフォルトで有効化されていて、無効化するためにはユーザーがいちいち設定を変更しなければならない）。

Windows 10はユーザーの自由と時間と情報と安眠と電気代を奪っている

Windows 8.1までは良くも悪くもエンドユーザーがWindows Updateのタイミングと内容を完全にコントロールすることができていました。翻ってWindows 10では、ユーザーにほとんど自由がありません。せっかく設定を変更して抑制しても、Windows Updateを適用すると（MSにとって都合のいいように）設定が毎回リセットされてしまいます。ましてや、余計な機能てんこ盛りで品質の低い大型アップデートを勝手にインストールして、ユーザーのシステムを台無しにするなんて、犯罪にも等しいです。また、MSは個人情報収集のためには手段を選びません。なりふり構わずあの手この手を使ってきます。知識がないライトユーザーは簡単に騙されて大量に個人情報をぶっこ抜かれてしまうでしょう。こういう汚いことを続けていれば、どんどんパワーユーザーが離れていくということにMSは気付かないんでしょうか。本当に過去最悪のOSです。Windows 10の汚らしい挙動と、MSの下品なゴリ押しのせいで、Direct3D 12*4もUWPも開発に使う気がすっかり消え失せました。開発環境としてずっと慣れ親しんできたWindowsですが、もうウンザリです。もはやWindowsプラットフォーム固有の開発には積極的に投資したくありません。

今のところゲームやクリエイティブツールの関係上、どうしてもWindowsを使わざるを得ない状況ですが、今後Wineの完成度が上がればいずれWindowsを捨ててLinuxに移行したいですね。ソフト電池のような認証ツールもWine環境に対応してくれたらいいのですが。

※2018-06-03追記：
5月度のWindows Updateを実行すると、案の定またスリープ解除タイマーが復活しました。例のごとくタスクのXMLファイル群をグローバル検索してみると、

というタスクが有効かつWakeToRunがtrueになっていたので、[タスクを実行するためにスリープを解除する]のチェックを外しておきました。

※2018-07-16追記：
6月度のWindows Updateを実行すると、以下のタスクが有効かつWakeToRunがtrueになっていたので、[タスクを実行するためにスリープを解除する]のチェックを外しておきました。Windows Updateのたびにスリープ解除タイマーを復活させやがることが分かったので、そろそろ無効化作業を自動化したいですね。

※2018-08-14追記：
7月度のWindows Updateを実行してみたところ、今回はスリープ解除タイマーを復活させていないようです。

※2018-09-17追記：
8月度のWindows Updateを実行してみたところ、今回はスリープ解除タイマーを復活させていないようです。

※2018-09-25追記：
1703のサポート期限が迫ってきたため1803に更新したところ、以下のタスクが有効かつWakeToRunがtrueになっていたので対処。

しかし、UpdateOrchestrator\Schedule Retry Scanに関してはタスクスケジューラのUIから[タスクを実行するためにスリープを解除する]をアンチェックもしくは無効化しようとすると、権限がないと言われてしまいます。以下を参考に、管理者権限で psexec を使うことでタスクを無効化できました。
ykw-note.hatenablog.com

C:\Users\XXX\PSTools>psexec -s -accepteula -nobanner schtasks /Change /TN "\Microsoft\Windows\UpdateOrchestrator\Schedule Retry Scan" /DISABLE

成功: スケジュール タスク "\Microsoft\Windows\UpdateOrchestrator\Schedule Retry Scan" のパラメーターは変更されました。
schtasks exited on <PCName> with error code 0.

※2019-03-03追記：
2019年1月度のWindows Updateを実行してみたところ、スリープ解除タイマーが復活しました。
今回は以下のタスクが有効かつWakeToRunがtrueになっていました。

しかし、タスクスケジューラのUIから[タスクを実行するためにスリープを解除する]をアンチェックもしくは無効化しようとすると、
「タスク スケジューラ サービスが利用できません。タスク スケジューラはサービスへの再接続を試行します。」と言われてしまいます。
以前のようにpsexecで対処しました。

C:\Users\XXX\PSTools>psexec -s -accepteula -nobanner schtasks /Change /TN "\Microsoft\Windows\UpdateOrchestrator\AC Power Download" /DISABLE

ちなみに UpdateOrchestrator\Schedule Retry Scan は UpdateOrchestrator\Schedule Scan に改名(？)されたようです。

※2019-04-24追記：
2019年3月度のWindows Updateを実行してみたところ、スリープ解除タイマーが復活しました。
今度は UpdateOrchestrator\AC Power Download が消えて、UpdateOrchestrator\Schedule Retry Scan が復活していました。

[SERVICE] \Device\HarddiskVolume2\Windows\System32\svchost.exe (SystemEventsBroker) によって設定されたタイマーは 01:45:38 (2019-05-08) で有効期限が切れます。
  理由: Windows は、スリープ状態の解除を要求したスケジュールされたタスク 'NT TASK\Microsoft\Windows\UpdateOrchestrator\Schedule Retry Scan' を実行します。

※2019-06-22追記：
2019年5月度のWindows Updateを実行してみたところ、スリープ解除タイマーが復活しました。
今度は UpdateOrchestrator\Schedule Retry Scan が消えて、UpdateOrchestrator\AC Power Download が復活していました。

[PROCESS] \Device\HarddiskVolume2\Windows\SystemApps\ShellExperienceHost_*\ShellExperienceHost.exe によって設定されたタイマーは 00:00:00 () で有効期限が切れます。

※2019-09-12追記：
2019年7月度のWindows Updateを実行してみたところ、スリープ解除タイマーが復活しました。
今度は UpdateOrchestrator\AC Power Download が消えて、UpdateOrchestrator\Schedule Retry Scan と UpdateOrchestrator\Schedule Scan が復活していました。
しかし、これらのタスクをpsexecで無効化しても、依然としてタイマーが残っています。他にWakeToRunがtrueになっている有効なタスクは見つかりません。

※2020-09-03追記：
2020年7月度のWindows Updateを実行してみたところ、スリープ解除タイマーが復活しました。

[PROCESS] \Device\HarddiskVolume2\Windows\SystemApps\Microsoft.Windows.StartMenuExperienceHost_*\StartMenuExperienceHost.exe によって設定されたタイマーは 00:00:00 () で有効期限が切れます。

[SERVICE] \Device\HarddiskVolume2\Windows\System32\svchost.exe (SystemEventsBroker) によって設定されたタイマーは 01:39:49 (2020-09-17) で有効期限が切れます。
  理由: Windows は、スリープ状態の解除を要求したスケジュールされたタスク 'NT TASK\Microsoft\Windows\UpdateOrchestrator\Backup Scan' を実行します。

StartMenuExperienceHost.exe はスタートメニュー専用のホストプロセスらしいです。Windows 10 1903にてエクスプローラーから分離されたとのこと。
とりあえず UpdateOrchestrator\Backup Scan のほうをpsexecで無効化して様子見。

C:\Users\XXX\PSTools>psexec -s -accepteula -nobanner schtasks /Change /TN "\Microsoft\Windows\UpdateOrchestrator\Backup Scan" /DISABLE

※2020-09-30追記：
いつのまにかスリープ解除タイマーが復活しました。

[SERVICE] \Device\HarddiskVolume2\Windows\System32\svchost.exe (SystemEventsBroker) によって設定されたタイマーは 07:59:29 (2020-09-30) で有効期限が切れます。
  理由: Windows は、スリープ状態の解除を要求したスケジュールされたタスク 'NT TASK\Microsoft\Windows\UpdateOrchestrator\Universal Orchestrator Start' を実行します。

[PROCESS] \Device\HarddiskVolume2\Windows\SystemApps\Microsoft.Windows.StartMenuExperienceHost_*\StartMenuExperienceHost.exe によって設定されたタイマーは 07:59:29 (2020-09-30) で有効期限が切れます。

とりあえず UpdateOrchestrator\Universal Orchestrator Start のほうをpsexecで無効化して様子見。

※2021-10-23追記：
Windows 10 21H1にて、久々にスリープ解除タイマーが復活しました。しかし原因はWindows Updateではなく、StartMenuExperienceHost.exe のようでした。

[PROCESS] \Device\HarddiskVolume2\Windows\SystemApps\Microsoft.Windows.StartMenuExperienceHost_*\StartMenuExperienceHost.exe によって設定されたタイマーは xxx (yyy) で有効期限が切れます。

xxx と yyy の部分はそれぞれ時刻と日付のはずですが、文字化けして変なデータが表示されています。2019年12月末頃に現象が発生していた環境もあるみたいですね。このタイマーはライブタイル (Live Tiles) の通知と関連があるようです。

superuser.com

グループポリシーエディターでライブタイルの通知を無効化し、OSを再起動することでタイマーがなくなりました。

以前Windows 10ではライブタイルが廃止されるとかいう噂が出ていましたが、Windows 10では一応残るものの、Windows 11では本当に廃止されたみたいですね。自分は天気アプリのライブタイルくらいしか活用していませんでした。スタートメニューの項目がちらちら変化すると視界に入って鬱陶しいんです。ニュースアプリのライブタイルとかも気が散るのでオフにしていました。モバイルとデスクトップは作法が全然違うことを理解していない企業が多すぎます。MSとかMozillaにはバカの一つ覚えの無能デザイナーしかいないんでしょうか。

※2022-02-22追記：
また本日も休止状態が勝手に解除されました。しかしpowercfgコマンドで調べても、タイマーは存在していません。
ふとデバイスマネージャーでキーボードやポインティングデバイスの電源管理プロパティを調べてみようと思ったところ、なぜか「HID キーボード デバイス」が2つ、「HID 準拠マウス」が2つリストアップされています。片方はスタンバイ解除オプションのチェックが入った状態、片方はチェックが外れた状態になっていました。気持ち悪いのでとりあえずチェックは外しておく。
イベントログには2022-02-22 03:57:57 (JST) に記録がありましたが、相変わらず原因不明で役に立ちません。

システムは低電力状態から再開しました。

スリープ時間: 2022-02-20T20:35:12.506912200Z
スリープ解除時間: 2022-02-21T18:57:47.737867700Z

スリープ状態の解除元: 不明

まあ実際の原因は十中八九Windows Update (UpdateOrchestrator) の監視タイマーだと思います。謎のシグナルを受けて深夜に勝手に再開するクソOS。本当にMSの開発者は首を吊って死ねばいいのに。
以下を参考に、グループポリシーで「Windows Update の電源管理を有効にして、システムのスリープ状態が自動的に解除され、スケジュールされた更新がインストールされるようにする」を無効化しました。ひとまず様子見とします。
itojisan.xyz

*1:余談ですが、最初のカレントディレクトリは通常権限だと「%UserProfile%」で起動する一方、管理者権限だと「%SystemRoot%\System32」で起動しますね。

*2:MSが運営している各種フォーラムには、こういった明らかにユーザーに不利益を強いているMSの姿勢すら擁護する大量のマゾ信者がグルとして涌いていて、本当に気持ち悪いです。

*3:Windowsストアアプリを自動更新するためのタスクらしいです。ところでストアアプリなんていう不自由なもの、誰が好き好んで使うんですか？

*4:Direct3DとHLSLの進化が停滞すると競合のOpenGL/VulkanとGLSLも停滞することが予想されるので、Direct3Dの更新自体は続けて欲しいのですが、個人的には今後プラットフォーム独自仕様のDirect3D/MetalよりもクロスプラットフォームなVulkanのほうが普及率が高くなり、API統一が進むのではないかと（期待を込めて）予想しています。

Vulkanグラフィックスの簡単なレンダリングサンプル

C++ Vulkan プログラミングTips GPU MFC

このあいだ書いた記事「VulkanシェーダーでSub-group命令を使う」では、グラフィックスをすっ飛ばしていきなりコンピュートシェーダーで拡張命令を試すという変態的なことをしましたが、GPGPUに興味のない人には退屈な内容だったかもしれません。

以前、Direct3D 12の簡単な入門記事「Direct3D 12 (DirectX 12) の簡単なサンプル」を書いたときには、コマンドリストの中で複数のPipeline State Object (PSO) を切り替えて、異なるシェーダーを適用してトライアングルをレンダリングするためのテストコードを実装しました。
今回はVulkanを使ってまったく同じことをします。レンダリング結果はD3D12バージョンとまったく同じになるようにしました。あらかじめ断っておきますが、「簡単なレンダリングサンプル」と言ったな。あれは嘘だ。

https://sygh-jp.github.io/content_hosting/my_program_ss/MyMfcSimpleVkTest1_ss_2018_04_17a.png

例のごとくMFCと公式のVulkan C++ラッパーを使って省力化していますが、それでも初期化コードが鬼のように長くなりました。Queue Family IndexやMemory Type Indexなど、ハードウェアの構成や仕様の差異にプログラマーサイドが柔軟に対応できる能力がある反面、抽象化層が極端に薄く、やはりAPIとしてはDirect3D 12を遥かにしのぐ難易度です。なかでも最難関だと感じたのは、やはりD3D12でのDescriptor Heapに相当するDescriptor Setまわりでした。頂点バッファとUniform Buffer Object (UBO) を使っているだけなのに、すでにこの有様です。分かってはいましたが、これにインデックスバッファやテクスチャ、Shader Storage Buffer Object (SSBO) といったおなじみの要素が加わってくるとなると、もうあっという間に複雑度が爆発して個人レベルでは手に負えなくなるのは目に見えています。

ちなみに、前回D3D12で使ったHLSLシェーダーを、中間言語であるSPIR-Vにコンパイルして、Vulkanでもそのまま使うことができました。一見地味ですが、HLSLシェーダーを一切変更することなく、Vulkanからも利用できるというのは驚異的ですね。これこそが中間言語の威力です。Cg言語のようなソフトウェアトランスレーターとは訳が違います。Direct3DではHLSLが登場する前から、ベンダー非依存のシェーダーアセンブラが中間言語として導入されていたことで、ハードウェアやドライバーの差異を気にすることなく開発できていましたが、OpenGLはなぜもっと早く同様のシェーダー中間言語を導入してこなかったのか、本当に惜しまれます*1。

相互運用について

OpenGLやDirect3D 11には、VulkanやDirect3D 12との相互運用を可能にするレイヤーや拡張が用意されています。従来のGL/D3Dアプリにおいて、Vulkan/D3D12に完全移行することはできないが、大量のドローコールのせいでボトルネックになっている箇所だけどうしても高速化したいという場合には、そういった相互運用を検討してもよいかもしれません。ただ、個人的な経験（手痛い失敗経験）から言わせてもらうと、やはり安定したアプリケーション開発のためには、あちこちに手を広げてむやみに複雑な解決策を持ち込もうとせず、できるかぎり単一のAPIのみに絞ったほうがいいと思います。理由として、複数の言語やAPIおよびフレームワークを混在させたハイブリッド開発は、コーディングがメチャクチャ疲れるうえに不具合を混入させやすいからです。また、相互運用が標準機能でなく拡張機能の場合は、ベンダーやユーザープログラマーによって十分テストされていないことから潜在的に不具合を抱える確率が高くなります。単に相互運用の能力があるということと、実際にそれを製品コードに使う、ということには大きな隔たりがあります。
CUDA/OpenCLにもGL/D3Dとの相互運用機能が存在しますが、GPGPUによるシミュレーション結果を可視化したいときは、（CUDA/OpenCLを使ったほうが効率的に記述できる場合を除いて）できるかぎりGLSL/HLSLのコンピュートシェーダーを使うべきでしょう。

*1:OpenGL 4.6でGL_ARB_gl_spirvつまりSPIR-Vのサポートが標準化されましたが、2018年4月時点でフル対応ドライバーをリリースしているのはNVIDIAだけです。本家OpenGLで中間言語が早期に実現されていれば、派生規格であるOpenGL ESでも採用されていたはずで、アプリケーション開発者がベンダードライバーごとのシェーダーコンパイラーの挙動の違いなんぞに苦労することもなかったと思います。

Windows 10の右クリックメニューにコマンドプロンプトを復活させる

Windows ソフトウェアTips

Windows 7のエクスプローラーで、Shiftキーを押しながらコンテキストメニュー（右クリックメニュー）を表示すると、「コマンド ウィンドウをここで開く」という隠しコマンドが表示され、コマンドプロンプトのカレントディレクトリをそのディレクトリに設定した状態で起動することができます。通例、コマンドプロンプトを起動するとカレントディレクトリは%UserProfile%に設定されるので、特定のディレクトリ（フォルダー）でバッチ処理をしたくなったときにディレクトリの移動が煩雑なのですが、そういうときにこの隠しコマンドが威力を発揮します。
Windows 8.xおよびWindows 10 Anniversary Update (1607) までは同様の機能を備えていました。

しかし、Windows 10 Creators Update (1703) では、「PowerShell ウィンドウをここに開く」というメニューコマンドが追加され、逆に「コマンド ウィンドウをここで開く」は削除されてしまいました。
Windows PowerShellは確かにコマンドプロンプトと比べて遥かに強力ですが、オプション書式に互換性がなく、従来のコマンドに複雑なオプションを指定した場合はそのままでは実行できなくなっているため、依然としてコマンドプロンプトの需要は残っています。

コマンドプロンプトを起動するためのメニューコマンドを復活させるには、レジストリをいじる必要があります。

毎回手作業で実行するのは面倒ですので、今回は「コマンド ウィンドウをここで開く」コマンド復帰の手順を一発で実行するためのレジストリファイルの内容を記載しておきます。UTF-16LE形式のテキストファイルで.reg拡張子を付けて保存してください。ただしご利用は自己責任でどうぞ。

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Classes\Directory\Background\shell\cmd]
"HideBasedOnVelocityId"=dword:00000000
"ShowBasedOnVelocityId"=dword:00639bc8

なお、上記のエントリを追加しただけでは、エクスプローラー右ペインのリストビューのディレクトリアイテムに対してコンテキストメニューを表示したときにメニューコマンドが表示されませんが、それほど困ることはないと思います。カレントディレクトリに設定したいフォルダーを開いて、リストビューの余白内でメニューを表示するか、あるいはエクスプローラー左ペインのツリービューのディレクトリアイテムに対してメニューを表示することでコマンドが出現するので、必要十分ではないでしょうか。
また、上記エントリは現在のWindowsログオンユーザーのレジストリのみに追加され、ほかのユーザーには影響しません。

ちなみに、特定のディレクトリをカレントに設定した状態でコマンドプロンプトを起動する他の方法としては、エクスプローラーのアドレスバーに「cmd」と入力する手もあります。

ネットワークディレクトリ

ネットワークディレクトリ（\\で始まるUNCパス）は、コマンドプロンプトのカレントディレクトリとして使えないという制約があります。そのため、ネットワーク上の共有フォルダーにて「コマンド ウィンドウをここで開く」を実行すると、まずWindowsによって自動的にネットワークドライブレターが割り当てられてから、そのドライブ上で改めてコマンドプロンプトが起動するという動作をします。

コマンドプロンプトの将来

隠しコマンドにPowerShellを追加するにしても、コマンドプロンプトを残して両方使えるようにしておけばいいのに、なぜわざわざ削除したんでしょうか？
MSは将来的にレガシーなコマンドプロンプトを抹殺する気なのかもしれませんが、肝心のPowerShellが完全な上位互換でないのに移行できるわけがありません。
そんなにPowerShell推しなんだったら、まずVisual StudioのコマンドベースユーティリティをPowerShellに置き換えてみせろよと言いたいです。PowerShellのバージョンがフラグメンテーションを起こしていることもあるせいか、いまだにVisual StudioのツールはPowerShellでなくコマンドプロンプトに依存している部分が多々あります。

ascii.jp

余談

実は、Shiftコンテキストメニューには、ほかにも「パスとしてコピー」（Windows 7）あるいは「パスのコピー」（Windows 8.x/10）という便利な隠しコマンドが用意されています。このコマンドはディレクトリおよびファイル両方に対して使用でき、実行することでクリップボードにアイテムの絶対パス文字列をコピーします。
ディレクトリのパスは通例エクスプローラー上部のアドレスバーをクリックすることでも簡単に取得できますが、Windows Vistaまではファイルのパスを1アクションで取得する機能がなく不便でした。こういった細かいユーティリティは、OSの標準機能として提供されていることが一番重要です。標準機能であればどの端末でも必ず使えることが保証されているので、サードパーティ製のプラグイン／ツール／サービスをインストールできない環境を使うときや、エンドユーザーあるいは同僚に操作の指示を出したりマニュアルを作成したりするときに重宝します。OSの設定を変更することなく、最初から既定でどのユーザーでも使えるようになっていることも必須条件ですね。

VulkanシェーダーでSub-group命令を使う

C++ Vulkan プログラミングTips GPU CUDA

NVIDIAはKepler (Compute Capability 3.0) 世代のハードウェアにおいて、Warp Shuffle命令を実装しました。WarpシャッフルはCUDAから組み込み関数 (intrinsic function) の形で利用できるSIMD命令の一種で、Warpと呼ばれるスレッドグループ内での並列データ交換を実現する機能です。NVIDIAのGPUでは、ひとつのWarpは32個のハードウェアスレッドからなり、またWarp内の各スレッドはすべて同じ命令を実行します*1。つまり、ひとつのWarp内のスレッド群はすべて同期して並列動作する*2ため、Warpシャッフルを使うことで、データ列の総和を求めるリダクション演算などを、共有メモリを使うよりも高速に並列実行することができます。

Warpシャッフルに関しては、以前「CUDA Warpシャッフル命令のエミュレーション」という記事を書きましたが、CUDAの共有メモリに関する知識があれば、Warpシャッフルがいかに便利で簡潔な機能であるかを理解できると思います。

WarpシャッフルのようなSIMD命令は、汎用的な計算（GPGPU）だけでなく、グラフィックスのポストエフェクト処理などの高速化にも非常に有用なのですが、APIの停滞のせいであまり標準化が進んでいませんでした。NVIDIAはWarpシャッフル命令をHLSL/GLSLから利用できるベンダー拡張を提供していますが、当然NVIDIA環境でしか使えないという制約があります。

Warpシャッフル相当の機能はまた、OpenCL 2.0の拡張機能cl_khr_subgroupsおよびOpenCL 2.1のコア機能として策定されていますが、2018年3月現在、OpenCLの実装はどのベンダーも停滞しており、OpenCLには期待できない状況です。一方、OpenGLにもARB拡張GL_ARB_shader_ballotとして存在しており、OpenCL同様にサブグループ (Sub-groupあるいはSubgroup) と呼ばれています。GL_ARB_shader_ballotはCUDAのWarpシャッフルのサブセットであるものの、GLSLを使えばOpenGLだけでなくVulkanからも基本的なサブグループの機能を利用できます。

Vulkanの学習を兼ねて、コンピュートシェーダーにてサブグループ命令を利用するサンプルコードを書いてみました。実行にはVulkan 1.0とVK_EXT_shader_subgroup_ballot拡張をサポートする環境が必要となります。NVIDIAハードウェアの場合、Kepler世代以降であれば拡張をサポートしているはずです。サンプルはWindows環境向けですが、ウィンドウシステムへのアクセスを必要としないオフスクリーンのコンピュート機能だけを使っているため、他の環境に移植するのは比較的簡単だと思います*3。

以前書いた記事「Vulkan SDK付属のGLSLコンパイラー」では、Vulkan SDK付属のシェーダーコンパイラーがあまりに未完成なことを嘆いていましたが、その後着々と進化を続け、ほぼ使えるレベルに達したようです。
なお、今回はホストコードの記述量を減らすため、C++向けのラッパー (vulkan.hpp) を使っています。もともとこのラッパーはNVIDIAから寄贈されたものをベースに公式化されたらしいのですが、設計不足な点が散見されたり、一部の関数テンプレートのコンパイルが通らないというひどいバグが混入していたりと、まるでテストされていないことがありありとうかがえます。はっきり言ってプロダクションコードに使うには厳しい印象です。本気でVulkanの導入を検討する場合は、ぶっちゃけこのラッパーは使わないほうがいいでしょう。

なお、AMDはAnvil*4という上位レベルのVulkanベースフレームワークを公開していますが、いつも仕事が中途半端なAMDが、この先ちゃんと継続的にメンテしてくれるのかどうか不安です。AMD APP SDKも、2015年8月にリリースされたv3.0で放置されたままという体たらくなので、正直期待できません。

Vulkan 1.1とSub-group命令

先日Vulkanのアップデートとしてv1.1が発表されましたが、Direct3D 12が先行していた、マルチGPUの活用やシェーダーモデル (SM) 6.0に対応する形で、重要な新機能が追加されているようです。サブグループ演算 (subgroup operation) に関しても、既存のOpenGL互換のARB拡張とは別のKHR拡張 (GL_KHR_shader_subgroup) およびホストAPIの正式仕様が策定され、CUDAと同等あるいはそれ以上の機能を獲得したようです。

なお、DirectXにおけるSM 6.0の目玉とも言えるのが、Sub-groupに相当するWave命令セットです。Waveは機能レベル12_0以上でないと使えないとか、そもそもDirect3D 12自体がWindows 10でないと使えないとかいう制約があり、個人的にはプラットフォーム制約の少ないVulkanのほうが有望だと思うのですが、いずれにせよこれでようやくCUDA以外でも高速なSIMD命令が標準的に利用できる土台が整い始めました。
とはいえ、HLSLもGLSLも、CUDA C++に比べるとプログラマビリティは遥かに劣ります。個人的にはC++のテンプレートが使えないのが一番痛いです。OpenCLは2.2でようやくカーネル記述言語にC++を採用しましたが、PCプラットフォームではまだどのベンダーもOpenCL 2.2をサポートしていません。純粋なGPGPU用途であれば、結局CUDAの地位は安泰であり、ただ単にNVIDIAハードウェアの能力を最大限活用できるAPIというだけでなく、地球上でもっとも生産性の高いGPGPU開発基盤であることは疑いの余地がありません。VulkanはせっかくSPIR-Vという強力なシェーダー中間言語を持って生まれたのだから、今後はシェーダーコンパイラーのさらなる飛躍と、Metalシェーディング言語のような新しいC++ベースのフロントエンドのサポートに期待したいところです。

*1:AMD GPUにおいてもWarp同様の概念としてWavefrontが存在します。Wavefrontは64個のハードウェアスレッドからなります。

*2:GPUコアの1サイクルでWarp内のすべてのスレッドが同時に駆動するとは限りませんが、論理的には必ず同期するようになっています。

*3:OpenGLでは仮にコンピュートを利用するだけであっても、GLコンテキストの作成にウィンドウハンドルを必要とし、しかも実行デバイスを明示的に選択する機能すら標準で提供されていませんでしたが、Vulkanは遥かに洗練されており、OpenCLやDirectComputeと似たような使い方ができるようになっています。

*4:Anvilとは「金床」（かなとこ）という意味ですが、UbisoftのAnvil Engineとカブっているので、できれば別の名称にして欲しかったです。