ＤＬＬのトレース確認方法
解決現在、ＶＣで作成したＤＬＬにて処理が途中で止ってしまっているようで、
正常に最後まで処理が流れない状況です。
どこで処理が止っているか確認したいのですが、現在、デバック情報やロ
グ出力等の対処を行っていないため、処理がどこまでされているかわかり
ません。
また、ログ出力等の対処は今後する予定ですが、既に上記の現象が発生し
てしまったマシンにおいて、ＤＬＬの処理がどこまでいってるか確認する
ための手段、方法等はあるのでしょうか？
ちなみに、ワトソン博士でダンプファイルを取得してバイナリーデータか
ら分析できるかと思いましたが、アプリはエラーとの認識はないようで、
イベントビューア等にもエラー情報はないため、ワトソン博士での取得は
無理な状況です。
よろしくお願いします。
> 現在、ＶＣで作成したＤＬＬにて処理が途中で止ってしまっているようで、
> 正常に最後まで処理が流れない状況です。
> アプリはエラーとの認識はないようで、
このような状況だと、アプリ内で無限ループになっているのでは？
一度、ループ処理の条件文などを見直すのがよいでしょう。
（昨日、私も条件文の記述ミスで、無限ループをしていしまっていたので）
ＤＬＬやアプリ側に仕込みがなく、さらにアプリでエラーが発生していないのでは、
正直、どこまで実行されているかを追うのは至難の業かと思います。
ソースレベルデバッグが無理なら、できないと思いますが・・・
尚、そのＤＬＬはデバッグオプションでコンパイルされたものですか？
それともリリースオプション？
シンボル情報が無いなら、結果的にSoftICEとか使って動作を見ても
解らないと思います。
以上。
ＤＬＬはリリースオプションでコンパイルしたものです。
ちなみに、プログラムが停止していると思われるあたりのソースにはループ
処理がないため、無限ループに陥ってるとは考えられず、マシンによって正
常に処理が終了するマシンと処理が止ってしまうマシンがあります。
現在、どこで停止していそうか、ソースから怪しい箇所をチェックしているので
すが、「ReportEvent」の処理がおかしい可能性がでてきました。
ReportEventによって正常にイベントログが書かれる場合もあるのですが、今回
のように処理がとまっているようにみえるときはイベントログが書かれていませ
ん。（ＪＡＶＡのクラスから今回のＶＣで作成したＤＬＬが呼ばれるのですが、
ＤＬＬで行っている処理はReportEventにてイベントログに出力するくらいの処
理しか行っていません。ＪＡＶＡの方はログが出力されているため、正常に動い
ているため、ＪＡＶＡから呼ばれた今回のＤＬＬが怪しいと思っています。）
ReportEventを調べたのですが、ReportEventで応答なしになる、といったよう
な事象はありませんでした。
動いているマシンの環境と動かないマシンの環境の列挙を
お願いします。
ＯＳやサービスパックの適用など・・・
以上。
DLLが自分が作ったもので、かつソースを持っているのなら、
現在作成中のexeと同じソリューションで作成すれば、DLL内にもブレークポイントが設定できるはず。
VisualC++ .NET 2003
での動作なので間違ってたらごめん。
でも、VisualC++6.0でもできたはず。
ＤＬＬは自作したものです。
しかし、途中で処理が止ったときに処理がどこまでいっていたのか、ということを
知ることが第１目標なので、今後の対応等で上記で教えて頂いた方法にて対処を見
当したいと思っています。ありがとうございます。
また、動くマシンと動かないマシンですが、動かないマシンも必ず動かないので
はなく、しばらく（２〜３か月）正常に動いていて、ある日急に動かなくなり、
それからは何度ＤＬＬが呼ばれても処理が最後までされないでとまっている状態
です。ＯＳ再起動をかけると、正常に処理が最後までされます。
通常はＯＳはずっとあがったままで、毎日シャットダウン等はありません。
動かなくなったことのないマシンも、途中から動かなくなったマシンも同じWind
ows2000ServerSP4です。
動かなくなったことのないマシンは毎日ＯＳ再起動が入ります。
開発環境ですが、ＶＣ＋＋６．０ＳＰ５です。
第１目標：処理がとまったマシンで処理がどこまでされていたか確認する方法
（今後、ログ等を仕込んだりデバックして確認するのではなく、既に
処理がとまったマシンで処理がどこまで行われたか知る方法）
第２目標：処理が途中でとまった原因追求。
（処理がとまってしまう事象はＯＳ再起動以来発生していないため、
考えられる原因を調査しており、そこで、ReportEventで応答なし
になる可能性があることがみえてきました。もちろん、今後の対策
はログ強化等を行う予定で、今知りたいのは今後の対策等ではなく
処理が途中でとまった原因となりうることを調査しています。）
目標は上記のとおりで、第２目標もできればよいのですが、今はとにかく第１目
標を知りたいと思っています。
よろしくお願いします。
> 第１目標：処理がとまったマシンで処理がどこまでされていたか確認する方法
> （今後、ログ等を仕込んだりデバックして確認するのではなく、既に
> 処理がとまったマシンで処理がどこまで行われたか知る方法）
何らかの形でログを吐かないと無理でしょう。
ログでなくとも、処理が進んだ痕跡として外部に何か残すのなら良いですが、残らないのでしょうし。
DLL 自体のソースを書き換えなければいいのなら、ログを吐かせることも出来ないわけではありません。
その DLL が呼び出している API をフックするとか。
その DLL を呼び出している EXE との間にプロキシを挟むとか。
止まった(ようにみえる)だけで落ちていないなら、
デバッガで動的にアタッチして、リリース版のリストファイル&
マップファイルを参考にアセンブリを解析するのが最終手段。
> また、動くマシンと動かないマシンですが、動かないマシンも必ず動かないので
> はなく、しばらく（２〜３か月）正常に動いていて、ある日急に動かなくなり、
> それからは何度ＤＬＬが呼ばれても処理が最後までされないでとまっている状態
> です。ＯＳ再起動をかけると、正常に処理が最後までされます。
上記が事実であれば、真先に思い付くのがリソースの枯渇です。
メモリやハンドルなどのリークがあるのではないでしょうか？
イベントログは詳しくないのですが、少し調べてみました。
ReportEvent の第１引数のハンドルを得るために RegisterEventSource を
使用していると思いますが、DeregisterEventSource していないとかでは
ないでしょうか？
イベントログへの書き込み失敗した場合、DeregisterEventSourceを行わず
に処理を抜けてしまっていました。
これが原因の可能性が高いので、イベントログに書き込み失敗した場合でも
DeregisterEventSourceを行うように修正します。
ありがとうございました。
| ツイート |  |