1

私はクライアントの問題を解決しようとしていますが、アイデアが不足しています。スケジュールに従って実行されるカスタムの社内アプリケーションがありますが、クラッシュします。このようになってからどれくらい経ったのかわからないので、クラッシュを特定のソフトウェアアップデートまでさかのぼることはできないと思います。最も不幸な部分は、ロジックの要点を含むVB6DLLのソースコードがなくなったことです。

このVB6DLLは、VBスクリプトからの2〜3回の関数呼び出しによって開始されます。明らかに、VBスクリプトを変更してエラーログを追加することはできますが、クラッシュの原因を特定するための質の高い情報を取得することはできません。すべての関数呼び出しのいずれかの側にログメッセージを配置し、どの呼び出しがクラッシュの原因であるかを特定しました。ただし、呼び出しがwscript.exeをクラッシュさせているため、errオブジェクトには何も返されません。

他にできることがあるかどうかわかりません。何か案は?

編集:私が気にする主な理由は、ソースコードがないのに、クラッシュを引き起こす何らかの外部要因(不十分な資格情報、ロックされたファイルなど)がある可能性があることです。wscript.exeがクラッシュした結果としてdrwtsn32.logに作成されたログファイルを確認しましたが、取得する情報は「アクセス違反」のみです。

私は最初、これはセキュリティ権限と関係があると思う傾向がありますが、これもメモリアクセス違反ではないでしょうか。

4

10 に答える 10

6

これがファイルのアクセス許可などの環境に問題があると本当に考えている場合は、 Sysinternalsツールのいずれかを使用することを検討してください。私は以前、Filemon を使用して、アプリケーションが触れているすべてのファイルを把握し、その方法で問題を発見しました。

また、 Dependency Walkerを使用して簡単なサニティ チェックを行い、自分が想定している DLL ファイルを実際に読み込んでいることを確認することもできます。間違ったバージョンの C ランタイムがロードされ、原因不明のクラッシュが発生するのを見てきました。

于 2009-01-13T17:05:10.640 に答える
4

アプリケーションの範囲によっては、クライアントが書き換えを検討する場合があります。ソースコードがなければ、他の何かが変更されたときに、とにかくそうすることを最終的に強制されます。

于 2009-01-13T15:57:20.123 に答える
4

クラッシュするアプリを実行しているPC上で直接またはメモリダンプ上でデバッガーを使用して、多かれ少なかれ何が起こっているかを判断することは常に可能です。この場合、コードがVB6である場合、Win32レベルでのみ有用な情報が得られるため、あまり役に立たない可能性があります。

最終的に、ソースコードがない場合、バグが本当に役立つ場所を見つけることができますか?呼び出し元のスクリプトでそのコードパスを永久に回避できない限り、とにかくそれを修正することはできません。

于 2009-01-13T16:01:27.743 に答える
4

Windows 用のデバッグ ツールを使用できます。これはエラーを特定するのに役立つかもしれませんが、それを修正するソースがなければ、あまり役に立ちません.

怠惰な方法は、(スクリプトではなく) コードから dll を呼び出すことです。これにより、少なくとも問題の原因を確認し、err オブジェクトを調べることができます。問題が正しく呼び出されていない場合を除き、修正することはできません。

于 2009-01-13T16:04:23.790 に答える
2

役立つツールがいくつかあります。まず、依存関係ウォーカーを使用して、アプリのランタイムプロファイルを実行できます。

http://www.dependencywalker.com/

プロファイルメニューがあり、[子プロセスのフォロー]オプションがオンになっていることを確認する必要があります。これは2つのことを行います。まず、プルされたすべてのlibバージョンを確認できます。これは、いくつかの問題に役立つ場合があります。次に、ランタイムプロファイルは、子プロセスを実行するときにデバッグメモリマネージャーを使用します。したがって、バッファがオーバーランしているかどうかと、それに関する少しの情報を確認できます。

もう1つの便利なツールは、MarkRussinovichのプロセスモニターです。

http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

このツールは、すべてのファイル、レジストリ、およびスレッドの操作を報告します。これは、ファイルまたはレジストリのクレデンシャルの問題にぶつかっているかどうかを判断するのに役立ちます。

Process Explorerは、同じ情報をたくさん提供します。

http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

これもルシノビッチのツールです。このツールを使用して一部のデータを確認する方が少し簡単だと思います。

