views:

285

answers:

1

My C# code is calling an unmanaged third-party library function via P/Invoke, and the unmanaged function is having some strange side effects. I want to debug into it and see what it's doing.

If I debug my C# code, and try to "Step Into" the P/Invoke call, it steps over instead. No surprise there -- I expected that; it doesn't have the source for this DLL, and I didn't tell it I was okay with seeing the disassembly view.

So I switch the debugger to disassembly view (Debug > Windows > Disassembly). Now I see the individual x86 instructions in my JITted code. Again I try to step into the P/Invoke call. Again, it steps over instead -- even though I clearly told it to Step Into an x86 CALL instruction. How hard is it to step into an x86 CALL?

My Googling thus far has shown me a couple of options that can affect this, and I've already set them:

  • In Tools > Options > Debugging > General, "Enable Just My Code" is unchecked.
  • In Project > Properties > Debug tab, "Enable unmanaged code debugging" is checked.

No good. Visual Studio still refuses to step in.

I don't have a PDB for the third-party DLL, but that shouldn't matter. I don't care about source code or symbol information. (Well, actually they'd be really nice, but I already know I'm not going to get them.) Visual Studio can do x86 debugging (that's what the Disassembly view is for), and all I want to do is step into the x86 code.

What else do I need to do to get VS to allow me to step into the x86 instructions inside a P/Invoke call?

A: 

One thing I would try is going from C# to C++/CLI code, and then from C++ to the third-party code. Once you're in C++ (and free of the P/Invoke infrastructure), you might have better luck with the disassembly view.

Dan
I know pretty much nothing about writing C++/CLI code... got any links that could help get me started with this strategy?
Joe White