Under Windows 11, notepad.exe has been migrated into the UWP framework,
and can no longer be launched as a 32bit process:
- even if c:\windows\syswow64\notepad.exe is still a 32 bit PE file
- the process created from c:\windows\syswow64\notepad.exe is not a
wow64 process.
So use msinfo32.exe instead. Like notepad.exe, it's a gui application,
present on Wine and all test-bot:ed windows platforms. But unlike
notepad.exe, it's not an UWP app on Windows 11.
(May not fully fix all the bugs below, but will get rid of a bunch
of errors).
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54535
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54536
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54537
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
- should have been fixed when libwine.so has been removed
- code was broken anyway
- enhanced protect against error when reading debuggee's memory
Introducing helper to correctly read pointer's from debuggee
(and other integral values).
vdso is now listed in ELF's module list (except if Wine's preloader
removes it from auxilary vector)
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
For dbghelp in 32-bit, when accessing a live debuggee in multi-arch
configuration, Wine's ELF loader is likely mapped above 4G, hence
not accessible with 32bit Windows APIs.
So don't try to expose the ELF libraries in that case.
Introducing a new loader operation class to support live targets, for
which system operations are not accessible, but pretending they are
successful.
Note:
- when Wine's loader ELF module isn't registered by dbghelp,
any other ELF module will not be registered by dbghelp.
- further work may be needed for winedbg in auto mode (launched with
AeDebug key on process exception) as in that mode winedbg
doesn't relaunch itself in 64bit, so won't be able to access
(64bit) ELF information (in multi-arch configuration).
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Since this API sporadically fails with STATUS_INFO_LENGTH_MISMATCH
as GetLastError() (sic!) on Windows 11, retrying the call let us get
the relevant output.
No clear explanation of the cause of the failure, it's maybe generated
when modules are still loaded into child process and it detects
modification of the modules' list while enumerating all modules.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Even is MSDN states that it enumerates modules' name, the first parameter
to the callback is the fullpath to the image.
So
- fix EnumerateLoadedModules() to pass the image name for the
considered module
- fix all callbacks in Wine code to EnumerateLoadedModules to
handle the image name instead of module name
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Note: from now on, winedbg will 'see' the ELF 64 bit modules (not yet
the PE ones) in multi-arch wow64 use case.
Modules can be displayed in 'info wow share' command and their debug
information is loaded.
Stack manipulation and backtracking are not available.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
SYMOPT_INCLUDE_32BIT_MODULES option applies when enumerating
loaded modules, but not when actually loading debug information for
a module.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Transform potential error on 32 => 64 bit transition with
end of stack (needed in new wow64 for dbghelp's stackwalk tests).
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
The ranges describe for a PE image all the contributions
of each compilation unit towards the various sections.
Renaming offset_size into ranges_size which is closer to its actual content.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Try to apply consistent naming:
- file refers to (PDB) file
- stream refers to a stream/file inside the PDB stream at MSF level
(we were also using file for the later, which isn't very simple to
follow).
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Expose the real path of a loaded module (potentially read from
WINEDLLDIR or WINEBUILDDIR or overriden load order or ...). This
improves gdb integration by passing the real path to the loaded
modules (instead of the paths in c:\windows\ system subdirectories).
Introduce new Wine only dbghelp's extended option to enable the
feature.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54250
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
When the handle to the loaded module is passed in SymLoadModule*(),
don't try to search for the module's image path and use only the file
handle.
Co-authored-by: Ake Rehnman <ake.rehnman@gmail.com>
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Replacing symt_get_inlinesite_depth() with SymAddrIncludeInlineTrace()
as they look very (very) similar.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
