.NET Security Blog : Debugging

CLR Security Team CodePlex Site

shawnfa — Thu, 10 Jul 2008 22:20:59 GMT

The CLR Security Team just launched our CodePlex site: http://www.codeplex.com/clrsecurity. Currently, it contains two assemblies that provide additional functionality to the security APIs shipped in v3.5 of the .NET Framework.

We'd love your feedback on the currently offered libraries, and also welcome ideas for other libraries you'd like to see on our CodePlex site.

From the description page on the site, the two current libraries are:

Security.Cryptography.dll

Security.Cryptography.dll provides a new set of algorithm implementations to augment the built in .NET framework supported algorithms. It also provides some APIs to extend the existing framework cryptography APIs. Within this project you will find:

A CNG implementation of the AES, RSA, and TripleDES encryption algorithms
A CNG implementation of a random number generator
A class that allows dynamically creating algorithms both from this library as well as all of the algorithms that ship with .NET 3.5
An enumerator over all of the installed CNG providers on the current machine
Extension methods that allow access to all of the keys installed in a CNG provider, as well as all of the algorithms the provider supports

Security.Cryptography.Debug.dll

Have you ever run into an indecipherable cryptographic exception complaining about "Padding is invalid and cannot be removed" when using the .NET Framework's symmetric algorithms? Since nearly all bugs relating to symmetric algorithms tend to result in this same exception, it can be incredibly difficult to track down exactly what went wrong to cause the exception. Security.Cryptography.Debug.dll is a tool that can be used in these circumstances in order to help you figure out the root cause of your cryptographic exception.

FxCop Transparency Rules

shawnfa — Tue, 04 Apr 2006 17:00:00 GMT

The FxCop team has just announced the availability of RC 1 of FxCop 1.35. Notable in this release is the introduction of the first three rules around security transparency. Namely, you'll see:

SecurityTransparentAssembliesShouldNotContainSecurityCriticalCode - fires when an assembly which is marked transparent contains any code which is marked critical.
SecurityTransparentCodeShouldNotAssert - fires when a block of transparent code attempts to execute a CAS Assert.
SecurityTransparentCodeShouldNotReferenceNonpublicSecurityCriticalCode - fires when transparent code attempts to use critical code which is not public or TreatAsSafe.

Debugging a Partial Trust ClickOnce Application

shawnfa — Tue, 28 Mar 2006 20:05:00 GMT

Although the theory is that by the time we deploy a finished application it's already fully debugged we all know that in practice things rarely go that smoothly. So what happens if you deploy a partial trust ClickOnce application that starts to crash when it's run? Well, if you're lucky enough to have the problematic application stay alive for as long as it takes you to attach a debugger you're golden.

However if the crash occurs somewhere along the startup path, or if the debugger shows that something went wrong and got you into a bad state before you could attach it you might want to have the debugger run before the process even starts.

That's where things start to get tricky -- since ClickOnce is responsible for starting up your application, you can't just tell it to run the debugger for you. Instead, you can use the gflags tool from the Debugging Tools for Windows to intercept the start of your process. For a partial trust application, AppLaunch will be the real entry point, so you'll want to launch your debugger when AppLaunch starts.

In the gflags Image File section, set AppLaunch.exe as the image, check the debugger box, and put the full path to your debugger in the debugger field. I tend to use either Mdbg or WinDbg for this, depending on what kind of error I'm debugging.

Once you've got that setup you can launch your ClickOnce application normally and the debugger will start ready to run the application. If your app no longer starts up, make sure that the full path to the debugger is correct, since if Windows fails to find it, it will fail the CreateProcess for AppLaunch as well.

Finally, when you've solved the problem, you'll probably want to go back to gflags and uncheck the debugger box so that your partial trust applications no longer run under the debugger.

A couple of quick notes on this -- since all partial trust code runs through the same AppLaunch entry point, setting this up will cause all partial trust ClickOnce apps to run under the debugger, not just the one you're debugging. The same technique can be used for a FullTrust ClickOnce application as well; in that case you'd use the name of your application's .exe file instead of AppLaunch.

Debugging ADMHost

shawnfa — Thu, 05 Jan 2006 18:00:00 GMT

A few people have noticed that the ADMHost sample is not set up to do mixed mode debugging by default. If you're working with this sample and you'd like to debug through both halves of the host, you'll need to enable this mode.

Right click on the ADMHost project and open the properties window
Set Configuration Properties \ Debugging \ Debugger Type to be Mixed rather than Auto

