CDbg»Forums
10 posts
Custom Entry Point Procedure Not Found
Edited by SedatedSnail on Reason: Initial post
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
Nikita Smith
45 posts / 1 project
None
Custom Entry Point Procedure Not Found
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


I have been told about the custom entry-point issue already. Unfortunately, PDB does not contain any info about entry point, I guess this is because definition of an entry point is arbitrary. Currently debugger has an internal list of entry point names that it will try to find in the debugged program, but this behavior was changed for next build where you can use config file to define your entry point.

Thanks for telling me about the issues, I will look into them later.
17 posts
Custom Entry Point Procedure Not Found
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.
511 posts
Custom Entry Point Procedure Not Found
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.


Actual entry point being the fallback when no main() variant is found is probably the best option.
Nikita Smith
45 posts / 1 project
None
Custom Entry Point Procedure Not Found
Edited by Nikita Smith on
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.
Yes, NT header has address for the entry point, you can find it here "address_of_entry_point".

 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;


However, this address points to "_WinMainCRTStartup" procedure which down the line calls "main", "WinMain", or other arbitrary name. PDB does not flag procedure that can be an entry point. At this point I don't have a better solution other than just iterate a predefined list of entry point names and try to find it in the PDB.
17 posts
Custom Entry Point Procedure Not Found
What ratchetfreak and I were sugesting was that you fall back to the debugger stepping into the CRTs entry point if you can't find a "proper" main function. Being to able to force this behaviour as a user would also be nice for when one actually wants to look at what the CRT is doing.
511 posts
Custom Entry Point Procedure Not Found
and breaking on entry point (maybe with warning) allows the user a chance to look for the main function and put in a break manually.