お正月休み真っ只中の今日、
いつものExcelを開いて作業しようとしたら、
突然Excelが落ちるようになった。
何度開いても同じようにすぐ落ちてしまう。
なんてことだ。
症状は以下のようだ。
- Excelは2010
- ファイル依存ではない。（どのファイルを開いても落ちる）
- セーフモードでExcelを起動しても落ちる。
そこで、Windowsログの内容を確認。
以下のようなログが出力されていた。
|
|
障害が発生しているアプリケーション名: EXCEL.EXE、バージョン: 14.0.7227.5000、タイム スタンプ: 0x5c180d62 障害が発生しているモジュール名: ntdll.dll、バージョン: 10.0.17763.194、タイム スタンプ: 0xd9f605a2 例外コード: 0xc0000005 障害オフセット: 0x00056f37 障害が発生しているプロセス ID: 0x23fc 障害が発生しているアプリケーションの開始時刻: 0x01d4a4fc1006214c 障害が発生しているアプリケーション パス: C:\Program Files\Microsoft Office\Office14\EXCEL.EXE 障害が発生しているモジュール パス: C:\WINDOWS\SYSTEM32\ntdll.dll レポート ID: 35bab542-4ca3-4612-9530-8cd49a10e07e 障害が発生しているパッケージの完全な名前: 障害が発生しているパッケージに関連するアプリケーション ID: |
どうやらntdll.dllというモジュールが悪さしているみたい。
ntdll.dllとか、例外コードの「0xc0000005」でググってみても、
なかなか解決策が見当たらない。
以下のMicrosoftの公式に書いてある項目をみてみると、
https://support.microsoft.com/ja-jp/help/2758592/how-to-troubleshoot-crashing-and-not-responding-issues-with-excel
最終的にはWindowsアップデートということだったので、
実施することとした。
そしていざWindowsアップデートを開始すると、
以下のようなメッセージが出力。
なんてことだ（本日２回目）
VirtualBoxは私が仕事の環境を自宅で模擬して勉強するために
昔一生懸命構築したものだ。
たしかに最近はあまり起動していないので、
なくても困らないのだが、
たいていこういうのは消したときに限って、
すぐ使いたくなるものである。
どうしようか。
と思っていたら、VirtualBoxの新しいバージョンがあるとのことなので、
そちらにアップデートをしてからWindowsアップデートをしてみることに。
そしたらWindowsアップデートは開始された。
その後再起動されてもう一度Excelを起動してみると、
少し症状が変わった。
たしかにntdll.dllで、例外コードの「0xc0000005」でエラーが出るが、
特定のファイルのみで発生するようになった。なんだこれ。。。
そのファイルは、googleのスプレッドシートをExcelに変換したものである。
とりあえず、このファイルが見れないだけだったら
影響は少ないので、このまま進めることとした。
解決になっていないので、また解決したら書く。
【2019/01/19 追記】
原因はExcelの更新プログラム（19/01/02にリリースされたKB4461627）に不具合があったためでした。
（コメントで教えていただきました。）
5月に予定されている改元変更に備えたアップデートがバグっていたようです。
下記の更新プログラムをアンインストールすることで治りました。
「Update for Microsoft Excel 2010 (KB4461627) 32-Bit-Edition」
アンインストールの仕方はコメント欄を参照願います。
地味にコントロールパネルをどこから開くか迷いましたが、
「スタート」⇒「Windowsシステムツール」
にありました。そしてアイコンを小で表示すると、
プログラムと機能が見つかると思います。
とりあえずよかった。
最近、東京駅に通勤で通う場合、
どこに住むのがベストかをずっと考えていた。
人それぞれ何を重視するかによって、
住む場所も変わってくるが、
私の重視するものは以下だとわかってきた。
通勤時間 ：★★★☆☆
駅前の賑わい ：★★★★★
治安の良さ ：★★★★☆
家賃の安さ ：★★★☆☆
電車の込み具合：★★☆☆☆
とにかく賑わっている駅に住みたい。
家から徒歩圏内に全部そろっているところに住みたい。
でもただ賑わっているだけではなく、治安の良さも欲しい。
飲み屋街でがやがやしていて、うるさい、汚い、怖い
みたいなところではなくて、気品のある場所がいい。
カフェや図書館でゆっくりできたり、
おしゃれな商店街があったり。
会社帰りによれる飲み屋があるとなおよい。
そんな条件でいろいろ探していたところ、
中央線沿いの中野、高円寺、阿佐ヶ谷、荻窪、西荻窪、吉祥寺が候補となってきた。
これらの駅はどの駅も特徴があって、
どの駅に住んでも快適な生活が過ごせそうである。
住みやすさランキングを見ても、
上位の駅は常に上位に名を連ねている。
なるほど、なるほど。
これは住んでみて、自分自身で住みやすさを体感するしかない。
ということで、中央線沿いの中野、高円寺、阿佐ヶ谷、荻窪、西荻窪、吉祥寺の
いずれかに住むことにする。
自分の直感を信じてみる。
快適な東京生活が見えてきた！！
東京へ出向を言い渡されて、真っ先に気になるのが、電車の混雑率である。
東京の満員電車はヤバい、ヤバすぎるという声をよく聞くので、
無意識のうちに恐怖を植え付けられているのだが、
実際にどれくらい満員電車がすごいのか、
満員電車じゃない電車もあるのか、
東京に住んでいない人にとっては、まったく見当がつかない。
そこで、ネット上で得られる情報から、
東京の満員電車のすごさを調べてみることにした。
満員電車の定義
まず、満員電車とはどのような状態なのか。
国土交通省が下記のようなわかりやすい絵を作成している。
三大都市圏の主要区間の平均混雑率の推移（国土交通省鉄道局都市鉄道政策課）
名古屋の満員電車は、通常時では150％ほど、
遅延などで遅れているときで180％くらいだろうか。
東京のイメージは常時200％のイメージがあるが、
実際のところはどうなのだろうか。
【最新】2017年度版 東京 電車 混雑率ランキング
これまた国土交通省鉄道局都市鉄道政策課が、
2018年の7月17日に「平成29年度の混雑率データ」
つまり去年一年間の混雑率をデータ化してくれている。
東京圏で混雑率１８０％超の路線が１２路線から１１路線へ ～都市鉄道の混雑率調査結果を公表します～
これによると、混雑率180％越の路線が11路線も存在するとのこと！
しかもこの混雑率は、最混雑時間帯の1時間の平均なので、
実際には200％を超えているときもあるということ。
さすが東京の満員電車である。
- 東京地下鉄東西線：１９９％
- ＪＲ東日本総武緩行線：１９７％
- ＪＲ東日本横須賀線：１９６％
- ＪＲ東日本南武線：１８９％
- ＪＲ東日本東海道線：１８７％
６、 東京都日暮里舎人ライナｰ：１８７％
７、 ＪＲ東日本京浜東北線：１８６％
８、 ＪＲ東日本埼京線：１８５％
９、 東急田園都市線：１８５％
１０、ＪＲ東日本中央快速線：１８４％
１１、ＪＲ東日本総武快速線：１８１％
地図屋といえば可視化
しかしである。東京になじみのない私としては、
上記のデータを見ても、実際にどの辺を走っている電車なのか、
さっぱりわからないのである。
そこで、地図屋としては、このようなデータを入手したら、
地図上に可視化をして、わかりやすく見えるようにしたいのである。
背景にラスタ地図を表示して、路線をベクトル地図として重ね合わせることをしたい。
このようなときに便利なのが、みんな大好きLeafletである。
Leaflet.js
LeafletはWeb地図のためのJavaScriptライブラリである。
オープンソースでライセンスはBSD-2-Clauseで非常に使いやすいのである。
Leafletに関する導入記事は山ほどあるので、他のサイトに任せるとして、
今回は自分で路線情報を描画するために、Leaflet.Drowプラグインを使用することにした。
Leaflet.Drawプラグイン
これを導入すると、ほぼコーディングなしで、
リッチなお絵かきツールが作成できてしまうという優れものである。
こちらを導入すると、Leafletのマップ上にこのようなアイコンが表示される。
こちらで上から、ポリライン、ポリゴン、矩形、円、マーカー、点を作図することができる。
さらにすごいのが、一度入力したオブジェクトを編集することもできるのだ。
編集ボタンを押すと、オブジェクトの各補間点をピックすることができるようになり、
補間点ごとに移動することができるのだ。
また、補間点の追加と削除もできてしまう。
なんと便利な！！
混雑率の高い路線の可視化
ということで、Leaflet.Drowを利用して、東京の電車の混雑率の高い路線が
どこを通っているのかを可視化してみた。
それが以下である。
東京の電車に詳しくないため、
路線の絵が間違っている場合は指摘をお願いします。
これを見るとどうだろうか。。。
東京へ行くにはどこから行っても混んでいる
ということがおわかりいただけただろうか。
横浜方面から行っても、埼玉方面から行っても、千葉方面から行っても。。。
主要区間の混雑率の可視化
先ほどの結果では、路線をすべて同じ重みで描画しているので、
実際に１９９％となっている区間がどこかわかりづらい。
そこで、これもまた国土交通省鉄道局都市鉄道政策課のデータで、
「三大都市圏の主要区間の混雑率」という、
路線ではなく区間で表現したデータがあるので、
こちらも地図上に可視化してみる。
三大都市圏の主要区間の混雑率
先ほどの11路線に限定し、上記の資料に記載の区間を太く描画する。
その結果が以下である。
実際にパーセントの値が算出された調査対象の区間が上記の区間ということになる。
この部分を通過する際は注意ということだ。
しかし、ここで一つ疑問が残る。
なぜ国土交通省はこの区間を調査したのだろうか。
もう少し東京駅寄りの区間を調査してもいいと思うのだが、
東京駅寄りは混んでいるのが当たり前だから調査していないのか？
それともあまり混んでいないのか。
この辺りは実際に電車に乗っている人でないとわからない。
とりあえず今回の調査で、
東京へ向かう電車はどれも満員電車で混んでいるという残念なことが判明したため、
私が満員電車から逃れることはできないということが分かった。
だとすれば、家選びの基準として、
電車の込み具合は捨てて、駅から近いとか、
治安がよいとか、お店がそろっているとか、
そっち方面を重視していこうかと思う。
どこに住むか決めたらまた連絡しようと思う。
瞬間英作文や文法のトレーニングをしつつ、
少しでも知っている単語を増やしていかねばと思い、
単語を覚え中。。。
しかし、なかなか覚えられない。。。
個人的に覚えにくい単語をメモ
- express：表現する
- 新幹線のexpressカードを思い出してしまって、表現するにたどり着けない。。。
- deal：対処する
- waste：浪費する
- feed：えさを与える
- regard：～とみなす
- aim：努力する
- suffer：苦しむ
TCPのサーバ側プログラムを改修する機会があった。
時々ではあるが、アプリケーション起動時に、サーバ側プログラムで
2分ほどの待ちが発生するとのこと。
TCPの知識はほとんどなかったため、この機会に勉強をした。
以下のサイトが分かりやすかった。
http://www.ne.jp/asahi/hishidama/home/tech/socket/tcp.html
このサイトは、以前JavaやScalaの学習をした際にもお世話になっている。
サイトの作者は相当熱心な勉強家であることがうかがえる。
技術者として尊敬している。
そちらに下記のように書かれている。
|
|
最初にクローズした（アクティブクローズ）側は、 最後に送ったACKが相手に届いたかどうかを確認することが出来ないので、 ネットワーク上に滞留した電文（ゴミ）が消えるまで待つ為の 再送待機（TIME_WAIT）状態になり、 一定時間（2～4分？OSによって異なる）経つとCLOSED状態になる。 |
たしかに今回サーバー側から先に切断しており、サーバー側がアクティブクローズ側になっている。
そしてサーバー側でnetstatコマンドで調べてみると、
利用しているポートがTIME_WAIT状態になっていた。
そしてその対策として、
|
|
また、アクティブクローズ側がSO_LINGERオプションで時間0をセットしている場合、 TIME_WAIT状態にならずにいきなりCLOSED状態になる。 このとき、（ライブラリによっては？）RSTを送信するみたいだ。 これにより相手にソケットがクローズされたことを知らせて 何も送ってこないようにして、待機状態を回避するんだろう。 もっとも、RSTが相手に届く保証も無ければ変な電文が送られてこない保証も無い訳で、 正しい手順では やはりTIME_WAIT状態になるべきだろう。 |
とのこと。
SO_LINGERオプションにより、強制的にclose状態にできるようだ。
だが、筆者も書いている通り、あまりよい方法とは言えないようだ。
以下のサイトなども、SO_LINGERオプションは推奨された方法ではなく、
本来あるべき姿は、クライアント側から切断するようなアーキテクチャにすることとのこと。
https://code.i-harness.com/ja/q/3954e9
ただ、すぐにでも解消したかったので、
今回は、とりあえずSO_LINGERオプションを使ってみることにした。
下記のサイトを参考に実装。
https://www.ibm.com/support/knowledgecenter/ja/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxbd00/setopt.htm
その際に、LINGERを以下のように設定した。
|
|
l.l_onoff = 1; l.l_linger = 0; |
SO_LINGERをONにして、タイムアウトを0にした。
その結果、確かにTIME_WAIT状態に遷移しなくなりました！！！！
副作用がないのか心配ですが、とりあえずSO_LINGERオプションをONにして
様子をみたいと思います。
