Can I set a breakpoint in ntdll.dll!_LdrpInitializeProcess?

Question

When debugging a Windows process, it would sometimes be convenient to break as early as possible.

Inital Callstack looks like this: (you get this e.g. when you set a breakpoint in a DllMain function on DLL_PROCESS_ATTACH)

    ...
    ntdll.dll!_LdrpCallInitRoutine@16()  + 0x14 bytes   
    ntdll.dll!_LdrpRunInitializeRoutines@4()  + 0x205 bytes 
>   ntdll.dll!_LdrpInitializeProcess@20()  - 0x96d bytes    
    ntdll.dll!__LdrpInitialize@12()  + 0x6269 bytes 
    ntdll.dll!_KiUserApcDispatcher@20()  + 0x7 bytes    

so setting a breakpoint in one of these ntdll routines should really break the process very early.

However, I can't figure out how to set a breakpoint there prior to starting the process in the debugger. Is it possible in Visual Studio (2005)? How? Can it be done in WinDbg?

Answer 1

I would use something like GFlags to launch the debugger when the process starts.

Here is a sample gflags settings for test.exe

And here is the debugger output. Notice the call-stack with ntdll!LdrpInitializeProcess

CommandLine: "C:\temp\test.exe" Symbol search path is: srv*;srvc:\symbolshttp://msdl.microsoft.com/download/symbols Executable search path is: ModLoad: 0000000000d20000 0000000000d28000
image0000000000d20000 (1b40.464): Break instruction exception - code 80000003 (first chance) ntdll!LdrpDoDebuggerBreak+0x30: 0000000077c7cb60 cc int 3 0:000> k Child-SP RetAddr
Call Site 000000000012ed70 0000000077c32ef5 ntdll!LdrpDoDebuggerBreak+0x30 000000000012edb0 0000000077c11a17 ntdll!LdrpInitializeProcess+0x1b4f 000000000012f2a0 0000000077bfc32e ntdll! ?? ::FNODOBFM::string'+0x29220 000000000012f310 00000000`00000000 ntdll!LdrInitializeThunk+0xe

Or you could open the process within the debugger like Windbg which would break into ntdll!LdrpInitializeProcess by default.

HTH

Answer 2

I have found out how to do it in Visual Studio.

The problem here is, that setting a breakpoint in any assembly function will be remembered as a "Data Breakpoint". These breakpoints are disabled as soon as the process stops, so even if I set one in this function (I can do this because I have the function on the stack if I set a breakpoint in any DllMain function) this breakpoint will be disabled for a new process run.

However for ntdll.dll (and kernel32.dll) the load addresses are pretty much fixed and won't change (and least not until reboot).

So, before starting the process, I just have to re-enable the Data Breakpoint for the address that corresponds to this NtDll function and the debugger will then stop there.