That should enable a better debugging experience on the sample code.

Incidentally, Gregg explains why Auto won't work in this case here. Since the ADMHost.exe is native, the Visual Studio debugger doesn't know that it will have to do managed debugging when it gets to the ManagedHost.dll library and so it chooses native debugging instead -- causing any breakpoints set in the managed side to be ignored.

Finding the Source Code for an Assembly

shawnfa — Wed, 23 Nov 2005 00:31:00 GMT

Sometimes, especially when working on large projects (such as, I don't know, say ... the CLR), you find yourself debugging a problem where you don't know where a component is built from. Depending on the problem, it might be useful to get to the sources of the assembly to help diagnose what the issue is (or to look up in the source control system who the owner of the code is so you can contact them). I ran into this problem recently, and using the IronPython MDbg extension was able to whip up a quick method that will dump the path to the source files that make up an assembly that you have symbols for:

def ShowAssemblySources(assembly):
    for module in Shell.Debugger.Processes.Active.Modules:
        if module.CorModule.Assembly.Name.Contains(assembly):
            print module.CorModule.Name
            if module.SymReader != None:
                for document in module.SymReader.GetDocuments():
                    print "  %s" % document.URL
            else:
                print "  module does not have symbols, skipping"

Using this method is pretty straight forward:

[p#:0, t#:0] mdbg> ShowAssemblySources("caspol")
c:\WINDOWS\Microsoft.NET\Framework64\v2.0.AMD64chk\caspol.exe
  d:\vbl\lab21s\ndp\clr\src\ToolBox\caspol\obj1c\amd64\CommonResStrings.cspp
  d:\vbl\lab21s\ndp\clr\src\ToolBox\caspol\obj1c\amd64\CommonResStrings.cs
  d:\vbl\lab21s\ndp\clr\src\ToolBox\caspol\caspol.cs

It's definately not an every-day debugging tool, which again makes it nice that IronPython makes extending the MDbg command set so easy since I wouldn't have wanted to spend more than a few minutes working this code out.

Debugging Lightweight CodeGen in VS

shawnfa — Wed, 26 Oct 2005 01:10:00 GMT

Haibo just posted about his debugger visualizer for dynamic methods. This is a pretty sweet piece of code for anyone who uses lightweight code generation and needs to debug the code they've emitted. Basically it adds a visualizer to DynamicMethod objects that enables you to dump out the IL of that method. (He also explains the code he uses to convert from IL bytes to ILDasm style representation, which can be used with the new MethodBody class that reflection exposes)

IronPython + MDbg = good times

shawnfa — Sat, 03 Sep 2005 00:02:00 GMT

Mike Stall recently completed a project to embed IronPython into the MDbg debugger as an MDbg extension. IronPython's hosting interface is pretty slick, in fact it took Mike only 10 steps to get IronPython running inside MDbg and expose the debugger functionality to Python scripts via a variable named Shell.

After playing with Mike's extension for a few hours, I'm absolutely amazed by not only how easy it is to use, but how seamless the integration is. For instance, I haven't used Python since college, and have never written an MDbg extension before. However, less than an hour after I sat down to play with this I was able to write a script (which is less than 125 lines of code) that pops up a tree view displaying the processes being debugged, its AppDomains (and the assemblies loaded into them), and the threads with call stacks and locals:

It took only about 10-15 minutes to write a quick script that enables you to set the debugger options via a GUI, which should cut down on the amount of time I spend trying to remember which letter combinations I want to type after "catch" :-)

Since IronPython allows you to use most managed code, including the majority of the frameworks themselves from within your scripts, I used the System.Diagnostics.Process class to kick off a native debugger in order to snap a minidump of the process being debugged:

def MiniDump(path = "%TEMP%\\mdbg.dmp.cab", options = "/ma /ba", symbols = "srv**http://msdl.microsoft.com/download/symbols", debugger = "%WINDIR%\\System32\\ntsd.exe"):
    pid = Shell.Debugger.Processes.Active.CorProcess.Id
    path = Environment.ExpandEnvironmentVariables(path)
    executeString = ".dump %s %s; .detach; q" % (options, path)
    commandLine = '-c "%s" -pv -y %s -p %d' % (executeString, symbols, pid)

    print "Writing minidump %s" % path
    debugger = Process.Start(Environment.ExpandEnvironmentVariables(debugger), commandLine)
    debugger.WaitForExit()

Of course not wanting to leave well enough alone, I made a couple of modifications to the extension (original source code here). First, I added some new paths to the Python path:

%AllUsersProfile%\ApplicationData\MDbg\Scripts
%AppData%\MDbg\Scripts
The path the MDbg.exe is running in

// Add the all user app data\mdbg\scripts, appdata\mdbg\scripts, mdbg.exe path, and current directory
// to the python engine search path.
// @todo - could add the symbol path Debugger.Options.SymbolPath here too.
string scriptPathSuffix = Path.DirectorySeparatorChar +
    Assembly.GetEntryAssembly().GetName().Name +
    Path.DirectorySeparatorChar +
    "Scripts";
string[] pythonPath = new string[]
{
    Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData) + scriptPathSuffix,
    Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData) + scriptPathSuffix,
    new FileInfo(Assembly.GetEntryAssembly().Location).DirectoryName,
    Environment.CurrentDirectory
};
m_python.AddToPath(Environment.CurrentDirectory);
        
