[FFXIV] 90002エラーを解消する。

 

こんにちは( ‘ω’)ノ
ここ4~5日の間、FFXIVにログインしていると突然接続が切断される、所謂90002エラーが頻発していました。
今までは普通にプレイできていたところに、突然の90002エラーだからそりゃあもう焦ったよね。
その90002エラーの原因と対策を検索したら、これがまぁ大量に出てくる出てくる。
今回はいろいろ対策を講じた内容を覚え書きの意味で書いてみようと思います。

 

まず最初に、90000番台のエラーは基本的にクライアント側の問題とされているようで、Loadstoneのサポートセンターのよくある質問/お問い合わせ「[Windows] プレイ中に通信が切断される」にも、ユーザー側が設定を見直すことで改善する場合があるとしています。
今回の極90002エラー討滅戦は、このリンク先の内容に書かれている設定を上から順に見直していきました。
見直しはたぶんこれで5回目くらいだけども…
[Windows]プレイ中に通信が切断される

 

症状

  1. 何もしていなくても落ちる。
  2. 戦闘中にモブや他プレイヤーが動かなくなり、自プレイヤーはスキル発動等行えるがダメージが通らなくなる。
  3. 生産中にスキルが発動しても加工や作業が進まなくなる。
  4. 3.の症状発生後に90002エラー落ち。
  5. 3.の症状発生後、10~15秒後に復帰する場合もあるが程なく90002エラー落ち。

 

接続環境

  • セキュリティソフト:ESET Smart Security 8.0
  • プロバイダ:OCN for VPN
  • 回線:フレッツ光ネクスト ギガファミリースマートタイプ
  • 接続方法:有線LAN
  • モデム:NTTホームゲートウェイ PR-500MI(以下HGW)
  • ルータ・ハブの有無:なし(クライアントインストールのPCに関して)

 

見直した設定関連

通信機器の再起動

NTTの提唱する電源プラグをコンセントから抜いて、6分以上経過した後に通電。

 

通信機器のファームウェアの更新

新しい更新はなし。

 

セキュリティソフト/OSファイアーウォール機能の設定確認

ESET Smart Security 8.0 ウイルス・スパイウェア対策の除外設定。

 

ESET Smart Security 8.0 パーソナルファイアウォールのルールとゾーンの許可設定。

 

ライベートIPアドレスの固定。

 

Windows ファイアウォールのプログラム許可およびポート開放。

 

プロバイダのセキュリティサービスの確認

未加入のためなし。

 

スタートアップから常駐停止し、インストールを行なう

msconfigの「スタートアップの項目を読み込む」のチェックを外し、FFXIVクライアントを再インストール。
NVIDIAドライバの異常も見られたので、こちらも再度クリーンインストール。

 

ルーターなどを外す

クライアントインストールのPCはLANハブを介してないので関係なし。

 

ルーターの設定を確認する

SPI設定でTCPタイムアウトを7200秒に設定。

 

HGWでポート54992~54994,55006~55007,55021~55040を開放。
このHGWはポート開放の範囲指定ができなくてめんどくさい…

 

ここまでが公式が提唱してる対策だけど、結果は何も変わりませんでした…。

 

別の原因を探る

他にも90002エラーについて何か有益な情報がないかと、ぐぐってる最中にブラウザの読み込みが異常に遅くなり、時には真っ白な画面になってしまうことに気づき、LANケーブルの劣化を疑い新品に交換してみたが、何も変化はなかった…o…rz

 

これもしかして回線の障害なんじゃね?(゚Д゚)ガタッ

 

ということで、NTTの故障受付113番へ回線の障害状況の確認をしましたが、そういった報告は来てないのでHGWの故障かも知れないと交換を勧められたので、そのまま交換の手続きを進めました。
NTTで障害がないならプロバイダ(以下ISP)かってことで、ISPのテクニカルサポートへ電話して障害状況の有無を確認するも、こちらも障害の報告はないとのこと。

 

弱ったなー…( ´・ω・)y─~~

 

テクニカルサポートの担当さん「こちらからping60回くらい送ってみたんですが、要求タイムアウトですね…。お客様の方はどうでしょうか?」

 

あ、ちょっと叩いてみますね( ‘ω’)

 

