• 締切済み

アプリケーションの強制終了の原因究明方法(デバッグ)に関して

問題のアプリケーションはVB6.0で開発されています。動作環境はwinXP SP2です。 自分で開発しているわけではないのですが、社内で使用しているソフトが最近頻繁に 強制終了するので原因を調べたいと思います。しかし、特定の操作でハングアップす るわけではなく、同じ操作をしても普通に動作することもあるし、エラーに再現性が 無くて困っています。 よく強制終了のときに「microsoftに送信しますか」とか出てくる奴なのですが、見て みると問題を起こした関数の入っているファイルの名前や、その命令のあるメモリの アドレスぐらいは出てきます。 しかし具合的に何の命令なのかはわからないし、VC++6.0のデバッガーでアセンブラ で見ても何のことやらさっぱりわかりません。 ネットで検索してWindbgなるものを入れてみたのですが、Minidumpフォルダにダンプ フィルがあるのかと思って探してみても見つからないし、少し行き詰っています。 具体的にエラーストップした命令周辺のコードやそのコードを含むモジュール名など、 もう少し突っ込んだ情報を見られる方法は無いものかと探しています。もちろん、 バッファーオーバーランのように、ストップ箇所=問題箇所とは限らないこともわか っています。 自分でソースコードを持っているわけではないので、コードまでは見られないのかも しれないし、自分で見る必要も無いのかもしれませんが、開発者に状況を伝えるため にもう少し問題箇所の特定につながる情報がほしいと思っています。デバッグの方法 について教えていただけますでしょうか。 よろしくお願いします。

みんなの回答

回答No.4

> (dc.7d0): Access violation - code c0000005 (first/second chance not available) > kernel32!MultiByteToWideChar+0x7e7: > 7c84bf3a 0fb60f movzx ecx,byte ptr [edi] ds:0023:06b56000=?? 内部的には、たぶんMultiByteToWideChar APIでエラーが起きていることは 間違いないと思うのですが、エラー自体はメモリアクセスを拒絶されたような エラーなので……何やってるんだろ? 単純にVBのソースが悪いとしたら、MultiByteToWideCharは内容的に StrConv(文字列,vbUnicode)っぽいので、StrConvを使っている辺りが 怪しいかもしれませんが、VBの命令使うだけなら、普通はそんな事起きないと 思いますしねぇ…… 外部コントロールやDLLでのエラーの可能性も十分に有り得る気がします。 正直、私にも それ以上のことは判りません(汗)。 ただの普通のVBプログラマでしか ないので……

subarist00
質問者

お礼

ご回答ありがとうございます。

  • ai-sapuri
  • ベストアンサー率37% (11/29)
回答No.3

質問者様が言うように、今回の意見は、該当していないように思います。 参考になるかわかりませんが、VB6で作られたソフトで、以前、Microsoft .NET Framework のアクセスに関するトラブル報告があったように思います。 よろしければ、この点をお聞きに成ると、知っている人が居るかもしれません。 質問に対し、質問で返しましたが、お役に立てれば幸いです。

subarist00
質問者

お礼

お付き合い有難うございました。並行でいろいろ調べていますが、SP2がらみでも、dllのレジスターがうまくいっていない場合でも、単なる本体コードのバグでも今回のような強制終了は起こりますから、見た目では区別がつきません。 .NetFramework がらみならそうだとわかるだけでもひとつ有用だと思います。改めて過去の例を漁ってみます。

回答No.2

保守契約等で、開発元に調べてもらうことが可能ならば、調べてもらったほうがいいでしょう。 落ちる状況がわかればベストですが、最低限「この処理をしたら落ちる」とかいう絞込みが出来れば、 あとは開発元が(最悪、ログをこまめに吐くよう一時的にアプリを改修して) 「どこで落ちているか」を調べるのは可能かと思います。 (開発環境内では動いてくれない(コンパイルしないと使えない)コントロールを  以前使ったこともあるので、不具合の状況によっては面倒かなぁ、と思ったりもしますが) あと、落ちる箇所自体は判明しても、簡単に修正できるかどうかは、また別の問題ですが(^^; デバッガのログを採取したところで、結構な手練でないと、解読は困難だと思いますよ。たぶん。

subarist00
質問者

お礼

ちなみにメモリダンプの内容をのぞいてみたら、 (dc.7d0): Access violation - code c0000005 (first/second chance not available) kernel32!MultiByteToWideChar+0x7e7: 7c84bf3a 0fb60f movzx ecx,byte ptr [edi] ds:0023:06b56000=?? などという行がありました。これはkernel32.dllに入っているMultiByteToWideCharというAPI関数に変な引数が入っているという理解でいいのでしょうか? であればとても有用な情報なのですが。

subarist00
質問者

補足

アドバイス有難うございます。 >保守契約等で、開発元に調べてもらうことが可能ならば、調べてもらったほうがいいでしょう。 一般的にはそのとおりだと思います。ただ開発者が外人のため、再現しにくいエラーについては先方も理解できなくて困っています(万が一、他の場所に原因があってもいけない、という意味からも慎重にいろいろ検討しています)。 またそのソフトもエラーログは備わっていますが、直接エラーのログに何も出てこないところを見ると外部のコンポーネントを使用していて、それがエラーを起こしているのかもしれません。 自分のPCにもVC++6.0とデバッガも入っていますし、必要ならメモリダンプをわかるだけ解読して渡すというのもひとつの手だと思います。 完全にできる方法を、というよりも一つでも手がかりが無いかと思って探しています。ダメ元でもよいので「ここを見てみる手もあるよ」というのがあればお願いしたいと思います。

  • ai-sapuri
  • ベストアンサー率37% (11/29)
回答No.1

ソフトの知識はありませんが、ハード的な問題として、よく似た事を経験しています。 問題は、ソフトよりハードの問題で、ハードディスクのクラスタが原因でした。 対応は、当然、HDの交換を行い以後問題がありません。 他に似た、問題でPC130のメモリーカードの交換で直ったものがあります。 原因は、わかりませんでした。 但し、取り外したメモリーは、社員の方に贈呈されたようですが以後不明です。 参考になればよろしいのですが、その問題と関わりがあれば、強制終了の頻度が多くなります。 参考まで

subarist00
質問者

お礼

ご回答ありがとうございます。

subarist00
質問者

補足

情報有難うございます。確かにハードがらみだとどれだけソフトの中を探しても見つかりませんね。私も今までに数十台のPCを見てきた中で1回だけメモリ不良の経験があり、memtestをかけるとエラーを吐きまくっていました。今回はそういったこともありません。それに、いくつかのPCで起こるのでソフトウェアがらみだと思います。 以前はWinXP、WinXPのSP1、SP2でも問題なかったのですが、最近問題のソフトがアップデートされてから問題がおきています。ただ、アップデートの量が相当多く、また再現性に乏しいことからどこで問題が起きているのかわかりません。ただ、複数のPCや複数のOSのバージョンで起こるのでソフトが原因ではないかと思っています。

関連するQ&A