I’ve finished porting my debugging tools support libraries to x64 now and thought it was worth putting up a summary of the issues that I’ve noticed:
A 32bit exe can’t start a 64bit exe for debugging - pretty obvious really.
When a 64bit debugger is running a 32bit debugee the debugger seems to get TWO “loader breakpoints” one when the 64bit dlls are loaded and a second when the 32bit dlls have been loaded.
In a 32bit debugger running on WOW64 a call to
DebugSetProcessKillOnExit()succeeds but doesn’t seem to do what it’s supposed to do.
When a CLR process is started on an x64 machine you can’t rely on the image type of the stub to tell you if it will be a native x64 process or an x86 process; the stub for a .Net 2.0 process can be x86 yet can still cause a native x64 CLR host to run the app…
When running a CLR app under the Win32 debug interface you only ever seem to hit the native entry point if you’re running under WOW64. In all other situations you don’t hit the native entry point ever. If you rely on it to pause your debug tools once the process is completely loaded and ready to roll then you need to stick a break point in
mscoree.dll. What’s more, if you’re on x64 you might not even be able to access the native entry point’s memory…
When injecting a dll into a process using the “Richter” thread calls
LoadLibrary()approach remember that a) the dll image type (x86/x64) must match the process image type and b) if you’re injecting into a 32bit process from a 64bit process you’ll need to enumerate the modules in the 32bit process to get the
Kernel32.dllso that you’re function pointer to
LoadLibrary()is offset correctly…
And now to update the tools themselves so that they run as 32bit processes with 64bit processes stored as resources (along with the 32bit and 64bit injection dlls) so that they can switch over to 64bit if appropriate and can run natively on 32bit and 64bit OSs and inject into either 32bit or 64bit targets…