クライアントインストールのPCからHGWに向けてpingを叩いてみる。

C:\Users\Users>ping 192.168.○.○ -n 10

192.168.○.○ に ping を送信しています 32 バイトのデータ:
192.168.○.○ からの応答: バイト数 =32 時間 <1ms TTL=64
192.168.○.○ からの応答: バイト数 =32 時間 =1ms TTL=64
192.168.○.○ からの応答: バイト数 =32 時間 <1ms TTL=64
192.168.○.○ からの応答: バイト数 =32 時間 <1ms TTL=64
192.168.○.○ からの応答: バイト数 =32 時間 <1ms TTL=64
192.168.○.○ からの応答: バイト数 =32 時間 <1ms TTL=64
192.168.○.○ からの応答: バイト数 =32 時間 <1ms TTL=64
192.168.○.○ からの応答: バイト数 =32 時間 =1ms TTL=64
192.168.○.○ からの応答: バイト数 =32 時間 <1ms TTL=64
192.168.○.○ からの応答: バイト数 =32 時間 <1ms TTL=64

192.168.○.○ の ping 統計:
パケット数: 送信 = 10、受信 = 10、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
最小 = 0ms、最大 = 1ms、平均 = 0ms

 

次にグローバルipにpingを叩いてみる。

C:\Users\Users>ping 8.8.8.8 -n 10

8.8.8.8 に ping を送信しています 32 バイトのデータ:
8.8.8.8 からの応答: バイト数 =32 時間 =7ms TTL=52
8.8.8.8 からの応答: バイト数 =32 時間 =5ms TTL=52
8.8.8.8 からの応答: バイト数 =32 時間 =6ms TTL=52
8.8.8.8 からの応答: バイト数 =32 時間 =106ms TTL=52
8.8.8.8 からの応答: バイト数 =32 時間 =6ms TTL=52
8.8.8.8 からの応答: バイト数 =32 時間 =12ms TTL=52
8.8.8.8 からの応答: バイト数 =32 時間 =6ms TTL=52
8.8.8.8 からの応答: バイト数 =32 時間 =6ms TTL=52
8.8.8.8 からの応答: バイト数 =32 時間 =6ms TTL=52
8.8.8.8 からの応答: バイト数 =32 時間 =6ms TTL=52

8.8.8.8 の ping 統計:
パケット数: 送信 = 10、受信 = 10、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
最小 = 5ms、最大 = 106ms、平均 = 16ms

 

これは明らかにおかしい!!

 

テクニカルサポートの担当さん「HGW………ですかねぇ………」

 

