国土交通省 航空交通管理センターの「航空交通流管理システム」で5月10日，端末が操作不能に陥いるトラブルが発生した(（「前編」を参照)。それから2日後の12日，今度は「飛行情報管理システム(FDMS)」で処理が異常終了した。航空交通流管理システムと同じく，原因は今年2月に移行した新システムにプログラムのバグが存在したことである。
FDMSは，「飛行計画情報処理システム(FDP)」の後継システム。航空会社などから得た飛行計画情報を処理して，航空交通管制部(札幌，東京，福岡，沖縄の4拠点)に送信する機能を備える。FDPと同様にNECのACOSを利用したFDMSは，今年の2月12日に稼働開始した。
5月12日の午前11時47分，ある飛行計画の変更処理がFDMS上で異常終了。14分後の午後12時01分に復旧した。管制官は飛行計画情報を基に航空機の出発を許可するが，飛行計画は出発の20分前に航空交通管制部に送信される。短時間で復旧できたため，この異常終了による運航への大きな影響が避けられた。
FDMSの端末には，航空機ごとの出発時刻，経由，行き先などの飛行計画が示される。出発時刻などに変更がある場合は，端末側のプログラムで変更データを作成した後に，ACOSに送信し，ACOS側のプログラムで変更処理を行う。5月12日の午前11時47分，ある変更データが端末から送信されたが，「データが無い(Null)」状態だった。これを処理しようとしたACOS側のプログラムが異常終了した。
端末側で作成する変更データは，メッセージ部とそれに続くメッセージ長から成る。変更データを作成する編集バッファ上で，メッセージを格納するエリアは固定長である。もし格納したメッセージが短い場合は，その後ろをNullで埋める。問題となった変更データは，メッセージがかなり長かった。そのため，メッセージの格納エリアを超え，メッセージ長の格納エリアにまでNullを書き込んだ。その後，「編集バッファからデータを送信するプロセスで，メッセージ長がNullなために，メッセージ自体がNullで上書きされたようだ」(航空局 管制保安部 奥野明氏)。
このプログラムのバグは，書き込むメッセージの長さに上限が設定されていなかったこと。そのために，編集バッファ上のメッセージ部の格納エリアを超えてしまった。
該当プログラムは改修中である。同時に，「航空交通流管理システム」のトラブルと合わせて，似たような処理がないか，他のプログラムの仕様やコードを点検している。その対象は，2月に新システムに移行させたものだけでなく，「航空路レーダー情報処理システム(RDP)」「ターミナルレーダー情報処理システム(ARTS)」など，今回リニューアルしていないものまで広げた。これら航空管制システムを開発したベンダー各社，および国土交通省航空局の「システム開発評価・危機管理センター(SDECC)」が1カ月を目安に点検を実施，中間報告をまとめる計画である。
