TvRock自身によるACPI Wake Alarmの遅延補正アプリケーション

 TvRock.exeに直接スリープからの復帰(レジューム)時刻の補正を行ってもらうアプリを作り、RTMfTと名付けてgithubに公開しました。

スリープ開始時刻から録画のために復帰する予定時刻が3.5時間以上未来の場合はACPI Wake Alarmによる復帰が行われるものと見なして補正処理を行います。
なお、補正時間の計算式の根拠については先の記事をご覧ください。補正を行った場合は補正内容がログに出力されます。

おまけ機能としてTvRock頓死監視機能を付けました。まれに番組表から予約操作などをすると頓死することがあるので、手動で再起動するのが面倒な方向けですが、まず使用する必要はないとは思います。

本プログラムはDLLインジェクションという手法を用いて動作中のTvRock.exeに対してパッチを当てます。
そのため、ほかの補正用プログラムを常時起動しておくことが不要になり計算機資源の省力化を達成し、意識高い系用語でいうところのSDGsへの貢献ができるという欺瞞に満ちた満足感を得られる可能性があります。

制限事項として、このプログラムは表題のとおり、ACPI Wake Alarmによってスリープからの復帰(レジューム)を行っても遅延しない環境では復帰時刻が正常よりも早まってしまいますので使用しないでください。

また、採用した手法により、アンチウィルスソフトによる誤判定を受ける可能性が想定されます。判定の正誤はソースプログラムから自分で判断してください。判断できない場合はTvRock.sch使用版を使うという手段があります。

なお、動作可能OSはWindowsVista以後です。

先に作成したプログラムだとtvrock.schの監視が必要だし、そもそもTvRock.exe自身が補正すれば話は簡単じゃないかと思い、改めて作成しました。

基本機能の実装そのものはすぐ終わっていたのですが、8日間も38度を超える強烈な病気になってしまい、TvRock頓死対策などのおまけ機能の着手が大幅に延期されてリリースが遅れました。

だれにも求められていないアプリの記事で大変恐縮です。

以上、お読みいただいてありがとうございました。

TvRockの予約録画時のスリープからの復帰方法について

 いまさらTvRockかとお呆れのかたもございましょうが、お許しください。

