Why is my stack trace being truncated?

Question

I have a partial-trust AppDomain within which I run a full-trust debugging window. Using PermissionSetAttribute to get permissions I can create the window and do plenty of things with it, but sometimes a SecurityException will be thrown during data binding.

One easily reproducible case throws this: Property accessor 'Namespace' on object 'System.RuntimeType' threw the following exception:'Request failed.'. Digging into the exception I can see that it was thrown when full trust was demanded.

No problem, the debug window assembly has full trust and I simply need to assert it. But when I look at the stack trace of the inner SecurityException I see this:

   at System.Security.CodeAccessSecurityEngine.Check(Object demand, StackCrawlMark& stackMark, Boolean isPermSet)
   at System.Security.CodeAccessSecurityEngine.Check(PermissionSet permSet, StackCrawlMark& stackMark)
   at System.Security.PermissionSet.Demand()
   at System.SecurityUtils.DemandGrantSet(Assembly assembly)
   at System.SecurityUtils.DemandReflectionAccess(Type type)
   at System.SecurityUtils.MethodInfoInvoke(MethodInfo method, Object target, Object[] args)
   at System.ComponentModel.ReflectPropertyDescriptor.GetValue(Object component)

It ends right there, at ReflectPropertyDescriptor.GetValue.

In Visual Studio's Call Stack window I can see ReflectPropertyDescriptor.GetValue at the very tip of the stack. That stack goes all the way back to the creation of the debug window and the security assert I performed there, which is exactly what I want.

Why has the stack been split in two like this? How can I stop it from happening?

I'm using .Net 4.0 security (i.e. Level 2).

Answer 1

This isn't that odd. Visual studio's call stack is showing you the method which you were at when the current exception was thrown . The InnerException shows the callstack of where the inner exception exception occurred. After the inner exception was thrown, it propagated up the callstack thus unwinding it until it got to ReflectPropertyDescriptor.GetValue. At that point, it was caught in a catch block and set as the inner exception of a new exception which then thrown and bubbled all the way up. So the call stack for the second exception begins at the point it was thrown (i.e. ReflectPropertyDescriptor.GetValue)

Here's a simple example which reproduces this.

namespace Exceptions
{
    class ExceptionTester
    {
        public void Run()
        {
            ThrowSecondException();
        }

        public void DoSomething()
        {
            DoMore();
        }

        public void DoMore()
        {
            ThrowFirstException();
        }

        public void ThrowFirstException()
        {
            throw new FooException();
        }

        public void ThrowSecondException()
        {
            try
            {
                DoSomething();
            }
            catch (FooException e)
            {
                throw new BarException("derp", e);
            }
        }
    }

    class FooException : Exception
    {

    }
    class BarException : Exception
    {
        public BarException(string msg, Exception inner) : base(msg, inner)
        {
        }
    }
    class Program
    {
        static void Main(string[] args)
        {
            var tester = new ExceptionTester();
            tester.Run();
        }
    }
}

When the second exception of type BarException is thrown, you'll notice that visual studio has ThrowSecondException at the top of the call stack because that is where BarException was thrown. However, when you dig into BarException's InnerException and look at FooException's call stack, it'll show you where FooException was thrown (ThrowFirstException()).