CODEWITHSUNDEEP
c#visual-studio-2015com
sbrett
sbrett

Reputation: 606

Any way to ignore DebuggerHidden and DebuggerStepThrough attributes for a function?

I have some code that I really want to step into and get a bit more information out of. Unfortunately the function is marked with [DebuggerHidden] and [DebuggerStepThrough]. Is there any means by which I can tell the debugger (VS2015, Update 3. 14.0.25431.01 ) to ignore that attribute and break in such code anyway? The code is actually Microsoft's own RuntimeType.cs file's InvokeMember method. I'm trying to debug a COMException (RPC_E_SERVERFAULT).

Update

The .net code I am debugging is 4.0. I do have Enable .NET Framework source stepping turned on, as well as source server support. As source symbols from http://referencesource.microsoft.com/symbols are almost non-existant for .net 4.0 I am utilizing Jet Brain's dotPeek locally hosted symbol's server feature. This allows me to see the "source" for files like RuntimeType.cs, which allows me to set breakpoints directly. It also shows me that RuntimeType.InvokeMember is marked as [DebuggerHidden]. For this particular scenario to work I do have the debug option "Require source files to exactly match the original version" disabled. I also have managed and native compatibility modes turned on, and the c++ project I am running has it's Debugger Type set for Mixed.

Upvotes: 1

Views: 1749

Answers (1)

Eli Finkel
Eli Finkel

Reputation: 593

Couldn't find a way to bypass this in VS.
(Not even using assembly stepping)

However, I was successfully able to debug it using WinDBG (WinDBG uses a different debugging engine, which is not really aware of managed code, so it's kind of expected)

Here is the example program (compiled to my_exe.exe):

class Program
{
    public static void Main()
    {
        typeof(Program).
            GetMethod("Main", System.Reflection.BindingFlags.Static).
            Invoke(null, new object[] { });
    }
}

Here are the steps I used (WinDBG commands):

1. sxe ld:clrjit             /* Raise exception when clrjit is loaded (I find that before this stage, for some reason, SOS delayed managed breakpoints don't actually work) */
2. g                         /* Go till above exception is raised */
3. .loadby sos clr           /* Load SOS (managed debugging extension */
4. !bpmd my_exe Program.Main /* Set breakpoint on Main */
5. g                         /* Go till above breakpoint */

Once you're there, you can step into/over the assembly code as you wish, as well as setting additional managed breakpoints on relevant methods.

Upvotes: 2

Related Questions