"SymGetLineFromAddr64(...) fails with "487",...

[Kerem Gümrükcü]

Hi,

for Information purposes:

OS is WIndows XP Up2Date:
File is: dbghelp.dll, Version: 6.9.0003.113 (debuggers(dbg).080320-1813)

Well is start debugging a newly created process which
calls DbgBreakPoint internally. My debugger application
traps into the EXCEPTION_DEBUG_EVENT (FirstChance)
and then delivers the Exception to a function which should show
details about the exception. The Information should show the Exception
Address, the regarding call thats responsible for it and the Source
Line and Number if available. The helper function behaves like that
and calls this order of functions:

SymSetOptions(SYMOPT_UNDNAME|
SYMOPT_LOAD_LINES|
SYMOPT_LOAD_ANYTHING|
SYMOPT_DEFERRED_LOADS); // successfully

SymInitialize(...) //successfully

SymGetSymFromAddr64(...) //successfully, retuns valid address and
"DbgBreakPoint"
SymGetLineFromAddr64(...) fails with 487, something like accessing invalid
memory space
The handle to the process is vallid and the same one used fo
"SymGetSymFromAddr64".
The second parameter is "lpde->u.Exception.ExceptionRecord.ExceptionAddress"
where
"lpde" is apointer to a "DEBUG_EVENT", third param is "0" and fourth param
is a buffer holding
enough space for "IMAGEHLP_SYMBOL64". So why does the call fail with
"487",...

I want the Source Line, the exception Module name and the Source file name
to
be shown on my output, which caused the problem,...
My Application comes with a full PDB File containing every information
possible,...

Regards

Kerem

--
-----------------------
Beste Grüsse / Best regards / Votre bien devoue
Kerem Gümrükcü
Microsoft Live Space: http://kerem-g.spaces.live.com/
Latest Open-Source Projects: http://entwicklung.junetz.de
-----------------------
"This reply is provided as is, without warranty express or implied."

[Pavel A.]

In your test app, replace DbgBreakPoint with __debugbreak().
Will SymGetSymFromAddr64 work then?

(removed non-relevant newsgroups from followback)

--PA

"Kerem Gümrükcü" <kare...@hotmail.com> wrote in message
news:uLOBk4a...@TK2MSFTNGP04.phx.gbl...

[Alex]

But dont forget those in the other groups :), they might be interested
the answer as well .... hence readded the groups but with a follow up to
microsoft.public.win32.programmer.kernel

[Gerard O'Brien]

SymGetLineFromAddr64 expects an initialised line info buffer of the
correct size. The type would be IMAGEHELP_LINE64. An ansi only example
invocation could be

IMAGEHLP_LINE64 lineInfo = { sizeof(IMAGEHLP_LINE64) };
DWORD dwLineDisplacement = 0;
if (SymGetLineFromAddr64(hProcess, address, &dwLineDisplacement,
&lineInfo))
// do stuff

[Kerem Gümrükcü]

Hi Gerard,

i allocate memory of sizeof(IMAGEHLP_LINE64) + SYM_MAX_LEN
where SYM_MAX_LEN is 2000 defined in the Header. You will ask
why SYM_MAX_LEN, because the size of the memory block also is exactly
a size i need for another operation. Even i got more memory as it needs, it
fails.
I also tried a one with a exact memory size as expected, butit failed too.
I think it is the address i try to use with the call. My application shows
you this.

//a lot of debugging events....
...
...
...

LOAD_DLL_DEBUG_EVENT
Dll Base Address: 2120679424
Dll Debug Info File Offset: 0
Dll Debug Info Size: 0
Dll File Handle: 1872

//stop here and handle it!
EXCEPTION_DEBUG_EVENT
Is First Chance Exception: 1
Type of Exception: EXCEPTION_BREAKPOINT
Exception Address: 2089882160

Please select what to do:

Continue Debugging = [ENTER/SPACE]
Quit Debugging (Detach) = [0]
Quit Debugging (Kill) = [1]
Create Minidump = [2]
Show Debugging Symbol Information (Only if Available!)= [3]

Retrieving Symbol and Exception Information if possible:

Exception raised in Address: 2089882160
Exception raised in Function: DbgBreakPoint

// This is where i call the SymGetLineFromAddr64
//an then i get the error caught by my error handler.

Error: SymGetLineFromAddr64 failed. Reason: 487
User Context: LINWIN-DEV\Administrator
User SID: *************************
Detail: Es wurde versucht, auf eine unzulõssige Adresse zuzugreifen. (487)

Press any Key to Continue...

I think, the supplied Exception Address is the problem,...but why.

Regards

Kerem

--

--
-----------------------
Beste Grüsse / Best regards / Votre bien devoue
Kerem Gümrükcü
Microsoft Live Space: http://kerem-g.spaces.live.com/
Latest Open-Source Projects: http://entwicklung.junetz.de
-----------------------
"This reply is provided as is, without warranty express or implied."

"Gerard O'Brien" <gob...@jadeworld.com> schrieb im Newsbeitrag
news:uA0AVufu...@TK2MSFTNGP02.phx.gbl...

[Gerard O'Brien]

Are you processing the first breakpoint exception?

Here are some notes on how the system/debugger interact during attach.

The system sends a single CREATE_PROCESS_DEBUG_EVENT that represents
the process attached to.
Then, for each thread in the process, the system sends a
CREATE_THREAD_DEBUG_EVENT.
Then, for each dll loaded, the system sends a LOAD_DLL_DEBUG_EVENT.
Then, the system injects a breakpoint instruction into the first
thread in the process to cause it to break when it resumes.
Then, the system resumes all threads in the process and the first
thread executes the breakpoint instruction that causes a breakpoint
EXCEPTION_DEBUG_EVENT debugging event to be sent.
After that any further debugging events are sent using the normal
mechanism and rules.

When the first breakpoint EXCEPTION_DEBUG_EVENT is seen, signal the
aedebug event and allow the debugee to continue. The debugger will then
get an
EXCEPTION_DEBUG_EVENT for the exception that is unhandled.

Kerem Gümrükcü wrote:
> Hi Gerard,
>
> i allocate memory of sizeof(IMAGEHLP_LINE64) + SYM_MAX_LEN
> where SYM_MAX_LEN is 2000 defined in the Header. You will ask
> why SYM_MAX_LEN, because the size of the memory block also is exactly
> a size i need for another operation. Even i got more memory as it needs, it
> fails.
> I also tried a one with a exact memory size as expected, butit failed too.
> I think it is the address i try to use with the call. My application shows
> you this.
>
> //a lot of debugging events....
> ....
> ....

> ....