I started to use EasyCode along with WinDBG. I'm not totally new to ASM, so I'm a bit confused why this happens and how to get around it. When I start WinDGB it stops immediately in ntdll!DbgBreakPoint instead of the process' entry point.
Now I noticed a similar behaviour when I run Eclipse with GDB, but there GDB automatically inserts a breakpoint at main() (for C programs at least), so I can simply hit continue and it I can start debugging my program.
I thought to give WinDBG a try, because it seems rather powerfull and can also do kernel debugging. So is there some way to make WinDBG stop at the process entry point instead of ntdll? I mean, other than manually entering a breakpoint at the entry point and hit "go". :)
Do I really have to answer these captcha questions all the time, when posting something????
Yeah windbg was specially designed to kernel debugging to break on entry point use this command
bp $exentry
or might you want to code some script or plugin to do it autom
Quote from: sys64738 on October 02, 2013, 03:25:42 AM
So is there some way to make WinDBG stop at the process entry point instead of ntdll?
WinDbg /c "g start" <your_app.exe>
should work ( start is supposed to be the name of your app's entry point ).
Quote from: x64Core on October 02, 2013, 03:42:44 AM
Yeah windbg was specially designed to kernel debugging to break on entry point use this command
bp $exentry
Thanks, I have tro try that on my XP machine. I juste tested it on Windows 7 and there it behaves differently. It also stops in the ntdll (as is expected), but when I do a single step, it goes to the entrypoint automaticall. On the XP version it doesn't do this.
Quote from: japheth on October 02, 2013, 03:47:31 AM
WinDbg /c "g start" <your_app.exe>
should work ( start is supposed to be the name of your app's entry point ).
I run Windbg from an IDE. Also when I restart the process it's the same. However, I just noticed that this problem seems only exist in the XP version/environment.
From WinDbg's command line options :
Quote
-g
(User mode only) Ignores the initial breakpoint in target application. This option will cause the target application to continue running after it is started or WinDbg attaches to it, unless another breakpoint has been set. See Initial Breakpoint for details.
but in this case it's better to have hard-coded breakpoint at the program entry;
then before restarting/closing the debugger will ask you if you want to save its current state, answer "Yes".
WinDbg is an advanced debugger . It takes time to learn how to use it.
hi sys64738:
Also try
g Module_name!start
i e g Program!start
where Program.exe is your image module and start is
your entry point i e
end start
If it is not a proc name, you might have to say
public your_label_name
i e
public dtbuff
dtbuff db 120 dup (0)
Also make sure the path to image and symbols and source is
sorted out.
Also:
_NT_ALT_SYMBOL_PATH=c:\windows\symbols;
_NT_SYMBOL_PATH=c:\windows\synbols;
These two environmental variables must point to your PDB files
on your hard drive uusally C but can be elsewhere.
Use the SET command from Dos or do it from Control Panel.