さっきNTTに交換の手続きしたんで、交換してからもっかい試してみますね…(´・ω・`)

 

と、電話を切ってからあることに気づく。

 

まてよ?( ‘ω’)

 

PCからHGWまでは異常がない。

 

NTTやISPに障害の報告は入ってないと言う。

 

そういえば5号機の方はDirectX11の件とNDIDIAドライバの応答停止と回復を除けば、ネットワークが安定していてFFXIVができる。

 

ネットワークがおかしいのは3号機だけ…。

 

これHGWがおかしいって訳じゃないな。

 

もしかして…

 

ネットワークアダプタのドライバに問題があるんじゃね?

 

ということで、デバイスマネージャからIntel(R) Ethernet Connection (2) I218-Vを削除して…

 

M/Bのサポートディスクからドライバを再インストールしてみました。

 

再度pingを叩いてみる。

C:\Users\Users>ping 8.8.8.8 -n 10

8.8.8.8 に ping を送信しています 32 バイトのデータ:
8.8.8.8 からの応答: バイト数 =32 時間 =7ms TTL=54
8.8.8.8 からの応答: バイト数 =32 時間 =8ms TTL=54
8.8.8.8 からの応答: バイト数 =32 時間 =7ms TTL=54
8.8.8.8 からの応答: バイト数 =32 時間 =6ms TTL=54
8.8.8.8 からの応答: バイト数 =32 時間 =6ms TTL=54
8.8.8.8 からの応答: バイト数 =32 時間 =5ms TTL=54
8.8.8.8 からの応答: バイト数 =32 時間 =6ms TTL=54
8.8.8.8 からの応答: バイト数 =32 時間 =5ms TTL=54
8
.8.8.8 からの応答: バイト数 =32 時間 =5ms TTL=54
8.8.8.8 からの応答: バイト数 =32 時間 =5ms TTL=54

192.168.○.○ の ping 統計:
パケット数: 送信 = 10、受信 = 10、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
最小 = 5ms、最大 = 8ms、平均 = 6ms

 

お!?

 

確認のため別の所にもpingを叩いてみる。

C:\Users\Users>ping www.ocn.ne.jp -n 10

www.ocn.ne.jp [153.254.147.205]に ping を送信しています 32 バイトのデータ:
153.254.147.205 からの応答: バイト数 =32 時間 =20ms TTL=238
153.254.147.205 からの応答: バイト数 =32 時間 =15ms TTL=238
153.254.147.205 からの応答: バイト数 =32 時間 =15ms TTL=238
153.254.147.205 からの応答: バイト数 =32 時間 =15ms TTL=238
153.254.147.205 からの応答: バイト数 =32 時間 =14ms TTL=238
153.254.147.205 からの応答: バイト数 =32 時間 =14ms TTL=238
153.254.147.205 からの応答: バイト数 =32 時間 =15ms TTL=238
153.254.147.205 からの応答: バイト数 =32 時間 =16ms TTL=238
153.254.147.205 からの応答: バイト数 =32 時間 =14ms TTL=238
153.254.147.205 からの応答: バイト数 =32 時間 =16ms TTL=238

153.254.147.205 の ping 統計:
パケット数: 送信 = 10、受信 = 10、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
最小 = 14ms、最大 = 20ms、平均 = 15ms

 

おおお!?!?

 

更にマンドラゴラサーバーのIPへpingを叩いてみる。

C:\Users\Users>ping 124.150.157.54 -n 10

124.150.157.54 に ping を送信しています 32 バイトのデータ:
124.150.157.54 からの応答: バイト数 =32 時間 =10ms TTL=241
124.150.157.54 からの応答: バイト数 =32 時間 =7ms TTL=241
124.150.157.54 からの応答: バイト数 =32 時間 =7ms TTL=241
124.150.157.54 からの応答: バイト数 =32 時間 =7ms TTL=241
124.150.157.54 からの応答: バイト数 =32 時間 =9ms TTL=241
124.150.157.54 からの応答: バイト数 =32 時間 =8ms TTL=241
124.150.157.54 からの応答: バイト数 =32 時間 =7ms TTL=241
124.150.157.54 からの応答: バイト数 =32 時間 =8ms TTL=241
124.150.157.54 からの応答: バイト数 =32 時間 =8ms TTL=241
124.150.157.54 からの応答: バイト数 =32 時間 =10ms TTL=241

124.150.157.54 の ping 統計:
パケット数: 送信 = 10、受信 = 10、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
最小 = 7ms、最大 = 10ms、平均 = 8ms

 

これもしかして直ったんじゃね?

 

FFXIVへログインして確認してみる。

生産で作業や加工は普通に進むようになり、アレキN4層でも他プレイヤーやモブが軽快に動き、ダメージもバッチリ通ります。

 

心なしか画質も良くなった気がする。(気のせい

 

これで散々悩まされた90002エラー討滅戦に勝利した٩(ˊᗜˋ*)و
テテテーテーテーテッテテー♪

 

原因特定の一因として

まずは公式提唱の「[Windows] プレイ中に通信が切断される」に記載されている対策を一つづつひと通り講じてみましょう。
それでも解決しない場合は、自身のネットワーク環境を疑ってpingを叩いてみましょう。
そこでpingの応答時間におかしな点が見つかったなら、ネットワークコネクションを再インストールするだけで、もしかしたら簡単に解決するかも知れません。
[Windows]プレイ中に通信が切断される

 

ではまた(=゚ω゚)ノシ

コメント

  1. Anonymous says:

    とても詳しい!

    • 管理人 says:

      コメントありがとうございます。
      今回の90002はネットワークアダプタのドライバに原因があった訳ですが、必ずしも記事に記載した対策で解決できるとは限りません。
      90002が発生しないことに越したことはないのですが、また何か発生するようならもうちょっと掘り下げて、いろんな症例から解決する術を記事にできれば良いなーと思います。

タイトルとURLをコピーしました