One of the horrible things about SecurityException is just how little information you are given.

For example, let us take a look at:

Yes, that is informative. The real problem is that most security analysis is done at the method level, which means that _something_ in this method caused this problem. Which meant that in order to debug this, I have to change my code to be like this:

Which gives me this:

Just to point out, the first, second, etc are purely artificial method names, meant just to give me some idea about the problem areas for this purpose only.

Then we need to go into the code in the First method and figure out what the problem is there, and so on, and so forth.

Side note: never ever put anything that could remotely fail in a static constructor. Failing a static constructor causes the entire application to be effectively permanently unavailable until someone recycles the process. Only pure computations are suited for cctors. Use a static threadsafe lazy for anything else (but not the default one because it stores the exception! what an evil design choice).

Hmm, at least from a debugging scenario, could CodeAccessPermissions.Assert possibly loosen up the restrictions enough to get a stack-trace without compromising the security restriction causing the exception? Really not something I've ever been in this situation.

I had a similar problem in a Sharepoint project. The SecurityException was thrown because of a missing permission. In order to find the permission I did the following:

I've surrounded the code that caused the error with a try catch block and caught the security exception. Then I've set a breakpoint in the catch block and had a look at the exception object in the quickwatch window.

The security Exception has a private field called m_demanded (among some other interesting fields), which finally told me what the missing permission was.