May 23, 2022
12:04 p.m.
On Mon May 23 12:04:35 2022 +0000, eric pouech wrote: > > of Unix modules. Specifically, dbghelp attempts to fetch it from the > > WoW64 PEB although it actually resides in the native PEB. > Actually, getting back to the correct 'base address' should be taken > care of in previous lines of check_live_target > So I'd say we'd better fix the reason for not getting to the base > address (if needed). > can you describe further: > - are you trying to debug an active process (or not)? > - is debuggee 32bit or 64bit? > - is dbghelp 32 or 64bit? > Notes: > - 32bit dbghelp will not be able to handle 64bit processes, so I hope > it's not what you're trying to do > - 64bit dbgjelp is able to load 32bit process only if > SYMOPT_INCLUDE_32BIT_MODULES is set in options before loading the > relevant modules (so before SymInitialize when fInvade is TRUE) > > However, this shouldn't be a reason to give up initializing dbghelp > > entirely. We do not expect a "user-mode" debugger to be able to debug > > Unix-side modules in a WoW64 process anyway. > why wouldn't we (at least for the 64bit version of dbghelp)? > are you trying to debug an active process (or not)? Yes, I'm trying to debug an active process. > is debuggee 32bit or 64bit? 32bit, Wow64 *proper*. (Of course, this means that the bug cannot be triggered without modification to upstream code.) > is dbghelp 32 or 64bit? 64bit. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/112#note_1098