Does having WinDbg attached to a target process interfere with how Detours functions?

[chuckchopp]

I can take a standard Win32 desktop application built either as a console app or a GUI app and use DetourUpdateProcessWithDll() / DetourCopyPayloadToProcess() to stuff some data into it to be to be consumed by the injected DLL. This has, in general, been working flawlessly on versions of Windows from WinXP up through Windows 11. Recently, while doing some testing with Windows 10/11 with long file name support enabled, I can copy that same program to a location on a NTFS volume such that the overall path length is 1,100+ characters in length. When I run the program, the process gets created and the program runs as expected. However, after I've opened a handle to the process and call DetourCopyPayloadToProcess() to stuff the exact same data into it, the target process abruptly terminates. The only difference between the scenario where it works and the one where it fails is the length of the path to the program file. Ultimately, I was able to isolate the root-cause of the problem as a buffer overrun when using a debug build of the injected DLL and a Microsoft Visual C++ Runtime Library "Debug Error!" message box was displayed.

What I wanted to know is what is the best/recommended way to get a target application under debugger control before the injected DLL's DllMain() is called for a DLL_PROCESS_ATTACH event. Is it as simple and straight forward has having the very first thing the injected DLL's DllMain() function does is to execute a "break" instruction and wait for a debugger to be attached? If so, will having something like WinDbg attached to the process have any negative impact on Detours' ability to inject the DLL into the target process?