Home/ Questions/Q 662507
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T23:23:10+00:00

Title kinda says it all. The usual SOS command !bpmd doesn’t do a lot

  • 0

Title kinda says it all. The usual SOS command !bpmd doesn’t do a lot of good without a name.

Some ideas I had:

  • dump every method, then use !bpmd -md when you find the corresponding MethodDesc
    • not practical in real world usage, from what I can tell. Even if I wrote a macro to limit the dump to anonymous types/methods, there’s no obvious way to tell them apart.
  • use Reflector to dump the MSIL name
    • doesn’t help when dealing with dynamic assemblies and/or Reflection.Emit. Visual Studio’s inability to read local vars inside such scenarios is the whole reason I turned to Windbg in the first place…
  • set the breakpoint in VS, wait for it to hit, then change to Windbg using the noninvasive trick
    • attempting to detach from VS causes it to hang (along with the app). I think this is due to the fact that the managed debugger is a “soft” debugger via thread injection instead of a standard “hard” debugger. Or maybe it’s just a VS bug specific to Silverlight (would hardly be the first I’ve encountered).
  • set a breakpoint on some other location known to call into the anonymous method, then single-step your way in
    • my backup plan, though I’d rather not resort to it if this Q&A reveals a better way
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The anonymous method isn’t really anonymous. It just hides behind a compiler generated name.

    Consider this small example:

    Func<int, int> a = (x) => x + 1;

Console.WriteLine(a.Invoke(1));

    To find the return value, we need to find the name of the method implementation. To do that we need to locate the MethodDesc of the surrounding method. In this example it is Main(), so:

    0:000> !name2ee * TestBench.Program.Main
Module: 6db11000 (mscorlib.dll)
--------------------------------------
Module: 00162c5c (TestBench.exe)
Token: 0x06000001
MethodDesc: 00163010
Name: TestBench.Program.Main()
JITTED Code Address: 001e0070

    Via the MethodDesc we can dump the IL for Main()

    0:000> !dumpil 00163010
ilAddr = 003f2068
IL_0000: nop 
IL_0001: ldstr "press enter"
IL_0006: call System.Console::WriteLine     
IL_000b: nop 
IL_000c: call System.Console::ReadLine 
IL_0011: pop 
IL_0012: ldsfld TestBench.Program::CS$<>9__CachedAnonymousMethodDelegate1
IL_0017: brtrue.s IL_002c
IL_0019: ldnull 
IL_001a: ldftn TestBench.Program::<Main>b__0
IL_0020: newobj class [System.Core]System.Func`2<int32,int32>::.ctor 
IL_0025: stsfld TestBench.Program::CS$<>9__CachedAnonymousMethodDelegate1
IL_002a: br.s IL_002c
IL_002c: ldsfld TestBench.Program::CS$<>9__CachedAnonymousMethodDelegate1
IL_0031: stloc.0 
IL_0032: ldloc.0 
IL_0033: ldc.i4.1 
IL_0034: callvirt class [System.Core]System.Func`2<int32,int32>::Invoke 
IL_0039: call System.Console::WriteLine 
IL_003e: nop 
IL_003f: ret

    Notice the funny looking names. They are the names of the generate delegate type and the actual method. The method is called <Main>b__0. Let’s look at the method:

    0:000> !name2ee * TestBench.Program.<Main>b__0
Module: 6db11000 (mscorlib.dll)
--------------------------------------
Module: 00152c5c (TestBench.exe)
Token: 0x06000003
MethodDesc: 00153024
Name: TestBench.Program.<Main>b__0(Int32)
Not JITTED yet. Use !bpmd -md 00153024 to break on run.

    There you have it. MethodDesc is 00153024 and as the comment say, you can use !bpmd to set the breakpoint using the MethodDesc.

    • 0