問題タブ [peverify]

アセンブリを生成するコンパイラがあります。アセンブリをロードし、クラスがそのアセンブリにあるオブジェクトでメソッドを実行しようとすると、例外がスローされます。

System.InvalidProgramException: 共通言語ランタイムが無効なプログラムを検出しました。

エラー メッセージが示すように、これはUR COMPILER SUXX0RZ LOLOLOL!!! 、MSDN で調べると同じことを言っているのとまったく同じ情報です: コンパイラに何か問題があります。

そこで、生成されたアセンブリで PEVerify を実行してみましたが、もう少し有用なメッセージが表示されました。

[MD]: エラー: 署名でタイプ 'void' が不正に使用されています。[トークン:0x11000002]

残念ながら、どの署名に不正な void があるかなど、それ以上のことは何も言いません。ご存知のように、報告されたエラーを追跡するのに役立つ種類のもの...

ILDASM で開いてみると、明らかに間違ったボイドネスがぶら下がっているのがわからないので、次のステップは何ですか? 私のコンパイラが間違っていることを理解するために、ここからどこに行くのですか?

ライブラリをConfuserExMissingMethodExceptionで難読化しようとしていますが、その後、難読化されたクラスの最初の使用を指すスタック トレースでアプリがクラッシュし、問題のメソッドは名前が変更されたものです。呼び出しやその他の使用法がどこで見つかったのかわからないため、何を確認すればよいかわかりません。私の推測では、JIT プロセス中に例外が発生しています。

名前の難読化のみが適用され、それを逆にするマップがあります。

難読化されたモジュールを調べたところ、メソッドの名前が変更されたバージョンが確実に存在します。

また、難読化されたモジュールで PEVerify.exe を実行すると、いくつかのエラーが発生します (以下に小さな抜粋のみを示します)。

難読化プロセスをデバッグして何が問題なのかを検索する準備ができています...しかし、何を探すべきかわかりません。コードのどの部分が古いメソッド名を使用しようとしているかを調べるにはどうすればよいですか? PEVerify の出力を処理する方法、たとえば mdTokens はどのように役立つのでしょうか?

アセンブリの難読化に取り組んでおり、難読化後に PEVerify で次のエラーが発生します。

ヘッダー付きの最初のメソッド宣言は次のとおりです。

そして、ここに2番目のものがあります：

私には明示的な IDisposable インターフェイスの実装のように思えます。両方のメソッドも同様に呼び出されるため、一方へのすべての呼び出しが別の呼び出しに置き換えられたわけではありません。彼らは同じ名前を共有しているだけです

同様のコードが C# で記述されている場合、コンパイラはメソッド System.IDisposable.Dispose() および Dispose() を生成するため、同じ名前が削除され、PEVerify がサイレントになります。

そのうちの 1 つがインターフェイス メソッドの明示的なオーバーライドであり、もう 1 つがそうでない場合に、同じ名前が有効な IL になるようにするために、このようなサンプル アプリを作成しました。

IL は次のようになります。

異なるメソッド名に注意してください。

次に、結果のexeを取得ClassLibrary1.IX.Mし、ちょうど入るように編集しMましたClass1（dnSpyを使用してそれを行いました）。PEVerify は実際にメソッドの重複に関する同じ問題を発行し始めましたが、exe はまだ正常に機能してM() IX.M()おり、期待どおりに印刷されています。

問題は、PEVerify がここで慎重すぎるのか、それとも名前が一致しないことに本当に問題があるのか​​ということです。

最適化 (Visual Studio 2015) でコンパイルされているときに、作業中のアプリケーションで特定のプロシージャを実行しようとすると、InvalidProgramException が発生します。PEVerify を使用して問題の内容を確認したところ、"Method[offset 0x00000351] Stack underflow" と表示されました。

明らかに、最適化をオフにすることで問題を解決できますが、MS が次のバージョンで原因となるバグを修正するのを待っているため、これは最適な解決策とは言えません。

スタック アンダーフロー エラーを修正するにはどうすればよいですか? 推測する必要がある場合、おそらくこのクラスが約18k行であるという事実に関連していると言えますが、それについてできることはあまりありません...

編集：明確にするために、「6276行と6277行を削除する」という行に沿った答えは期待していません。私が探しているのは、.netでこの種の問題をトラブルシューティングするための一般的な戦略です。この ActionScript の質問に対する回答のようなもの: How to debug a runtime stack underflow error? 、.net に固有のものを除く。この種の問題を抱えている次の人が、この問題を回避するための出発点となるように、これを投稿しています。

正しくビルドして実行するコンパイラがありますが、PEVerify は特定の時点でそれを検証不能と呼んでいます。問題のエラー、対応するソース コード、および ILDasm の出力を注意深く調べた後、.NET および Mono バージョンを除いて、PEVerify のバグを疑うところまで問題を見つけることができませんでした。同じ場所で同じエラーを報告します。

問題のあるメソッドは次のようになります。

エラーは次のように報告されます。

[IL]: エラー: [D:\SDL-1.3.0-4423\boo\build\Boo.Lang.Compiler.dll: Boo.Lang.Compiler.TypeSystem.AsyncHelper::InAsyncMethod][オフセット 0x00000011][見つかった参照'Boo.Lang.Compiler.Ast.Node'][expected ref Boo.Lang.Compiler.Ast.INodeWithBody'] スタックに予期しない型があります。

Offsest0x11は式の後半に対応し??ます。ILDasm より:

このBoo.Lang.Compiler.Ast.Nodeクラスは、すべての AST ノードの基本クラスです。 BlockExpressionとMethodは、それぞれラムダとメソッドのノード クラスであり、どちらもINodeWithBodyインターフェースを実装します。C# (型に問題があるとビルドされない) と IL (メソッド呼び出しの最初の型パラメーターが呼び出し000cの戻り値の型であると記述されている) の両方で、すべてが正しく表示されます。GetAncestor<Method>!!0

Node明らかに type の値を持っているのに、ここで type の値を扱っていると PEVerify が考える原因は何Methodですか? そして、それを修正する方法はありますか？