1

extern "C" void __stdcall Entry();

Executable Path = C:\Dev\Game_Project\Files\cdbg\cdbg64.exe"
Working Directory = C:\Dev\Game_Project\Files\cdbg\

file "w:\\dbg\\code\\win64_tracer.c", line 1391.

SedatedSnail
I'm using a custom defined entry point:

1	extern "C" void __stdcall Entry();

When I press f11 to start/step into, It gives the message "Entry point procedure was not found!", and does not break.
I'm working around it by using "fbreak Entry", but it is a bit tedious to type every time I start debugging.

Is there some easier way in the current build to break at entry?
I thought saving the current session might save the breakpoint, but I can't figure out how to load the session again.

Thanks for doing this project, it has been great to use.

A few smaller things:
When launching the debugger from a director that is not the directory where the debugger is installed, the launch settings paths are not correctly set:

Executable Path = C:\Dev\Game_Project\Files\cdbg\cdbg64.exe"
Working Directory = C:\Dev\Game_Project\Files\cdbg\

This path doesn't exist; it is the install dir path being over written by the path the debugger was launched from.
The launch path is "C:\Dev\Game_Project", and the install path is "C:\Program Files\cdbg".
They have been fused into one Frankenstein's path "C:\Dev\Game_Project\Files\cdbg\".
It looks like you forgot to update the string length or null terminator or something.

Another thing, when exiting the program while the debugger is attached, it panics on invalid code path,

file "w:\\dbg\\code\\win64_tracer.c", line 1391.

Also, the debugger used to prompt me to select an executable at launch, but it seems to have stopped doing that now.
I don't know if you updated it since last time I downloaded it. I just thought I'd mention it, because the behavior had changed but the version number hadn't.

-Thanks

seventh-chord
Executables actually contain information about where in memory the entry point (i.e. the first instruction of the main function) lies. If you have a list of functions with info about where in memory the code for each function lies, you can map back from the entry point instruction address to a function, and break on entry to that function. You probably don't want to do this by default though, because it means users would have to step through the c-std-library before getting to their own main function.

seventh-chord
Executables actually contain information about where in memory the entry point (i.e. the first instruction of the main function) lies. If you have a list of functions with info about where in memory the code for each function lies, you can map back from the entry point instruction address to a function, and break on entry to that function. You probably don't want to do this by default though, because it means users would have to step through the c-std-library before getting to their own main function.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

typedef struct nt_image_opt_header64 {
    u16 magic;
    u08 major_linker_version;
    u08 minor_linker_version;
    u32 sizeof_code;
    u32 sizeof_inited_data;
    u32 sizeof_uninited_data;
    u32 address_of_entry_point;
    u32 base_of_code;
    u64 image_base;
    u32 section_alignment;
    u32 file_alignment;
    u16 major_operating_system_version;
    u16 minor_operating_system_version;
    u16 major_image_version;
    u16 minor_image_version;
    u16 major_subsystem_version;
    u16 minor_subsystem_version;
    u32 win32_version_value;
    u32 sizeof_image;
    u32 sizeof_headers;
    u32 check_sum;
    u16 subsystem;
    u16 dll_characteristics;
    u64 sizeof_stack_reserve;
    u64 sizeof_stack_commit;
    u64 sizeof_heap_reserve;
    u64 sizeof_heap_commit;
    u32 loader_flags;
    u32 number_of_rva_and_sizes;
    struct nt_image_data_dir data_directory[NT_IMAGE_DIRECTORY_ENTRIES_COUNT];
} nt_image_opt_header64_t;