どういった調査方法があるのか、教えて頂きたいです。
2000~3000ユーザーを抱えていらっしゃる手練にひけらかすことかと恐縮しますが、検死と再現の両面から調べるのが基本です。さらに最後の手段は「再現待ち」ですね。順を追って詳細化しましょう。
検死は、異常終了時のテキストログおよびメモリダンプから原因を調査するものです。
再現は、検死によって得られた原因の可能性から、自前で用意した環境で予想した条件を整えて複数回試行して再度事象を発生せさることです。これは不具合修正後のテストでも必須の環境ですね。
最後の手段の再現待ちは、不具合解決を目的とせず、何らかの情報取得を目的とした修正を行って顧客に提供します。最も悪いパターンとされているもので、ある程度の確信のある根拠が必要です。
その内の1ユーザー様で、多岐にわたるソフト強制終了が起きています。
ソフトの通常の動きの途中でも、ソフトが落ちている形跡がLogより見て取れます。
これはテキストのログでしょうか。もし顧客の環境のWindows設定の変更が可能であれば、異常終了時にメモリダンプを出力するように依頼できないでしょうか。
私はUNIXの経験が長かったため、メモリダンプを用いた調査は当たり前だったのですが、その後Windowsの仕事を行った際に、メモリダンプがあまり使われておらず、驚いた経験があります。
Windowsでは「WinDbg」にて「!analyze -v」などを用いる方法ですね。職人技が必要です。(今は別の方法があるのでしょうか?)まずはトレースバックを見て、直近でダウンしているフレームがどこの関数であるか調査しましょう。(当然、コールスタックがどのようにOSで管理されているか知っていなればいけません)変数の内容も見ていきましょう。マルチスレッドの場合は原因となるスレッドを探します。
最後に、考えられる可能性としまして・・・
- ソフトの発生条件が厳しい不具合
- OSの不具合(HP-UXで実際にありました。即対応は望めなかったので別の関数で実装しました)
- 顧客がインストールした何らかの拡張モジュール
でしょうか。
PCに接続しているハードや、PCそのものの交換も試しましたが、未だに解決できておりません。(そもそも原因を調査せずに進めているのが不味いですが・・・)
根拠もなく顧客に出費および工数を伴う対策をさせ、挙句に問題を解決できなければ信用を失いますよ。
言いなりの顧客に対して手軽な対策であるのはわかりますが、真摯に対応しましょう。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2016/02/05 10:58