最後に、Windowsまたはdev studioのデバッグツールを使用すると、エラーが発生している場所を把握できます。

于 2009-01-13T18:08:38.767 に答える
2

Coding The Wheelの担当者は、オンライン ポーカー ボットの構築に関する非常に興味深いシリーズを持っています。このシリーズには、深刻な技術情報が満載です。その多くは、既存のアプリケーションにアクセスしてそれらをいじる方法に関係しています。あなたがしたいこと。

具体的には、WinDbg を使用して重要な情報を取得する方法に関する記事独自のコードへの関数呼び出しを曲げる方法に関する記事、および他のプロセスに DLL を挿入する方法に関する記事があります。これらの手法は、クラッシュを見つけて回避または修正するのに役立つ可能性がありますが、それでも難しいと思います。

于 2009-01-13T16:32:00.397 に答える
1

アクセス違反は、ほとんどの場合、メモリエラーです。この場合、ランダムにクラッシュするため、さらに可能性が高くなります(許可はより明らかに再現可能になる可能性があります)。dllの場合は、次のいずれかになります。

  1. dll自体のコードにエラーがあります。これは、メモリ割り当てエラーや単純なループ境界条件エラーのようなものである可能性があります。

  2. dllがシステム上の別のdllにリンクしようとすると、エラーが発生します。これは通常、マシン上のdllバージョン間の不一致が原因で発生します。

最初のステップは、再現可能なクラッシュ状態を取得することです。システムをクラッシュさせる一連の状況がない場合は、いつ修正したかを知ることはできません。

次に、システムをクリーンなマシンにインストールし、そのマシンでエラーを再現しようとします。モニターを実行し、プログラムがクラッシュしたときに開いている他のファイル(dllなど)を正確に確認します。ハイパースレッドのPentiumでクラッシュするコードを見たことがありますが、以前のマシンではクラッシュしません。したがって、古いマシンをテストベッドとして復元することは、そのマシンをカバーするための良いオプションかもしれません。マシンのRAMの量を変えることも価値があります。

うまくいけば、これらの手順があなたに手がかりを与えるかもしれません。うまくいけば、それは環境問題になるので、適切なバージョンのWindows、dllなどを使用することで回避できます。ただし、この時点でまだ適切な手がかりがないままクラッシュが発生する場合は、書き直すか、アセンブラレバーでdllをデバッグするか、分解して、問題をさらに詳しく調べます。アセンブリコードに精通していない場合、これらは両方ともロングショットであり、何が得られるかを確認するのは困難です。どちらのオプションも、膨大な時間の浪費になる可能性があります。私自身、過去に、このような特に低レベルの高強度の問題に直面したときに、「コーダー・フォー・ハイヤー」のWebサイトの1つで宣伝され、専門知識のある人を探しました。この場合も、これを実行するには再現可能なエラーが必要になります。

長期的には、ソースコードのないdllを置き換える必要があります。機能を分析し、フローチャートを提供するために組み立てスキルを持つ専門家に支払うことは、検討する価値があるかもしれません。実行中のマシンがクラッシュし、そのバージョンのWindowsが簡単に利用できなくなった後など、制御された方法でこれを後で行うよりも早く行うことをお勧めします。

于 2009-01-13T17:19:16.027 に答える
1

Resource Hackerを使用してみてください。社内アプリケーションを逆コンパイルできる可能性があります。完全なソース コードは得られないかもしれませんが、少なくとも、アプリが何をしているかについての詳細情報が得られる可能性があります。これは、原因を特定するのにも役立ちます。

于 2009-01-14T17:21:13.540 に答える
0

リバースエンジニアリングは1つの可能性ですが、難しいものです。
理論的には、コンパイルされたVB6アプリケーションを逆コンパイルし、デバッグ/トレースすることもできます。これは簡単な部分であり、最も単純な場合を除いて、ソースなしで変更するのは難しい部分です。

無料のコンパイラ/逆コンパイラ:

VBデコンパイラー

VBデバッガー

ほとんどの場合、書き換えは問題を解決するためのより成功したより高速な方法です。

于 2009-01-14T18:11:15.407 に答える
0

可能な限り最大の RAM をマシンに追加します

このシンプルで安価なハックは、過去に私にとって役に立ちました。もちろんYMMV。

于 2009-01-13T16:52:07.313 に答える