0

私は非常に厄介な問題をデバッグしてきました。

基本的に、さまざまな方法でクラッシュする難読化されたアセンブリがあります。難読化されていないアセンブリには問題はありませんが、ここで難読化ツールに責任がないという保証はありません。(それは私が修正しようとしているものかもしれません)

とにかく、難読化されたアセンブリも.Net 4.0で正常に動作します。.Net 4.5 で JIT 最適化を無効にすると、正常に動作します。

私が試したこと:

ILに対してデバッグしてみました。アクセス違反は、単に何かをスタックにロードする IL 操作から発生しているようです。繰り返しますが、完全に管理されたコードです。

String.Emptyに関連している場合に備えて、IL を調べ、すべての string::empty 呼び出しをldstr "". に置き換えました。ここで、AccessViolation の代わりに FatalEngineException を取得します。

ただし、すべてのオプションをオフにして難読化解除ツールを実行すると、機能します。基本的に、難読化解除ツールが何もオンにせずに行うことは、IL をかろうじて再配置し、いくつかの NOP を挿入することだけです。

また、実行可能ファイルは PEVerify をパスするため、問題にはなりません。

悪い実行可能ファイル: Test.exe

適切な実行可能ファイル: Test-cleaned.exe

問題のあるスタックトレース:

Test.exe!PreEmptive.SoS.Client.Cache.CacheService.ServiceCache() 行 22032 + 0x137 バイト不明
Test.exe!Test.TestConsole.Main(string[] args) 14 行目 + 0x6 バイト 不明

ildasm を使用して、2 つの実行可能ファイルを比較できます。再注文したので、私の好みでは少し難しすぎました。メソッドの IL をダンプするだけの小さなツールを作成し、比較しやすいようにメソッドを並べ替えました。

悪い IL ダンプ: testcount.il

適切な IL ダンプ: testcountcleaned.il

とにかく、これを分析し、IL のどの部分がこれを引き起こしているかを正確に把握する方法について誰かがアイデアを持っているなら、私はそれを感謝します.

4

1 に答える 1

0

解決策は、実際に P/Invoking を少しだけ使用することでした。.Net 4.5 は、より積極的にメモリを使用します。何らかの理由で、使用していたツールが、構造体の 1 つで Marshalling 属性を削除しました。そのバグを修正した後、すべてが魔法のように機能します。したがって、.Net 4.5 のバグではありません。メモリをより積極的に使用するようになりました。

于 2012-09-12T13:27:32.070 に答える