ReAttach does not attach in time to allow debugging of DllMain's DLL_PROCESS_ATTACH

[fanaticlatic]

I am writing some dll injection and have discovered ReAttach is unable to pick up the process between Windows calls:
CreateProcess(...); // creates the process to hook
and the end of:
CreateRemoteThread(...) // Calls the DllMain I wish to debug

When CreateRemoteThread runs my target apps DllMain call, it doesn't attach in time to handle the DLL_PROCESS_ATTACH. I am able to break on the DLL_THREAD_ATTACH/DETACH and DLL_PROCESS_DETACH.

The only way I can debug is to place a breakpoint in my injector application prior to the CreateRemoteThread function then either run ReAttach or use Visual Studios "Attach to Process".

[erlandranvinge]

Hi there. Thanks for the feedback, and I'm sorry to hear that. ReAttach uses a mix of windows and visual studio APIs to perform its work. The auto attaching part (with the dialog) is unfortunately relying on a simple polling timer. A quick peek into the code (https://github.com/erlandranvinge/ReAttach/blob/master/ReAttach/Dialogs/ReAttachDialog.xaml.cs) uncovers the rather embarrassing fact that the polling interval seems to be set to 1 second (!). I can keep some of my dignity by assuming that I never intended the feature to be used in time critical scenarios. This is obviously ridiculous design, and the ideal solution is likely somewhat in the direction of detecting actual process starts and acting upon those events.

[fanaticlatic]

Thanks for your quick response!

I appreciate this is definitely an edge case. ReAttach has saved me major headaches in the past. Glad I could point something out to make it even better.

[vadosnaprimer]

This is unfortunate. Usually things like __asm int 3 force it to break, allowing to attach normally, but this method doesn't work in my case, neither does reattach catch it on time apparently.

EDIT:

Okay the alternative way for 64-bit seems to be this.

[fanaticlatic]

@vadosnaprimer I've ended up using:
while( !IsDebuggerPresent() )
{
Sleep( 100 );
}
__debugbreak();

Windows specific, which for me is fine.

[vadosnaprimer]

I guess you don't even have to make it sleep as long as you have the ,pdb. It'd break, suggesting you to attach the debugger or just resume, and thankfully VS has no problem with attaching at this point, you just need the original project with .pdb available being loaded already, and point to it.