foreach(string path in pythonPath)
    m_python.AddToPath(path);

After that, I added the ability to have an autorun script, Startup.py. As the last step of initialization, I simply look for a Startup.py in each of the directories on the path, and if I find it kick it off:

    // Finally, run each Startup.py
    WriteOutput("Running startup scripts");
    foreach(string path in pythonPath)
    {
        string startup = path + Path.DirectorySeparatorChar + "Startup.py";
        if(File.Exists(startup))
            m_python.ExecuteFile(startup);
    }
} // end of PythonExt::LoadExtension

Finally, I added a PythonExtVersion property to the MDbgUtil variable, which allows a script to find out what version of the MDbg python extension it's running under.

class Util
{
    private static Version version = new Version(1, 1, 0, 0);
       
    public Version PythonExtVersion
    {
        get { return version; }
    }

This is pretty powerful stuff -- I can easily see not wanting to run MDbg without the ability to lo PythonExt for anything but trivial debugging. Considering how easy it was to get this up and running, if you've got a decent object model to expose to users, embedding IronPython into your application really opens up new doors for your users to use your application in ways you might not have thought of (or didn't have time to implement yourself) -- yet makes their experience much better.

Updated 4:06pm: Added links to StateWindow.py and OptionsGui.py

Viewing IL at Debug Time

shawnfa — Wed, 08 Jun 2005 18:55:35 GMT

Last week, I mentioned Yiru’s post on using SOS to see the IL of a dynamically generated method. Yiru’s post is about lightweight code gen, but the technique she shows is useful for more general purpose managed debugging . Let’s work through debugging a program that’s supposed to display the number of days between two dates. The problem is that the author of this program didn’t seem to test it before releasing it, and currently it only says that it cannot calculate the date difference.

I’ll start by firing up WinDbg and requesting that I break on any first chance managed exceptions. (Throughout this post, I’ll be italicising command I type and highlighting in bold and maroon debugger output that’s important for use later on):

