Skip to content

Conversation

@supervacuus
Copy link
Collaborator

@supervacuus supervacuus commented Sep 24, 2025

Fixes the primary aspect of #1388.

Instead of using the dbghelper interfaces with the A suffix, which rely on compatible code page settings downstream, we use the wide-char variants and convert them to narrow UTF-8. This completely isolates symbols and paths from any system ANSI code page.

The modulefinder was also affected by this in that the szExePath of MODULEENTRY32W, while storing wide-characters, actually appeared with all CP-foreign characters being replaced with 0x3f.

While logically those two aren't connected inside the SDK, they do overlap in the processing pipeline:

  • processing will replace frame packages with the code file of an image if the instruction address can be found within its address bounds
  • if there is no image provided where a frame's instruction address would fit (for instance, because LoadLibrary couldn't find a library due to a mangled path coming in from szExePath), it would accept the package as provided by the frame
  • so, if the modulefinder had worked correctly, the problem in the frame packages would have remained hidden, but because the modules didn't load either, we could see the invalid paths from the symbolication

Further changes:

  • ensure that we use PSAPI_VERSION == 2, since we only link kernel32
  • ensure that module finder and symbolizer on Windows assume paths of length 32767 for modules and symbol records.

cursor[bot]

This comment was marked as outdated.

cursor[bot]

This comment was marked as outdated.

The szExePath generated for actual UTF-8 paths was already filled with mojibake :-) so LoadLibrary couldn't find any local modules.

This is actually connected to the symbolication:

* in the server, if a module was found, the backend would assign packages to frames based on the instruction address and the module address range
* if the module couldn't be found, as was the case previously, it had to use the frame package provided

So, now we fixed both and they should overlap.
@supervacuus supervacuus changed the title fix(win): make symbolication independent of the system ANSI code page. fix(win): make symbolication and modulefinder independent of the system ANSI code page. Sep 25, 2025
Copy link
Member

@JoshuaMoelans JoshuaMoelans left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm!

cursor[bot]

This comment was marked as outdated.

cursor[bot]

This comment was marked as outdated.

@supervacuus supervacuus merged commit 1af38cc into master Oct 1, 2025
41 checks passed
@supervacuus supervacuus deleted the fix/remove-apc-dependency-windows-symbolication branch October 1, 2025 17:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants