私はasp.netの例外を理解しています。私がコードを呼び出すページを持っていれば、もう1つのコードが呼び出されます。コードの最後のビット（別のdllの中にある）が例外をスローし、どこでも処理されなければ、スタックトレースがあるYSODにエラーがスローされるはずです。だから私は、スタックの一番下に実行されたコードの最初のビットを取得し、実際にエラーが発生した場所の先頭に次のコードが流れます。私のスタックトレースには、もともと呼び出されたページが含まれていませんか？
これを念頭に置いて、スタックトレースにaspxページが表示されないアプリケーションがあります。 システムでSystem.Web.Util.CalliHelper.EventArgFunctionCaller（のIntPtr FP、 オブジェクトo、オブジェクトトン、EventArgsの電子）で
：また、そのようにはasp.netスタックへの通常の初期の呼び出しを示していません。 Web.Util.CalliEventHandlerDelegateProxy.Callback（Object sender、 EventArgs e）、System.Web.UI.Control.OnLoad（EventArgs e）、 Community.Support.BasePage.OnLoad（EventArgs e）in C：\ Projects \ Unilever \ BinaryFiles \ Support \ BasePage.cs： のSystem.Web.UI.Control.LoadRecursive（）の行389 のSystem.Web.UI.Page.ProcessRequestMain（ブール のincludeStagesBeforeAsyncPoint、ブールのincludeStagesAfterA syncPoint）
私は本当になぜそれが表示されます。私の唯一のヒントは、リフレクションが使用されていることです。私はこれがなぜなのでしょうか？
これはいくつかの側面に依存します。たとえば、例外が別のスレッドで発生した場合、同じスタック上で発生していないため、 "呼び出し元"を取得しません（各スレッドは独自のスタック）！ – Yahia
例外を再スローする（または 'InnerException'に既存のスタックを保存せずに新しい例外をスローする）と、スタックトレースがリセットされます。 – Oded
'Community.Support.BasePage'は実際のaspxページではありませんか？あるいは、Web.UI.Pageから派生したクラスでもあります。実際のaspxページはこのクラスから派生しています。 – deostroll