On Thu Oct 23 17:26:48 2025 +0000, Alex Henrie wrote:
The program calls SymEnumSymbols to get the list of functions in memory, then it compiles some C code, injects it, and links it to those functions. If it can't find the symbol it's looking for, the linker step fails. The function names returned from SymEnumSymbols have to match what they would be on real Windows.
hmm kinda strange...
does SymEnumSymbols() on native return an actual name for the (internal) functions different from the exported one?
(it's more likely, that even when using the MS symbol store, the .pdb for the system modules don't contain all these details, and dbghelp ends up building the symbol's table for the module with the only info available == the PE export table)
or does the program filters on dbghelp for public symbol only ? (SYMOPT_PUBLIC_ONLY in SymSetOption()?) that's not currently supported in builtin's dbghelp and could explain some mixups