.NET Framework mscorlib沙箱场景下栈追踪行号缺失Bug问询

正如评论指出，下文代码针对可移植PDB（portable pdbs）。可移植PDB与当前场景无关，但本问题对使用沙箱应用程序域和可移植PDB的用户仍有参考价值。

我在受限制的沙箱（AppDomain）中运行代码时，沙箱内部抛出的异常没有附带行号；解除CAS限制后行号正常显示，因此问题与CAS相关。StackFrameHelper.InitializeSourceInfo似乎负责提供行号信息，其内部的条件分支在受限路径下执行时，第二个Assert调用会失败（参考stacktrace.cs第135行），相关代码如下：

// need private reflection below + unmanaged code for the portable PDB access itself
// PERF: these demands are somewhat expensive so do the quick check first. We are aiming for
// ~50k traces/s at 5 frames/trace on decent 2017 era hardware to maintain rough performance
// parity with 4.7 implementation that didn't have Portable PDB support
if (!CodeAccessSecurityEngine.QuickCheckForAllDemands())
{
    new ReflectionPermission(ReflectionPermissionFlag.MemberAccess).Assert();
    new SecurityPermission(SecurityPermissionFlag.UnmanagedCode).Assert();
}

该操作会抛出异常*“执行同类型的另一修改前，必须先还原堆栈遍历修饰符”*，但该异常在第205行被吞掉，直接跳过了PDB加载逻辑。

• 根据官方文档及相关公开问题的说明，每个栈帧只能激活一个断言，因此上述代码看起来存在逻辑错误，这是否是mscorlib 4.8的编程错误？
• 为了规避该问题我需要阻止程序进入上述分支，但我找不到CodeAccessSecurityEngine.QuickCheckForAllDemands的源码，该方法似乎与完全信任相关，但我的调用程序集已经是完全信任的；另外在调用exception.ToString()前断言无限制权限（new PermissionSet(PermissionState.Unrestricted).Assert()）也没有效果，当前AppDomain配置为沙箱，IsFullyTrusted返回false，该如何规避这个疑似Bug？

内容的提问来源于stack exchange，提问作者Bouke