3年半前に試乗車(走行距離不明)を3割引で購入。
3年半経過して、6万キロ走っていたの間違いでは？

microsoft.comのサブドメインは簡単には作れないし消せないのかも。
まだ正式版ではないので、URLやらドメインは暫定版じゃないかな。
trafficmanager.netとか、cloudapp.netみたいな一見非MSドメインじゃないだけマシと思いましょう。
一体いくつドメインを持っているのやら。

接続性チェックも専用ドメイン＆URL用意してたりしますし。
http://www.msftncsi.com/ncsi.txt
http://www.msftconnecttest.com/connecttest.txt
接続性チェックはフリーWi-Fiとかで嘘のIPアドレスが一時的に帰ってくる対策で分ける意味は有りますが。

忘れ去られてるみたいですが、IE8時代から現行Edgeに至るまで互換リストを作って配布してます。
※IE8は修正プログラム(Internet Explorer 8 の互換表示一覧用の更新プログラム)として配信
なので実は今までもやっていました。

目新しいのはリストの配布ドメインがcvlist.ie.microsoft.comのようなmicrosoft.comではなく、config.skype.comというskype.com下になっている事。
リストの形式がXMLでなくJSONに変わった事ですかね。

応答なしでタイムアウトからの強制終了コンボでなければ、メモリ破壊とかしてそうでいやな落ち方ですね。
自分だったら、Windowsのイベントログに痕跡が残ってないか確認してみますね。

Application.ScreenUpdating = False/True
してるか、
後は適時、DoEvents挟んで本来の処理を回すと変化があるか確認してみる。
VB6由来でwithとか使っていて、end with前にexit for/subとかで抜けるとスタック破壊からの落ちる系の既知バグが有った気がします。

無駄かもしれませんが、ツール＞オプション、全般タブの「エラートラップ」を「エラー発生時に中断」とかでトラップしないかチャレンジしてみるとか。

温素材≠ホットでございます。
暇ならプレスリリースでも。

非力＆ガス寿命(燃費)が心配ですが、カセットコンロのヒーターだとペルチェによるファンヒーターは市販されてます。
http://www.i-cg.jp/product/stove/cb-gfh-2/
まぁ、燃費がよろしくないのとFF式じゃないので高気密住宅じゃダメでしょうけど。

FAXでも停電時は局給電でビープスピーカーによる着信と発信等が可能な物が有ります。
ただし、ナンバーディスプレイ契約をしていると交換機からナンバーディスプレイ用のデータを送信するために鳴動が非契約時と異なります。
非常用電話機が局給電時はナンバーディスプレイ非対応(大半がそうだと思います)だと、ナンバーディスプレイデータ受信中に着呼したと思って受話器を上げると呼損する事も有るので一言添えた方が良いかと思います。
リハーサルで実際に試してあるなら大丈夫だとは思いますが。

タケモトピアノのCMは泣き止むことで有名です。
http://www.takemotopiano.com/cm.html

ボタン電池は両極が隣接していて、容易に短絡するので結構危険ですよね。
同じ理由で006Pとかも。

電池交換しようと、機器の上に正極を上向きで一時置きしたのですが、
実は機器の微妙な凹凸でショートしていた事に気づかず、電池が破裂して空を飛んでった幼少の頃の思い出。

そんな記憶があるので、絶縁せずに電池を捨てるのはテロ行為かなと。
ボタン電池回収ボックスに「テープで絶縁しろ」と書いて有るはずなので。

高橋メソッド使いかもしれない。

実は目新しくない人間(エンドユーザーや開発者)に対するソーシャルハックなんですよ。
OSSに限らずイソジンやら、イソジンのコメントにもある味覇と創味シャンタンDXみたいな例も有ります。
プロプラでは、流石にトロイ的な事はあまりないですが、次バージョンでゴミ化とかEOSになったりとか有りますし。
# 燃費やら検査データ改ざんみたいな例とかも有りますけど。

閑話休題。
自動更新によって突如マルウェア化する人気Chrome拡張とか色々前例は有ったり。
使用者が外部依存しているリソースのチェックを怠り続ける限り今後も何処かで起きるでしょうね。
最近有った事例だと、StatCounterみたいな話題にならなかった物も含め。

とはいえ、Web界隈はシステムの複雑化と開発速度優先により、容易に外部ライブラリを使用し、
その外部ライブラリも別の外部ライブラリを呼び、人間が管理しきれなくなり、
言語ではなく、ロジックが理解しきれない事によるバベルの塔崩壊前夜な感じにも見えます。

たしかに管理者が変わったのに、パッケージ名という名前空間でしか管理していないために、
ブランドに対する信用をそのまま機械的に引き継げてしまうシステムが問題を大きくする要因の一つでしょう。
しかし、悪意あるオデュッセウスが見つかっていないだけという可能性だってあります。
究極的には対処法は外部リソースは基本的に信じず、信頼できる方法で確認し続ける事が必要なのでしょう。
そして、それって最初に書いた通り、別にOSSに限った話ではないのですよね。
# で、誰がコストを負担するかで揉めたり、確認が追いつかずライブラリやランタイムのバージョンが古いままで地獄を見るのだ。