(成果物だけほしい方向け: `tvrock.schから補正'版はこちら、`TvRock単体で動作`版はこちらです)

表題の件ですが、タスクスケジューラとそれ以外があります。そして、今回はそれ以外のほうのお話をさせていただきます。

その前に、まず小ネタから。

0.9t8ではTvRockDTV.x64.dllがないためにTvTestとかTSTaskの64bit版が動かないとお嘆きの方に。実は0.9u2で生成させたTvRockDTV.x64.dllをそのまま保持しておいて0.9t8に戻せばTvTestやTSTaskの64bit版が使えます。

他は64bit化したものの、TvRockだけはどうにも余人を以て代え難く、しかし0.9u2はTvRockがOSのスリープを(powercfg /requestsoverrideしてしまわない限り)阻止し続けるので使いたくないという方向けのニッチすぎる情報でした。

さて、TvRockで録画を予約するときに「復帰処理をタスクスケジューラで行う」にチェックボックスを入れていなくてもきちんとスリープから復帰して録画が開始されますが、powercfg /waketimersを行ってもスリープ状態の解除タイマーはありません。

以前から気になっていたのですが、今回こんなネタを知ったのでスリープからの復帰時間の補正をするツールを書くついでにだいたい見当はつくけど確かめてみようということでghidraを用いてバイナリを紐解いてみました。

思った通りWM_POWERBROADCASTを受けたときにwParamがPBT_APMSUSPENDのとき、つまりスリープに入る直前にSetWaitableTimerして、レジュームした直後(PBT_APMRESUMEAUTOMATIC)にCancelしてました。

そのため、普段はpowercfg /waketimersを行っても見えません。普段は登録されていないのですから当たり前です。

ここで、先のACPI Wake Alarmによる遅延のために何とかしたいとする場合は、予約前の準備時間以上スリープしないようにシステムを設定しておくのが無難でしょう。

あえてプログラムを書こうという場合、いくつかアプローチがありますが、私はtvrockと同様にWM_POWERBROADCASTでPBT_APMSUSPENDを受けたときにtvrock.schから現在時刻からの直近で4時間以上未来の録画予約があれば予想遅延時間を引いた時刻でwaitable timerを設定しています。この方法だとPBT_APMSUSPENDをもらってから2秒以内にすべてを終わらせる必要があるのでCで書きました。

でもこれは物好きだからやっているだけで、普段からtvrock.schを監視しておいて、変更されたらschtasksコマンドやpowershellを使ってタスクスケジューラ経由でスリープを解除させる方法が簡単だと思います。TvRock.exeではTvRock.schを開く際はCreateFile()で排他しているので書き込み中にリードしたりといった事故は起きないと思います。

ちなみにtvrock.schのSTARTはunix epochなJSTです。

tvrockを卒業することになるかと思いきや、解決策が見つかってしまったのでまだまだ使い続けることになりそうです。やっといてなんですが、もう録画してまで見るものがないのでした。

最後で恐縮ですが、TvRock, TvTest, RecTest, TSTask, Spinel, BonDriverProxyEx, BonDriver_PT3-ST, pt2wdm の作者様方のみならず、多くの関係者の方に心から感謝しています。

以上、このような駄文を読ませてしまい、誠に申し訳ございませんでした。

TvRockをいじり倒していたらBSODに。

Windows10で初のBSODに遭遇いたしましたので、記念に記録いたします。
BSODはブルースクリーン・オブ・デスの略で、要はカーネルパニックみたいなもんです。

ここのところ、いろいろな経緯から録画管理ソフトのTvRockというソフトウェアをいじくり倒しています。

とうの昔に開発が終了しているソフトウェアなのですが、これが実に使い勝手が良いので、Windows10に更新して発生した事象について調べたりしているうちにBSODが発生してしまうようになりました。

具体的には、TvRockのﾊﾞｰｼﾞｮﾝをいろいろ差し替えたり、有志の方がパッチを当てたﾊﾞｲﾅﾘを入れてみたり、ごちゃごちゃやっているうちに、スリープからの復帰時に予期せぬ再起動がかかってしまうようになりました。

びっくりしましたが(びっくりしたのは、再起動がかかったことではなく黙って再起動されたことに対してです)、BSODが発生してもWindows10か、もっと前からかもしれませんが、BSODを表示せず即座にリブートをかけて何事もなかったようにシレっと証拠隠滅を図るのがマイクロソフトさんの進む道のようです(設定によって変えられますが、規定値がそうなっているということです)。

よほどへんてこなソフトを入れた挙句に苦情をマイクロソフトさんに持ち込まれて散々痛い目に合ったものとお察しします。
「何もしてないのにおかしくなった」なんてセリフを平気でのたまっちゃう厚顔無恥な奴ってどこにでもいますから、心からの同情を禁じえません。何もしなければ何も起きません。何かすれば何かが起きます。

が、そういうユーザが、BSODが発生したために再起動になった、という情報も知らされずいきなり再起動してしまってさらにわけがわからない状況に追い込まれるという悪循環を作り出していて大変興味深いなあ、と思いました。
もう、この愚民政策はマイクロソフトさんだけでなく、どこもかしこもやってることですから、止められない流れなのでしょう。
まあ、Windows10からはWindowsUpdateも止められないというほどに、どこぞの国の特別委採決も真っ青な強硬っぷり(Homeエディションは設定すら不可)なので、より一層MSさんは責任重大ですね。それこそ「知らないうちにおかしくなった」という主張が正当性を帯びますもんね。

それはさておき、今回のケースでは、手動でスリープに入らせても自動(時間経過)でスリープに入らせても、必ずBSODを引き起こしました。

スリープ解除要因も、例えばマウスやキーボードを動かしたり押下してもBSODになりますし、録画時刻になってスリープが解除される時刻にもBSODになったりと、要因が分からなければ泣きたくなるような事象でした。
イベントログを見ても、KP41問題とかでやけに著名ですがソース:Kernel-PowerのイベントID:41の、

「システムは正常にシャットダウンする前に再起動しました。このエラーは、システムの応答の停止、クラッシュ、または予期しない電源の遮断により発生する可能性があります」

ってやつが記録されているだけです。

わあ、KP41問題だあ!!

・・・ってなわけがないんです。
なんだか巷では大流行になっちゃってますが、KP41問題とか言っている大半の事由は本当に電源に由来するものではありません。
よほどしっかりした設計のサーバ機ならともかく、そんなことまできっちりとログからトラブルシュートできるAT互換機がお手頃価格で市販されているなんてのは幻想と思ってもいいです。

当然、今回もTvRockをガチャガチャいじくっていることが問題であることは明白です。

サバを読んでいきなりNT6.2から10に数字を変えましたが、この辺はWindows2000から私は信頼出来るなあ、と思っておりますので、慌てずまずダンプが残っているかどうかを調べますと、やはりいきなり再起動したように見せていても、きちんとメモリダンプは残されていました。

そのダンプをWinDbgで解析してみると、pdc.sysでVIDEO_SCHEDULER_INTERNAL_ERRORを吐いてBSODに至ったことが分かりました。電源管理に関するドライバです。
もっと言えば、スリープ時に関連するドライバのド直球です。

従って、直前にいじっていたTvRockをアンインストールして、そのうえでアンインストール時にTvRockがレジストリから削除してくれない情報を手動で削除しただけでこの現象は収まりました。

こんなふうに開発者でもないのにイジくるようなことをする人はほどんどおられないと思いますが、TvRockをもてあそんでいて、BSODを見せないということを知ってびっくりして思わずこんな記事を書いてしまいました(TvRockがきっかけであって、TvRockが悪いとかどうとかではないことはここで闡明しておきます。まあ、このblogでしょっちゅう記述していることの繰り返しなんですけどね)。

誰の役に立つかわかりませんが、TvRockには2019年問題もありますので、入れ替え作業などでもしもこんなトラブルが発生するかもしれません。
もしかしたらどなた様かに役立つこともあるかもしれないと思い、記録しておく次第です。