Windbg help -> how can I read the code at this callstack?

Question

I have a dump of a windows service i made. The exception is that my code can't move a file (for some reason). Now, in my code there's a number of places where i move files around the filesystem. So, using Windbg, i'm trying to see the code where the exception occurs.

here's my !clrstack dump..

0:016> !clrstack -p
OS Thread Id: 0xdf8 (16)
Child-SP         RetAddr          Call Site
0000000019edea70 0000064278a15e4f System.IO.__Error.WinIOError(Int32, System.String)
PARAMETERS:
    errorCode = <no data>
    maybeFullPath = <no data>

0000000019edead0 0000064280181ce5 System.IO.File.Move(System.String, System.String)
PARAMETERS:
    sourceFileName = <no data>
    destFileName = <no data>

0000000019edeb50 0000064280196532 MyClass.Foo.DoSomeStuffInHere(System.String)
PARAMETERS:
    this = 0x0000000000c30aa8
    filePathAndName = 0x0000000000d1aad0

now, this helps a lot...

0:016> !do 0x0000000000d1aad0
Name: System.String
MethodTable: 00000642784365e8
EEClass: 000006427803e4f0
Size: 88(0x58) bytes
(C:\WINDOWS\assembly\GAC_64\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
String: C:\BlahBlahFolder\FooFolder\4469.jpg
Fields:
-snipped-

So i've figured out the file which failed to be moved. kewl. But i just want to see the code in this method MyClass.Foo.DoSomeStuffInHere(System.String) which calls File.Move(..). That method has lots of File.Move .. so i could put try / catches / debug / trace information .. but i'm hoping to be more efficient by using Windbg to help find this problem.

Any thoughts?

Answer 1

You cannot get the exact line of code, unless the application was deployed in debug mode. And if that were the case, I believe it would be showing them in the !clrstack call.

Answer 2

This is a difficult problem and may require stepping outside of one's comfort zone of managed only debugging.

What you want to do is map the IL for the function MyClass.Foo.DoSomeStuffInHere to the dissassembly of that function. My example below is x86 however x64 can follow the same steps.

This is referenced way down deep in the following link. Debugging Unexpected Process Termination

Example text from the whitepaper: In the managed stack, Debugging.Unexpected.btnSTA_Click ... Look at the code in the Debugging.Unexpected.btnSTA_Click event.

private void btnSTA_Click(object sender, System.EventArgs e)
{
   DebuggingCOMLib.STAClass staobj =  new DebuggingCOMLib.STAClass();
   staobj.RaiseError(1,5);
   Label1.Text += "STA Call Completed sucessfully";
}

If the source code is not available, you can examine the assembly by supplying the instruction pointer for the call-stack frame to the !u command. The instruction pointer can be retrieved from the !clrstack: output.

0096f970  03a00e06 [DEFAULT] [hasThis] Void
Debugging.Unexpected.btnSTA_Click(Object,Class System.EventArgs)

To disassemble this function, type !u 03a00e06.

    0:010> !u 03a00e06 
    Normal JIT generated code
    [DEFAULT] [hasThis] Void Debugging.Unexpected.btnSTA_Click(Object,Class 
    System.EventArgs)
    Begin 03a00de0, size 54
   <snip>
    03a00e18 8b15a89c1702     mov     edx,[02179ca8] ("STA Call Completed 
    sucessfully")
    03a00e1e e83d3590ff       call    03304360 (System.String.Concat)
    <snip>
    03a00e2f 5e               pop     esi
    03a00e30 5f               pop     edi
    03a00e31 c20400           ret     0x4

Ok, now what?
Scan your own !u output for a line like

call    03304360 (System.IO.File.Move)

Also, you can run !ip2md 03a00e06 to get the MethodDesc and then run !dumpil to examine the IL code if that is easier.

You could count the number of calls to System.IO.File.Move in the !u output and then count down the same number in the IL. Then you can use .NET Reflector to Disassemble the method and map the C# to IL and compare the result.

Lot's of steps, but it would get you to the same result :-)

Thanks, Aaron