Open Live Writer をオープンできない．An unexpected error happened というメッセージパネルが出ている．スクリーンショットを取ってJPGで保存しておいたのだが，それを開くこともできない．パネルにはSend MessageとContinueという2つのボタンが付いているが，どちらも作動しない．時間が経つとこのパネルは消えるが，何度やってもOpen Live Writerを起動することはできない．
やむを得ず，もう一度本家サイトからダウンロードしてインストールした．問題はこれで一応解決したのだが，数日前からカスペルスキーでアプリ更新しようとして失敗するという状態が続いていたのと関係あるかもしれない※．アンインストールしないで再インストールしているので，設定などはすべて温存されていたようで，何も言わず黙ってこの画面が開いた．とりあえず，問題なく動作している，ようだ．
※これは勘違い．アップデートできなかったのはLibreOfficeだ．
検証テストの実行速度が極端に落ちている問題を解決しなくてはならない．状況はある程度までつかめたが，ある意味でいよいよわからなくなってきたという感じもある．これまでわかったことを整理しておこう．開発環境はVS2019のVBを用いている．
- 異変は「仮想木」を実装して動き始めた時期と重なっている．具体的には2月8日から9日のころで，障害はすでに8日の午後5時ころには発現しているが，それに気付くのはだいぶ時間が経ったあとで，その後も作業を継続していた．
- この時期にはすでに，仮想木の実装は一段落してコードの整理に着手していたので作業量が膨大かつ慎重を要するものであったため，8日だけでバックアップを5回，9日には3回バックアップしている．
- 9日にはフォルダ名やアセンブリ名をCollatz Milky Highwayに変更．
- 当初は，スタックオーバーフローに対処するために開発プロジェクトのポストイベントに組み込んだスタックサイズ変更のためのスクリプトに関係しているのではないかと推定，スタックを大量消費するA面のコラッツ木生成などには影響が出ていないため，この推因は放棄された．
- 正常動作している版のバックアップが2つある，一つは8日の午後2時に作ったBACKUP1と午後9時に作ったBACKUP4でそれ以外は全滅．
- BACKUP1に残っているリリース版のEXEは正常動作しているが，BACKUP1のコピーをリビルドして生成したEXEでは事象が発生する．
- BACKUP１のコピーをリビルドした版をREBUILD1とする．BACKUP1（のコピー）にREBULID1で生成されたモジュールを１個づつ移植して動作チェックしたところ，CollatzMilkyHighway.DLLが不良の原因であることが突き止められた．
- この２日間ではソースコードの各処に相当量の修正が入っているが，EXEのサイズは一貫して202,752バイトでまったく変化していない．
- WinMergeのバイナリファイル比較検査を通してみると，これらのEXEには数バイト～の相違点があるが，それらを除けばほとんど同一
- バックアップをリビルドして生成したCollatzMilkyHighway.DLLのサイズはBACKUP0では218,624で正常動作するDLLと一致しているが，BACKUP1では異なる値217,600になる．このDLLでは事象が発生する．
これらのことから推定されることは，①.NET 5.0ではマネージドコードのみを含むモジュールをEXEとして生成し，それ以外の部分はDLLに吐き出しているものと考えられる．これは効率を最優先するというポリシーによるものと考えられるが，これにより，EXEを見ていただけでは開発状況を把握できないという事態になっている．②EXEのサイズが不変なのでウィルス検査ルーチンはこのようなプログラムの改変を検出できない可能性がある．VBのソースコードである*.VBとEXEのコードは一対一対応しているというのはまったくの思い込みであり，実際には複数のDLLに分散配置されている．
問題はこのような事態にどう対処すればよいのか？ないしどう対処可能か？という点にある．BACKUP0をリビルドした版では正常動作するDLLと同サイズのDLLが生成されているので，まずこれが動作可能かどうかをチェックしてみよう．
ここまでをアップロードしようとして，以下のエラーになった．
どうもこのフロントエンド機は恒常的なディスク領域不足状態に陥っている模様だ．プログラムはCドライブに置くしかないので，外部ドライブに移動できるものは限られている．デスクトップ，ドキュメント，ピクチャなどをすべて空にしたが，空き領域はゼロのままだ…一度リブートしてみよう．⇒アップロードは失敗に終わったが，リブートしてここまでの記事は残っていた．Cドライブの空き領域は1.26GBにはなったが，赤い状態だ．もう少し拡げておかないと安定した作業はできない．しかし，もう削れるものはすべて削ってしまった．
どうすればよいか？あとできることは一時ファイルの削除くらいしかない．⇒全部削っても17.9MBしかない．ウィンドウズの更新プログラムのバックアップが削除できると多少は効果があるのだが…逆に累積更新プログラムのダウンロード中になってしまった．かなり無理なところまで削ったが，1.29GBまでだ．このマシンは何度もメーカーに出しているが，HDDもメモリも増設不可ということで対処できなかった．その代わりにSDカード256GBを使っているが，それも満杯になっている．
現在正常動作することが確認されているのは，BACKUP1に含まれるサイス218,264のCollatzMilkyHighway.DLLとサイズ202,752のCollatzMilkyHighway.EXEの組み合わせだけだ．しかし，リビルドして同サイズのDLLとEXEを生成するREBUILD0では症状が出てしまう．これはBACKUP1とREBUILD0に含まれるモジュールに差異があることを意味する．どこが違うのかチェックしてみよう．
- BouncyCastle.Crypto.dll 3,318,504 3,318,504 ○
- CollatzMilkyHighway.deps.json 3,669 3,669 ○
- CollatzMilkyHighway.dll 218,624 218,624 ○
- CollatzMilkyHighway.exe 202,752 202,752 ○
- CollatzMilkyHighway.pdb 26,928 26,664 ○
- CollatzMilkyHighway.runtimeconfig.dev.json 385 385 ○
- CollatzMilkyHighway.rutimeconfig.json 260 154
- Mailkit.dll 859,136 859,136 ○
- Mimekit.dll 1,155,584 1,155,584 ○
サイズで比較すると差異があるのは，rutimeconfig.jsonだけということになる．これを差し替えて動作を見てみよう．⇒変化しない．⇒やはり，原因はCollatzMilkyHighway.dll にあるようだ．WinMergeで比較するとほとんど一致するところがないくらい違うという感じだ．しかし，逆アセンブリで見ると差異はそれほど大きくはないようにも見えなくはない．むしろ，前後のブロックの配置が変化しているのではないか？確かに，ロジックを整理するために前後関係を入れ替えたりなどのことをしていたかもしれない．もっとも肝心な点は正常動作しているときのソースコードを確定することだ．いまのところリビルドして正常動作するバージョンは見つかっていない．
いや，もしかすると手順を間違えているかもしれない．BUILD0は動作しているようだ．もう一度作り直してみよう．⇒いや，やはりできていない．スタックサイズが違う．DLLのスタックサイズは設定していないのだが，合わせてみた．⇒結果は同じだ．というか，BUILD0としているのは実際にはBUILD4のあとなのではないか？BACKUP1の直前はCollatzProject 2022-02-07-1なのではないだろうか？まず，先に2022-02-08-1をもう一度リビルドしてみよう．
ようやく，リビルドで高速動作する版を見つけた．CollatzProject 2022-02-07だ．この一つあとの2022-02-07-1では実行時にエラーが発生してしまうため，テストできない．ともかく，ここまで戻って何が実行速度に影響しているのかを確認しなくてはならない．2022-02-07-1はエラーが出るので，2022-02-07と2022-02-08-1を比較することにしよう．⇒無数と言ってよいくらいの差異があるが，本質的な点がどこにあるのか探る必要がある．
- MAXDUMPTEXT 4096 ← 2048
- Truncate Truncate ← Trancate
- CutTextBuffer 新設
- RichTextのスクロールを抑制
- EnabelDisable関数 新設
- Hideボタン 新設
- 枝番号リストチェック チェックの場合はループ内で転記する
検証テストに関わる部分に限定すれば，時間に影響しそうなところと言えば枝番号リストの転記だけのように思われる．⇒確かにそのようだ．これで最新版まで戻ることができる．⇒動いた．以前は3秒で完了していたところ，11秒かかっているが，まぁ妥当なところだろう．これで難題は解決した．一旦バックアップを取って次に掛かることにしよう．もうほとんど出荷できるレベルに達している．あとはブラッシュアップするだけだ．一度ログを読み直しておこう．
枝番号リストを更新するような変更が入ったのは，巨大数のコラッツ数列を求めるとき，枝番号リストが処理終了まで空白になってしまうのを避けるためだ．検証テストのときに更新するのは時間のムダだが，コラッツ数列のときはむしろ表示した方がよいと思う．
▲GetTheSequenceでダンプを止めていると画面がフリーズして何も変化しない状態になる．これはTree heightを更新していないためで，最大数から下降しているため，数字が変化しない．このため，開始も終了もわからないような状態になっている．最大高を与える番号は確定しているが，高さは変化するようにした方がよい．仮想木では現在もそうなっている．⇒対処した．
▲一般木でMax degreeを与えるノード番号がかなりおかしい．これはおそらく個別検査時に更新しているためと思われる．検証テスト中はUpdate以外での更新は認められない．⇒戻るところを間違えていた．もう一つ新しいバージョンがある．やり直しだ．CollatzMilkyway 2022-02-09と2022-02-09 BADがあるが，後者は捨ててもよいだろう．
▲どこかやりそこなったのだろうか？ValidNumberとWXの不一致が発生して停止する．⇒WXをローカル変数に変えているためだ．この値はグローバルでなくてはならない．⇒再帰関数の呼び出して参照渡しするようにした．
現在の実装では枝数と高さはUlongで取っているが，さすがに大き過ぎるのではないか？マニュアルではInt16<=32767としているのだが，この辺りが妥当な線なのではないだろうか？実際問題として，最大枝数が8桁にもなると，べき乗の計算ですら抜けてこなくなってしまう．⇒Int16では少し小さ過ぎるような気がする．枝数列をInt16範囲内い抑えても，中間の計算でオーバーフローしてしまう．CountValidPostでInt16を超えているようだ．⇒Uintに変更した．設定はInt16のままとする．
▲A面では検定中に仮想木モードに切り替えができてしまう．⇒B面と同じようにアクセス不可としておくのがよいのではないか？それが一番簡単だ．
▲GoボタンがStopに切り替わらない．⇒動作しているが，応答が遅れているため入らないように見えている．⇒仮想木モードでは停止しないかもしれない．
▲一般木で樹高800を設定してスタックオーバーフローが発生する．少し早過ぎるような気がするのだが…高さ425で発生している．⇒CollatzTreeStructureで使っているローカル変数をグローバルに戻したが，効果なし．以前はheight=11111でオーバーフローしているので，800というのはまったくの番外だ．いや，開発環境では同レベルで発生していたようだ．あ，なるほどわかった．デバッグモードではスタックサイズの変更を実施していない．⇒マクロでDebugを指定することはできるが，実行されていないだけでなく，その文字列自体消去されてしまう．固定した文字列しか受け付けていないようだ．まぁ，この件に関してはこれで仕方ないものとしておくことにする．
▲DとHをそれぞれ最大値の32767に設定して走らせて，計算は進んではいるが，表示がまったく更新されない．これは，そのノードの現物を処理するまでは表示を更新していないためだが，子ノードを出力した時点で更新するようにした方がよい．H=3267ではボトムに達するまで何も表示が更新されない状態が続いてしまう．D=32767,H=1でも同じだ．有効ノードが1に変わる以外何の変化もない．