8

I investigating .Net Framework JITter compilation results and I want to get programmatically exceptions handlers chain. May be somebody can help me with this investigation?

To make task easier, I debug following code:

class Program
{
    static void Main(string[] args) { MethodA(); }

    static void MethodA() { MethodB(); }

    static void MethodB() 
    {
        try { MethodC(); } 
          catch (Exception exception)  { MethodC(); }
    }

    static void MethodC() { MethodD(); }

    static void MethodD()
    {
        try { MethodE(); }
          catch (Exception exception) { MethodE(); }
    }

    static void MethodE() { throw new Exception(); }
}

What's found?

  1. JITter uses standart way to build stack frames (locals, EBP, EIP, params)
  2. First parameters moves to method via registers (fastcall)
  3. Where is try-catch-finally ? I have no idea. Really. Method have no any code to deregister last handler from chain.
  4. Static methods pushes to stack only EBP and EIP. This means, stack cannot contain chain and chain is out of stack.

What I use: MS Visual Studio 2010, SOS extension for resolving .Net objects and metadata by address. VMMap to understand, what type of memory page by given address and (hehe) MS OneNote to mark memory dump with different colors to mark as resolved (that means, I understand what I found)

I'll be happy to understand where is this chain, but I have no experience to do it.

Important note: CLR don't uses SEH for exceptions (many articles, where authors write about SEH in CLR lies. CLR only wraps SEH to translate its exceptions into CLR types)

perror
  • 19,083
  • 29
  • 87
  • 150
Alexus
  • 181
  • 1
  • 1
    I assume http://stackoverflow.com/q/19111108/731115 could help you. – mikalai Jun 10 '14 at 07:47
  • Thx, but I looking for complex answer. Like in SEH (Structured Exceptions Handling): to obtain chain head, we need to read FS:0, where we will find....... – Alexus Jun 15 '14 at 05:33
  • As it's a very narrow domain, I'd suggest searching at clr-relared resources - there is a very little chance you'll get the answer here.. – mikalai Jun 15 '14 at 20:05

1 Answers1

1

I can't tell you straight up how it works but maybe this will help find the answer.

Firstly you want to be debugging on the CLR level - this is all about the CLR instructions that correspond to your code and how they install new exception handlers. Once you can do it in the debugger you can automate using the CLR debugging API.

http://msdn.microsoft.com/en-gb/library/vstudio/bb397953(v=vs.100).aspx

"The CLR debugging services provide several ways to control the execution of a program. These include breakpoints, single stepping, exception notification, function evaluation, and other events that relate to the startup and shutdown of a program."

Basically if you can understand the mechanisms of installing a new handler and looking up the handler when an exception is raised, then you can expand from there. Maybe this api will help maybe not.

offbyseveral
  • 111
  • 4