Hi Feryno,

It looks that your debugger does not handle correctly handled exceptions.

I just create a simple test application which calls SetUnhandledExceptionFilter and I force an exception:

mov rax, 0
mov [rax], rax

My exception handler is called correctly when running under no debugger. If I run it under your debugger, it stays at the exception line and cannot continue execution to my handler.

I have also pressed "Ctrl-F12" but it does not work. Application just exists with CTRL-F12

Is there any problems with FDBG and handled exceptions?

Thanks.

Hi alorent,

msdn.microsoft.com/en-us/library/ms680634(VS.85).aspx
SetUnhandledExceptionFilter Function
...if an exception occurs in a process that is not being debugged...
...
Parameters
lpTopLevelExceptionFilter [in]
...and the process is not being debugged...

I think the function seems not to be friendly with debugger.
You can pass an exception into app exception handler (if the app has installed it), then the exception isn't captured by the debugger in its debug loop but it is delivered to the app exception handler - see IgnoreExceptions\*.* from included fdbg debuggee samples. This can be set in Rambo -> Ignore Exceptions. These settings are not saved at fdbg exits into ini file and are lost. It is usefull for apps reporting self errors or for antidebugs with self-modifyng code.

I was thinking about the G command. My idea is something like this:
fdbg checks whether code/data/stack window is at the top
if yes, then an edit control is created in address column so you can edit the address without any assistence of mouse clicks
now they are 3 choices:
1. cursor is at the begin
2. cursor is at the end (usefull if you often change only last 1-2 digits of address, avoids the necessity to move to the end of string at first before editing it)
3. the whole address in edit is selected, so if you press any char/digit key the whole string is replaced with that 1 char/digit (most usefull when you e.g. frequently change addresses into something like rip+40, rsi+100 etc., it would save a work to delete the whole sting before replacing it with new one)
Is it the same idea as your, or is it far away of it?

Hi Feryno,

Yes! Your scheme seems great for me!!! I'm happy to help you with beta testing!

Thanks man!

Hi alorent,
please try this version. I placed the Goto command into Explore menu and its key shortcut is Alt-G (you can change the shortcut in resource.inc -> accelerator main_keys, the line with IDM_GOTO). If you mind losing windows position settings from version 001A then just copy the original fdbg*.ini file into new file with the name fdbg20081103.ini
Don't forget to try changing the cursor settings in Face -> Various settings -> goto command edit style.
Cursor may be at begin / end / select all.
begin is the default
end is usefull if you often edit only last 1-2 digits of address
select all is usefull if you usually change addresses into something like rip-80, r9+A8 etc

edit from 2008-Nov-03, fixed the ini directory location, updated the attachment
edit from 2009-Jan-02, deleted the attachment, newer version available

ini file was not stored in fdbg main directory but was stored incorrectly in the directory with opened debuggee, fixed that, updated the attachment in the previous post

Hi Feryno,

Thanks a lot for the update!!! It works like a charm!

All the best for you and your x64 debugger

implemented the idea from:
http://board.flatassembler.net/topic.php?p=85298#85298

edit from 2009-Jan-15, deleted the attachment, newer version available

It started by wanting to pass a program to FDBG on the command line, but then I decided to use the wide character strings. Mainly because I didn't want to code another command line parser with it's own set of "features" - kind of used to the problems with CommandLineToArgvW.

Currently, figuring on calling CMD_OPEN and using a flag to conditionally jump over the OFN code.

Thanks bitRAKE, that's good improvement. I was thinking about passing a debuggee name through command line years ago but because of my laziness, lack of time and a lot of other activities, I have never implemented that. I remember only that I did something to avoid the necessity of clicking on an executable again if it terminates and you want to run it again as a debuggee - the name of program stays in memory so if you open a new debuggee (Ctrl-E) and you press Enter only, the previously terminated program is loaded again as a debuggee (this saves some time if somebody is doing intensively programming and needs to debug a program being developped hundreds of times).

The way I learnt assembler there wasn't a separation between the debugger and the editor.

This patch works until I convert more to use wide characters.
Try it cannonically for fun,

fdbg.exe -e fdbg.exe -a "-d -e fdbg.exe -a \"-d\"" Now I can press F9 Ctrl-E {return} from editor and be debugging.

Hi bitRAKE.
I tried to implement that. Sorry, the implemented command line parser is only very simple and not so good and sophiscticated as your design... Implementing the command line support is done easier than hacking cmd_open proc. It is done at the end of the WM_CREATE proc - the command line is parsed and if there is a choice to launch a debuggee then CreateThread is invoked with DbgThreadStartAddr.
I did few tests and it seems to work well. But the number of paths and managing them (splitting, merging) was quite high, so there may be silent mistakes.
1 known problem for me is caused by the behaviour of OFN dialog.

imagine this - you copy fdbg.exe into c:\windows directory and you open command prompt and point it at path e.g. d:\fasmprog
there is a directory fdbg001D in the d:\fasmprog and fdbg001D directory contains fdisasm.exe and fxa16.exe files so the full paths for both executables are:
d:\fasmprog\fdbg001D\fdisasm.exe
d:\fasmprog\fdbg001D\fxa16.exe