0:000> sxe clr
0:000> g
…
ModLoad: 5b0c0000 5b1c0000   C:\WINNT\Microsoft.NET\Framework\v2.0.50607\mscorjit.dll
(960.860): CLR exception - code e0434f4d (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=0012e6e0 ebx=00000001 ecx=00000000 edx=00000006 esi=0012e7dc edi=0012e7d8
eip=77e55dea esp=0012e6dc ebp=0012e730 iopl=0         nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000             efl=00000202
KERNEL32!RaiseException+0x53:
77e55dea 5e               pop     esi

Once I’ve gotten the exception, I’ll load up SOS and see if displaying the exception gives any clue to what the problem might be:

0:000> !load sos
0:000> !pe
Exception object: 014628a4
Exception type: System.InvalidOperationException
Message: Operation is not valid due to the current state of the object.
InnerException: <none>
StackTrace (generated):
<none>
StackTraceString: <none>
HResult: 80131509

Huh, well that’s not very useful at all. It appears that the author of this program didn’t supply an exception message, so InvalidOperationException just used its default exception. In order to figure out why this exception was thrown, I’m going to look at the IL of the method that threw. Why look at the IL, instead of just using .frame or the call stack window to pull up the source for the method? Well, in this case I don’t have access to source code or symbols for the program.

In order to do that, I’ll have to first take a look at the call stack:

0:000> !CLRStack -p
OS Thread Id: 0x860 (0)
ESP       EIP
0012e914 77e55dea [HelperMethodFrame: 0012e914]
0012e98c 00f10164 Test.DaysBetween(System.DateTime, System.DateTime)
    PARAMETERS:
        start = <no data>
        end = <no data>

0012e9c0 00f100bd Test.Main()
0012f450 5d57671d [GCFrame: 0012f450]

I can see that the DaysBetween method is responsible for throwing the exception, since it’s at the top of the call stack. I also notice that it’s a static method (since there is no this parameter given), and that the IP of the throw was 0x00f10164. The SOS DumpIL command requires a MethodDesc as a parameter, so I’ll first use the ip2md command to get the MethodDesc that covers that IP, and then dump it’s IL:

0:000> !ip2md 00f10164
MethodDesc: 00ee0d38
Method Name: Test.DaysBetween(System.DateTime, System.DateTime)
Class: 00ef12c0
MethodTable: 00ee0d9c
mdToken: 06000002
Module: 001e0d40
IsJitted: yes
m_CodeOrIL: 00f10100
0:000> !dumpil 00ee0d38
ilAddr = 004020a4
IL_0000: nop
IL_0001: ldarg.1
IL_0002: ldarg.0
IL_0003: call System.DateTime::op_LessThan
IL_0008: ldc.i4.0
IL_0009: ceq
IL_000b: stloc.1
IL_000c: ldloc.1
IL_000d: brtrue.s IL_0015
IL_000f: newobj System.InvalidOperationException::.ctor
IL_0014: throw
IL_0015: ldarg.1
IL_0016: ldarg.0
IL_0017: call System.DateTime::op_Subtraction
IL_001c: stloc.2
IL_001d: ldloca.s VAR OR ARG 2
IL_001f: call System.TimeSpan::get_Days
IL_0024: stloc.0
IL_0025: br.s IL_0027
IL_0027: ldloc.0
IL_0028: ret

From looking at the IL of the throwing method, it appears that between IL_0000 and IL_000d we check to see if the second parameter is less than the first parameter (remember ldarg.0 gets the first parameter in this method since the method is static). If it is, then we jump to IL_0015, however if is not then between IL_000f and IL_0014 we use the default InvalidOperationException constructor and throw.

That analysis leads me to believe that the second parameter was in fact not less than the first parameter. Lets take a look at the calling method to try to figure out what the parameters were. From the call stack above, we know that the calling method is Main, and the IP where the call was made is 0x00f100bd. Following the same !ip2md, !dumpil sequence we see:

0:000> !ip2md 00f100bd
MethodDesc: 00ee0d10
Method Name: Test.Main()
Class: 00ef12c0
MethodTable: 00ee0d9c
mdToken: 06000001
Module: 001e0d40
IsJitted: yes
m_CodeOrIL: 00f10070
0:000> !DumpIL 00ee0d10
ilAddr = 00402050
IL_0000: nop
.try
{
IL_0001: nop
IL_0002: call System.DateTime::get_Now
IL_0007: ldc.i4 1980
IL_000c: ldc.i4.s 9
IL_000e: ldc.i4.s 15
IL_0010: newobj System.DateTime::.ctor
IL_0015: call Test::DaysBetween
IL_001a: call System.Console::WriteLine
IL_001f: nop
IL_0020: nop
IL_0021: leave.s IL_0033
} // end .try
.catch
{
IL_0023: pop
IL_0024: nop
IL_0025: ldstr "Could not calculate days between"
IL_002a: call System.Console::WriteLine
IL_002f: nop
IL_0030: nop
IL_0031: leave.s IL_0033
} // end .catch
IL_0033: nop
IL_0034: ret

The call to DaysBetween is on line IL_0015, and looking just above the call site we see that at the time of the call the parameters on the IL stack are September 15, 1980 and the current date. Clearly the current date is not less than a date in 1980, so it appears that the bug is in the order these parameters are given to DaysBetween.

In fact, with a little ildasm / ilasm magic, we can test that theory. Moving IL_0002 to appear between IL_00010 and IL_0015 will reverse the order of the parameters to the method call, and result in the program running and telling me that it’s been 9,032 days since 9/15/1980.

Yiru on Debugging LCG

shawnfa — Sat, 28 May 2005 00:03:00 GMT

Yiru's got a great piece up on using SOS to debug code that was emitted using Whidbey's new Lightweight CodeGen feature. Debugging any code written at the IL level can be tricky for anyone who doesn't have Partition III of ECMA committed to mind. LCG makes it even more fun since the code is generated dynamically, so there's generally not any source to look at when figuring out the problem. Yiru shows how to use the the SOS commands !DumpMD, !DumpIL and friends to help figure out what is wrong with the emitted method.

As I've mentioned a few times before in this blog WinDBG is my debugger of choice, and working with managed code all the time means knowing SOS is a must. I'm always glad to learn a new trick or two about that particular extension.

Whidbey's Security Off Model

shawnfa — Thu, 28 Apr 2005 17:03:00 GMT

Although the v1.0 and v1.1 versions of CasPol provided a switch to disable the CLR's security system, running without CAS enforcement on was never a scenario that we encouraged for obvious reasons. The choice to disable security was a system wide switch that affected any managed application on any version of the runtime, and made running managed code incredibly unsafe.

As of Whidbey, you'll find that the switch to turn security off no longer works as it used to. If you run caspol -s off with beta 2 or later of Whidbey installed, you'll see:

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50215>CasPol.exe -s off
Microsoft (R) .NET Framework CasPol 2.0.50215.44
Copyright (C) Microsoft Corporation. All rights reserved.

CAS enforcement is being turned off temporarily. Press <ENTER> when you want to
restore the setting back on.

Security will then be disabled as long as the CasPol process remains active. When CasPol is terminated, it returns security to the on state. Even abruptly terminating the CasPol process will still return security to its on state.

This works because the implementation of the internal security off flag has changed. Instead of using a registry key to indicate the status of CLR security, we now use a named mutex which CasPol holds to indicate to the CLR that it should disable security. Examining the the handles held by the CasPol process in a debugger will enable you to quickly identify this mutex:

0:000>!handle 0 4 Mutant
Handle 4c
  Name          \BaseNamedObjects\CLR_CASOFF_MUTEX
Handle 428
  Name          <none>
Handle 4a8
  Name          \BaseNamedObjects\ShimCacheMutex
Handle 624
  Name          <none>
4 handles of type Mutant

Since security is being disabled by this mutex, the CasPol process is resilient to being terminated unexpectedly, because Windows will just clean up the handle for CasPol when cleaning up the process. Another side effect is that if the machine is rebooted, the security state will revert to on.

If we fire up the kernel debugger, we can take a look at the ACL of the mutex:

lkd> !object \BaseNamedObjects\CLR_CASOFF_MUTEX
Object: 85088d88  Type: (8679f040) Mutant
    ObjectHeader: 85088d70
    HandleCount: 1  PointerCount: 2
    Directory Object: e179f980  Name: CLR_CASOFF_MUTEX

lkd> dt nt!_OBJECT_HEADER 85088d70
   +0x000 PointerCount     : 2
   +0x004 HandleCount      : 1
   +0x004 NextToFree       : 0x00000001
   +0x008 Type             : 0x8679f040
   +0x00c NameInfoOffset   : 0x10 ''
   +0x00d HandleInfoOffset : 0 ''
   +0x00e QuotaInfoOffset  : 0 ''
   +0x00f Flags            : 0x20 ' '
   +0x010 ObjectCreateInfo : 0x853e3678
   +0x010 QuotaBlockCharged : 0x853e3678
   +0x014 SecurityDescriptor : 0xe2c57b2c
   +0x018 Body             : _QUAD

lkd> ?? 0xe2c57b2c & ~0x7
unsigned int 0xe2c57b28

lkd> !sd e2c57b28 1
->Revision: 0x1
->Sbz1    : 0x0
->Control : 0x8004
            SE_DACL_PRESENT
            SE_SELF_RELATIVE
->Owner   : S-1-5-32-544 (Alias: BUILTIN\Administrators)
->Group   : S-1-5-21-2127521184-1604012920-1887927527-513 (Group: REDMOND\Domain Users)
->Dacl    :
->Dacl    : ->AclRevision: 0x2
->Dacl    : ->Sbz1       : 0x0
->Dacl    : ->AclSize    : 0x34
->Dacl    : ->AceCount   : 0x2
->Dacl    : ->Sbz2       : 0x0
->Dacl    : ->Ace[0]: ->AceType: ACCESS_ALLOWED_ACE_TYPE
->Dacl    : ->Ace[0]: ->AceFlags: 0x0
->Dacl    : ->Ace[0]: ->AceSize: 0x18
->Dacl    : ->Ace[0]: ->Mask : 0x001f0001
->Dacl    : ->Ace[0]: ->SID: S-1-5-32-544 (Alias: BUILTIN\Administrators)

->Dacl    : ->Ace[1]: ->AceType: ACCESS_ALLOWED_ACE_TYPE
->Dacl    : ->Ace[1]: ->AceFlags: 0x0
->Dacl    : ->Ace[1]: ->AceSize: 0x14
->Dacl    : ->Ace[1]: ->Mask : 0x001f0001
->Dacl    : ->Ace[1]: ->SID: S-1-5-18 (Well Known Group: NT AUTHORITY\SYSTEM)

->Sacl    :  is NULL

That shows that the mutex is created with an ACL that prevents anyone who isn't an administrator from owning it. And although Windows does not provide a way to prevent non-administrators from creating this mutex, internally the CLR will not respect the existence of the named mutex if it is abandoned or not owned by the BUILTIN\Administrators group. This prevents a squatting attack where a malicious user could turn off security simply by creating this mutex himself.

One of the more interesting effects to note of disabling security with this mutex is that the v2.0 CLR will no longer respect the registry key used by older versions of the runtime, and those versions will not have their security disabled by the new CasPol switch.

Although there still is the ability to turn off security, the ability to turn it off permanently has been removed. The new switch is useful mostly for debugging purposes, to establish if a problem you're diagnosing is related to the security system or not. The recommendation is still to avoid using this mechanism if at all possible.

Mike Stall on Finding the Real Exception Call stack

shawnfa — Wed, 19 Jan 2005 22:28:00 GMT

Mike's got an interesting piece up today about using WinDbg to find the actual call stack of an unmanaged (or managed for that matter) exception. It's this kind of power debugging technique that makes WinDbg my all time favorite debugger.

Mike Stall's (Relatively)New Debugger Blog

shawnfa — Tue, 05 Oct 2004 21:11:00 GMT

Mike Stall is one of the devs on our base services team, and his focus is on managed debugging. I played football with Mike 4 flag football seasons back, but generally don't need to work directly with him since the debugger and security don't have very much interaction. However, Mike is always the guy to go to whenever there's a debugging question, so I'll definitely be reading his blog with interest.

Some of the topics he's already covered are mdbg and the ICorDebug interface.

Finding Out The Current User in the Debugger

shawnfa — Fri, 24 Sep 2004 01:02:00 GMT

Every once in a while, while debugging multi-threaded applications that do impersonation, it becomes useful to figure out the context that the current thread is running under. This is especially useful when debugging server scenarios where connections are farmed out to worker threads which begin their work by impersonating the user logging in. Before Whidbey finding this information wasn't very straightforward, and even when you found out the current user, it was difficult to find out any other security token information.

Thankfully the VS Whidbey debugger team has stepped up with a nice solution to this problem. You can now evaluate the $user pseudo-register in the debugger, and find out all about the context that the current process and thread are running under. In addition to the user name, this variable also shows their SID, session id, login id, impersonation level, and active privileges. In addition to this, information on all the groups that the active user is a member of is listed.

If the current thread is impersonating, then information on the user the thread is impersonating as is also available. Here's what this might look like on a thread that is not impersonating:

Whidbey's New SecurityException

shawnfa — Fri, 30 Jul 2004 19:24:00 GMT

One of the more difficult things to debug with .NET 1.0 and 1.1 is the security exception. With these frameworks generally the only information that you got was the state of the failed permission. Due to the complexity of debugging security problems, most people just gave up and required that their code run in a fully trusted environment. With Whidbey we've done a lot of work to beef up the security exception, and make debugging security issues even easier, in the process making it easier for developers to figure out the minimum set of permissions that their application needs to run under.

Limitations of the Current Implementation

Currently, the SecurityException contains four security specific properties.

GrantedSet provides the set of permissions that are granted to the assembly that failed. This property does not get filled out every time an exception is thrown however.
PermissionState has the permission or permission set that caused the exception to be thrown
PermissionType is also not always filled out, when it is, it should contain if PermissionState is a permission, permission set, or permission set collection
RefusedSet contains the set of permissions that were refused by by the assembly that caused the security exception to be thrown

Generally, PermissionState is the only property that can be depended upon to always have a value. This does not provide for a good user experience.

The Whidbey SecurityException

The Whidbey SecurityException adds several more properties, which together allow developers to figure out what code was causing a security problem. The new properties are:

Name	Type	Description
Action	SecurityAction	the SecurityAction that failed the security check
Demanded	object	the permission, permission set, or permission sets that were demanded and triggered the exception
DenySetInstance	object	if a Deny stack frame caused the security exception to fail, then this property will contain that set, otherwise it will be null.
FailedAssemblyInfo	AssemblyName	AssemblyName of the assembly that caused the security check to fail
FirstPermissionThatFailed	IPermission	the first permission in failing PermissionSet (or PermissionSetCollection) that did not pass the security check
Method	MethodInfo	the method that the failed assembly was in when it encountered the security check that triggered the exception. If a PermitOnly or Deny stack frame failed, this will contain the method that put the PermitOnly or Deny frame on the stack.
PermitOnlySetInstance	object	if the stack frame that caused the security exception had a PermitOnly permission set, this property will contain it, otherwise it will be null
Url	string	URL of the assembly that failed the security check
Zone	SecurityZone	Zone of the assembly that failed the security check

As you can see, there's a ton more data available about the cause of the security exception in Whidbey. However, as I noted above, even the current SecurityException properties don't get filled out properly all the time. As part of the SecurityException enhancement work, we've gone through all the places in the BCL that throw exceptions and ensured that they've filled out as much of the SecurityException data as possible.

So What Does a New Security Exception Look Like?

All of these extra properties provide a lot of information for developers to work with if they catch the SecurityException in their code. But what happens if the exception goes unhandled? The default behavior of spewing exception information to the screen will still provide a lot more information than was provided before. For instance, if I tried to run my ProtectedData sample off a network share, with default policy in place, I'd end up with a SecurityException. The debug spew for that exception would look similar to the following.

First comes the standard stack trace and exception type that failed.

Unhandled Exception: System.Security.SecurityException: Request for the permission of type 'System.Security.Permissions.DataProtectionPermission, mscorlib, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.
at System.Security.CodeAccessSecurityEngine.Check(PermissionToken permToken,CodeAccessPermission demand, StackCrawlMark& stackMark, Int32 checkFrames, Int32 unrestrictedOverride)
at System.Security.CodeAccessSecurityEngine.Check(CodeAccessPermission cap, StackCrawlMark& stackMark)
at System.Security.CodeAccessPermission.Demand()
at System.Security.Cryptography.ProtectedData.Protect(Byte[] userData, Byte[] optionalEntropy, DataProtectionScope scope)
at CPD.Main() in \\shawnfa-build\c$\blog\ManagedDPAPI\CryptProtectData.cs:line 12

This is followed up by the SecurityAction that failed, the first failed permission, and the details of the demanded permissions. (From now on, I'm going to abbreviate the full assembly names.)

The action that failed was:
Demand
The type of the first permission that failed was:
System.Security.Permissions.DataProtectionPermission
The first permission that failed was:
<IPermission class="System.Security.Permissions.DataProtectionPermission, mscorlib ... "
version="1"
Flags="ProtectData"/>

The demand was for:
<IPermission class="System.Security.Permissions.DataProtectionPermission, mscorlib ..."
version="1"
Flags="ProtectData"/>

Next is a list of all the permissions granted to the assembly that failed the demand:

The granted set of the failing assembly was:
<PermissionSet class="System.Security.PermissionSet"
version="1">
<IPermission class="System.Security.Permissions.EnvironmentPermission, mscorlib ..."
version="1"
Read="USERNAME"/>
<IPermission class="System.Security.Permissions.FileDialogPermission, mscorlib ..."
version="1"
Unrestricted="true"/>
<IPermission class="System.Security.Permissions.FileIOPermission, mscorlib ..."
version="1"
Read="\\SHAWNFA-BUILD\C$\blog\ManagedDPAPI\"
PathDiscovery="\\SHAWNFA-BUILD\C$\blog\ManagedDPAPI\"/>
<IPermission class="System.Security.Permissions.IsolatedStorageFilePermission, mscorlib ..."
version="1"
Allowed="AssemblyIsolationByUser"
UserQuota="9223372036854775807"
Expiry="9223372036854775807"
Permanent="True"/>
<IPermission class="System.Security.Permissions.ReflectionPermission, mscorlib ..."
version="1"
Flags="ReflectionEmit"/>
<IPermission class="System.Security.Permissions.SecurityPermission, mscorlib, ..."
version="1"
Flags="Assertion, Execution, BindingRedirects"/>
<IPermission class="System.Security.Permissions.UIPermission, mscorlib, ..."
version="1"
Unrestricted="true"/>
<IPermission class="System.Security.Permissions.UrlIdentityPermission, mscorlib, ..."
version="1"
Url="file://shawnfa-build/c$/blog/ManagedDPAPI/CryptProtectData.exe"/>
<IPermission class="System.Security.Permissions.ZoneIdentityPermission, mscorlib, ..."
version="1"
Zone="Intranet"/>
<IPermission class="System.Net.DnsPermission, System ..."
version="1"
Unrestricted="true"/>
<IPermission class="System.Windows.Forms.WebBrowserPermission, System ..."
version="1"
Level="Restricted"/>
<IPermission class="System.Drawing.Printing.PrintingPermission, System.Drawing ..."
version="1"
Level="DefaultPrinting"/>
</PermissionSet>

Finally, the assembly that failed the permission demand is listed along with the method that called into the demanding code, and the Zone and URL evidence for that assembly.

The assembly that failed was:
CryptProtectData, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null
The method that caused the failure was:
Void Main()
The Zone of the assembly that failed was:
Intranet
The Url of the assembly that failed was:
file://shawnfa-build/c$/blog/ManagedDPAPI/CryptProtectData.exe

Visual Studio Gets In On The Action

In addition to all the work done in the CLR to make debugging security exceptions easier, Visual Studio 2005 has done quite a bit of work as well. When an unhandled SecurityException is thrown under the VS debugger, Visual Studio will look at all of the extra properties that are populated on that exception, and provide you with context sensitive help to solve the problem.

As you can see in the screen shot, VS will highlight the line that caused the SecurityException, and shows a pop up dialog that tells you the permission that failed and provides several possible solutions for the problem. In this case, there's not a lot of ways to get around the DataProtectionPermission demand, so the options that VS presents include turning this into a ClickOnce application or installing locally. This help is based around the failing permission, so if a FileIOPermission failed, VS might suggest using IsolatedStorage instead.

The View Details link will, oddly enough, open up the View Detail dialog where you can inspect each property of the Security Exception yourself, in order to help you further track down security issues.

Debug-In-Zone

All that's fine and good, but when you develop on your local machine, you end up with FullTrust by default. Forcing developers to modify their security policy to debug is not a good user experience, so again Visual Studio steps up to the plate, this time with a feature called Debug In Zone.

By going to your project properties, and accessing the security tab, you can specify the set of permissions that you'd like to debug your application with. For instance, if your goal is to have your application run with Internet permissions, then just select Internet from the drop down list. You can also create a custom permission set that reduces down to the exact set of permissions that your app needs; the Calculate Permissions button, which will interface with PermCalc will help you with this goal.

With the changes to the SecurityException class and enhancements to the Visual Studio debugger, figuring out the cause of those hard to diagnose SecurityExceptions.

What Happens When My Application Throws An Unhandled Exception

shawnfa — Thu, 15 Jul 2004 21:26:00 GMT

There are several different behaviors that can occur when a managed application throws an unhandled exception. The two most common are to bring up an error dialog box, or to pop up the Visual Studio Just In Time Debugger dialog box.

The first behavior is the default when you install the CLR, but don't install Visual Studio. Installing VS modifies the default to pop up the select-a-debugger dialog. How does the CLR figure out what behavior to use? It checks a registry key, located at HKLM\Software\Microsoft\.NetFramework\DbgJITDebugLaunchSetting. The value of this key lets the CLR know what to do when it encounters an unhandled exception. Possible values are:

Value	Action
0	Bring up the unhandled exception dialog box. (Click OK to terminate ...)
1	Print out the stack trace of the exception and terminate the application
2	Invoke the default managed debugger

If the value is set to 2, then the CLR consults HKLM\Software\Microsoft\.NetFramework\DbgManagedDebugger to determine which debugger to launch. This debugger is expected to be a managed debugger, that uses the CLR debugging interface. The debugger listed in this key will get four parameters, specified using printf style % format characters. The parameters are:

Parameter number	Meaning
1	PID of the process
2	ID of the AppDomain
3	Exception string ("System.OutOfMemoryException"), as a wide character string
4	Event handle to signal when aborting the attach operation

By default, Visual Studio registers the VSJITDebugger.exe program as the debugger, which is what is responsible for displaying the familiar choose-a-debugger dialog box. The default registration for this debugger in Visual Studio 2003 is:

"C:\Program Files\Common Files\Microsoft Shared\VS7Debug\VsJITDebugger.exe" PID %d APPDOM %d EXTEXT "%s" EVTHDL %d