How to set breakpoint at the very beginning of program execution - c++

Question

How can I stop the program before loading any of the linked DLLs?
I've tried to set LoadLibraryExW function in the Break At Function debugging option and it stops at that function, but before that I have the following in Visual Studio output windows:
'test.exe': Loaded 'C:\Windows\System32\ntdll.dll', Symbols loaded (source information stripped).
'test.exe': Loaded 'C:\Windows\System32\kernel32.dll', Symbols loaded (source information stripped).
'test.exe': Loaded 'C:\Windows\System32\KernelBase.dll', Symbols loaded (source information stripped).
'test.exe': Loaded 'C:\Windows\System32\uxtheme.dll', Symbols loaded (source information stripped).
'test.exe': Loaded 'C:\Windows\System32\msvcrt.dll', Symbols loaded (source information stripped).
---- plus about 30 DLLs ---
So how can I stop the program in the debugger before loading the ntdll.dll? Ok, not before loading, but before executing any of DllMain functions and before initializing any of static objects.

Answer 1

You can do this by adding a registry key to "Image File Execution Options" with the name of your exe. Add a value of type string named "Debugger" and set it to vsjitdebugger.exe to launch the just-in-time debugger dialog. Which then lets you pick one of the available debuggers, including Visual Studio. This dialog is triggered right after Windows has loaded the EXE, before any code starts running.
Here's is a sample .reg file that triggers the dialog when you start notepad.exe. Modify the key name to your .exe:
REGEDIT4
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\notepad.exe]
"Debugger"="vsjitdebugger.exe"

Answer 2

Using Gflags and WinDbg, you can automatically attach to your target application, and set a break point BEFORE any DLLs are loaded.
To do this, you will need the "Debugging Tools for Windows" installed. You can get that for free from Microsoft. It includes GFlags and WinDbg. You can find it at:
http://msdn.microsoft.com/en-us/windows/hardware/gg463009.aspx
Use GFlags to set the automatic debug options on your target program. This is the easiest way to set your system to start a debugger that will automatically be started up when the target application starts. No need to fool around with the registry, it will make all the necessary changes for you.
Use GFlags to set WinDbg to be started as the debugger. Change the Event Filters for WinDbg on the event "Create process" from "Ignore" to "Enabled". By default, WinDbg does not break on the process creation of your target. But if you need or want it to set a break point on create process, you can by changing this event option. The easiest way to change this option is let WinDbg start up on your application, use its GUI to change the option through the "DEBUG|Event Filters..." menu item and its dialog, save your workspace and stop debbuging. Then begin whatever leads to your target application starting, and from that time on for that particular debug target, WinDbg will break on "Create Process".
There are other ways to set this option automatically in WindDbg, but they aren't quite as easy as using its GUI. You can set the command line options for its invocation to enable the Create Process event. You can have WinDbg run a script file that will set the option for you. You can set WinDbg's TOOLS environment variable to point it to its "Tools.ini" file, and enable the create process event there. And there's a couple more methods to set the event option to enable a break point on Create Process.
The link above includes links for Debugging help with GFlags and WinDbg.
For most debugging needs, developers don't need or want a break point at process creation (before all the normal, basic dlls necessary to run are loaded). But if you do, WinDbg and several other free debuggers provided by Microsoft can do it. You just need to change the default for that event from ignored to enabled.

Answer 3

Instead of starting with F5, just start debugging with F11 or F10.

Answer 4

One way to break very early on is to manually add a Function Breakpoint on LdrInitializeThunk. This does not break before ntdll, but should be before any static initalization or user code

Answer 5

ntdll.dll is loaded by the kernel, during process creation. I don't know about the other dlls specifically, but they're most likely also loaded by the kernel.
As far as I'm aware, what you're trying to do can't be done, unless you were to write a rootkit to overwrite part of the process creation code. Even then, I'm not sure if the process being created is really considered a process before these libraries are loaded.

Answer 6

I don't think you can do this with the regular user-mode debugger in Visual Studio. Microsoft provides a free toolkit of other debugging tools, including kd (kernel debugger) and windbg, that might be able to interrupt the loading, but I doubt you'll ever be able to inspect the process before it loads ntdll. It's not really a process at that point.
What are you trying to accomplish?

Answer 7

There is no way to do this because DLLs that your PE-executable depend on are loaded by system (not by your process) before the process is even created. The process starts only when your executable is linked with all the functions imported from other DLLs.
ADD:
But of course DllMain routines are running for every DLL only when process is started and you may debug them.