now you invoke the debugger from the command prompt from the path d:\fasmprog using this command:

fdbg fdbg001D\fdisasm.exe fdbg001D\fxa16.exe

(it launches fdbg.exe copied into c:\windows dir and fdbg loads a debuggee d:\fasmprog\fdbg001D\fdisasm.exe, fdisasm.exe takes command line argument fdbg001D\fxa16.exe which points to a file d:\fasmprog\fdbg001D\fxa16.exe)

now everything works and you can debug disassembling (fdisasm.exe) of the file fxa16.exe

restarting it works well (Ctrl-R)
if the program terminates, then you can exit fdbg (Alt-X) and invoke the same command again:
fdbg fdbg001D\fdisasm.exe fdbg001D\fxa16.exe

but !
if you want to reload the debuggee after it terminates (F9 run etc...) using the open debuggee command (Ctrl-E), then open file dialog changes the path from d:\fasmprog\ to d:\fasmprog\fdbg001D\
(open file dialog cannot load executable as fdbg001D\fdisasm.exe but it cuts the directory fdbg001D and puts it at the end of original path d:\fasmprog so now the path is d:\fasmprog\fdbg001D and executable fdisasm.exe is loaded correctly but without the preceeding fdbg001D\. Now the arguments put to fdisasm.exe don't have that updated (in fact messed is better word) so now fdisasm.exe fails to accept input params because it input is wrong so you had to manually delete the fdbg001D\ from the arguments Edit control and leave only fxa16.exe there to have success.

This brokes a bit the automation I wanted to implement.
If in the above sample you invoke fdisasm.exe from its directory, e.g. command prompt is at path
d:\fasmprog\fdbg001D and the shell line is then
fdbg fdisasm.exe fxa16.exe
then there is no problem at all. The problem is only if there is a partial path preceeding the debuggee (fdbg001D\fdisasm.exe).

the cmd line switches are:
-d (stays the same as in previous versions)
2 new params do the same as checking/unchecking 2 checkboxes in OFN:
-n (stop at ntdll.DbgBreakPoint instead of OEP, you can put breakpoint manually at program entry point, it is in the Log window as threadstartaddress=xxxxx)
-t debug only this process (exclude children, debug loop won't intercept exceptions from children processes, it will intercept only exceptions from the process being debugged)
mnemonic is D=default, N=ntdll, T=this (only this process)
switches must follow the fdbg immediatally in any order, then debuggee name and then arguments for debuggee (debuggee will get them using GetCommandLine)

OK, so have a fun, here is the present, that new-year edition. Stress-testing is welcome. Let me know in any case of problems. There is no need to update from ver 001C to 001D if you don't need the command line support.

edit 2009-07-13
deleted attachment, newer version available

Open File Dialog crashes on Windows 7 (beta): ...error occurs when changing directories with the drop down, or navigating buttons. This is not related to recent commandline changes - errors in both versions.

My current work around is to type a valid path into the file name edit field. For example, "D:" to change to the D drive. Otherwise there is no way to navigate between drives.

the addr is 000007FEFDAFAB7D which looks like inside of a DLL
fdbg virtual address in somewhere in range 0000000100000000-0000000100xxxxxx
sometimes, crashes occure in DLL if there is a stack misalignment in the app e.g. if RSP is something like 6F018h instead of correct 6F010h, e.g. such procedure:
sub rsp,20h
...
call [MessageBox]
fails inside DLL

the included fxa16.exe checks these "silent bombs" by counting the number of pushed registers with the value subtracted from RSP at procedure prologue

I'll try to download the win7 and test it.

I remembered just now, years ago I produced some executables with damaged resource section and then fdbg crashed when pointing the OFN to the directory containg such damaged executable.
The interesting fact was that simple OFN didn't crash. But fdbg OFN has a hook to extend the default OFN (to have an extra edit control to input command line args and 2 extra checkboxes), perhaps the problem is there.

I've re-written both the hook and the proceedure and I can't find anything wrong with either. ...limits the update of options - instead of on every notify.

It only crashes when the directory is symbolic (My Computer). Maybe this is MS's way of pushing developers to the IFileDialog interface? I can't find another program that even creates the same OpenFileDialog (minus the added options, of course) that fdbg invokes (strange how MS converts the old usage to use the new interface in most cases).

OK, here is it.
Now let it run forever.

edit from 2009-11-18: deleted the attachment, newer version available

Thank you very much.

Hi Feryno,

I'm using your great debugger!

I was wondering if it's possible for you to add a feature in the Data window to display data as BYTE, WORD, DWORD, QWORD. Currently, you just display it as QWORD but as you might know not all our expected structures in memory are QWORD

Keep up the good work!

Sometimes the DIV/MUL instructions do not display the correct register. For example: MUL R8 will show as MUL RAX in the disassembly.

bitRAKE, thanks for your report, I'll fix that
the same is with e.g. TEST R8B,... instruction
DIV/MUL and TEST problems are because of mistake in analyzing of the REX prefix
I started to implement the idea posted by alorent, but I had only 2-3 free hours to do that since his post (currently not more than 1/3 of the necessary work is done)

to fix the disasm problem, you can update the file from attachment and recompile fdbg

edit from 2009-11-18: deleted the attachment, newer version available