News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

Runing WinDBG

Started by sys64738, October 02, 2013, 03:25:42 AM

Previous topic - Next topic

sys64738

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????

x64Core

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

japheth

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 ).

sys64738

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.

sys64738

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.

GoneFishing

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.

herge


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.


Regards herge
Read "Slow Death by Rubber Duck"
for chemical Laughs.