Comments on: Beware of using stack-based COM objects from .NET http://www.voyce.com/index.php/2010/01/21/beware-of-using-stack-based-com-objects-from-net/ Programming and debugging tidbits Wed, 04 Jan 2012 23:07:52 +0000 hourly 1 By: Grant Shirreffs http://www.voyce.com/index.php/2010/01/21/beware-of-using-stack-based-com-objects-from-net/comment-page-1/#comment-999 Grant Shirreffs Thu, 14 Oct 2010 20:17:23 +0000 http://www.voyce.com/?p=618#comment-999 Thanks, exactly what I wanted. Thanks, exactly what I wanted.

]]> By: ian http://www.voyce.com/index.php/2010/01/21/beware-of-using-stack-based-com-objects-from-net/comment-page-1/#comment-998 ian Thu, 14 Oct 2010 09:20:05 +0000 http://www.voyce.com/?p=618#comment-998 Hi Grant, Thanks for the comment. I found the offset using the public symbols for mscorwks and disassembling around functions of interest. If you've got the pdb symbols loaded (using <code>.symfix</code> should setup the appropriate paths) you can use <code>x</code> (examine symbols) to find the routine, e.g.: <code> 0:020> x mscorwks!RCW::Cleanup 79faa927 mscorwks!RCW::Cleanup = <no type information> </code> The particular offset I used was the location in that routine where it actually deleted its internal wrapper object: <code> 0:020> u 79faa974 mscorwks!RCW::Cleanup+0x4d: 79faa974 e8a7f7ecff call mscorwks!operator delete (79e7a120) 79faa979 59 pop ecx 79faa97a e8356eecff call mscorwks!_EH_epilog3 (79e717b4) 79faa97f c3 ret </code> The creation function is <code>mscorwks!RCW:CreateRCW</code>, so you can search for that using <code>x</code> in your live process in the same way. Hope that helps. Hi Grant,

Thanks for the comment.

I found the offset using the public symbols for mscorwks and disassembling around functions of interest. If you’ve got the pdb symbols loaded (using .symfix should setup the appropriate paths) you can use x (examine symbols) to find the routine, e.g.:

0:020> x mscorwks!RCW::Cleanup
79faa927 mscorwks!RCW::Cleanup = <no type information>

The particular offset I used was the location in that routine where it actually deleted its internal wrapper object:

0:020> u 79faa974
mscorwks!RCW::Cleanup+0x4d:
79faa974 e8a7f7ecff call mscorwks!operator delete (79e7a120)
79faa979 59 pop ecx
79faa97a e8356eecff call mscorwks!_EH_epilog3 (79e717b4)
79faa97f c3 ret

The creation function is mscorwks!RCW:CreateRCW, so you can search for that using x in your live process in the same way.

Hope that helps.

]]> By: Grant Shirreffs http://www.voyce.com/index.php/2010/01/21/beware-of-using-stack-based-com-objects-from-net/comment-page-1/#comment-997 Grant Shirreffs Thu, 14 Oct 2010 00:48:02 +0000 http://www.voyce.com/?p=618#comment-997 Interesting article; thanks very much for this. I especially like the idea of the dumping breakpoints on RCW creation and destruction. Unfortunately, the addresses you give are specific to a version of MSCORWKS.DLL , and are completely unmapped in a typical 32-bit process on my Windows 7/64 machine. How did you arrive at these addresses? I've tried remapping them based on the MSCORWKS addresses in your call stack compared to those in mine, but the functions must have moved inside the DLL. Any hints? Thanks again Grant Interesting article; thanks very much for this.

I especially like the idea of the dumping breakpoints on RCW creation and destruction. Unfortunately, the addresses you give are specific to a version of MSCORWKS.DLL , and are completely unmapped in a typical 32-bit process on my Windows 7/64 machine. How did you arrive at these addresses? I’ve tried remapping them based on the MSCORWKS addresses in your call stack compared to those in mine, but the functions must have moved inside the DLL. Any hints?

Thanks again
Grant

]]>