BCB5 debugger won't work under XP

1 view
Skip to first unread message

Michael Kelley

unread,
Dec 3, 2003, 5:13:10 PM12/3/03
to
Anybody able to use the bcb5 debugger under XP and hit breakpoints. When I
start running a fresh debug build executable, I don't get the blue dots next
to each statement and breakpoints don't work. Is the debugging support
needed under XP so different than Win2K that bcb6 is the only choice?
-Mike


Michael Kelley

unread,
Dec 3, 2003, 5:37:05 PM12/3/03
to
I blew away the *.dsk file and things appear to be OK. This was the first
time trying to debug on an XP machine and for some reason members of my
development staff thought the the *.dsk file should be checked into our SCM
system. Setting belonging to another machine (source paths to nonexistent
drives, etc) apparently make all the difference.

Dennis Jones

unread,
Dec 4, 2003, 1:08:02 PM12/4/03
to

"Michael Kelley" <mke...@imail.com> wrote in message
news:3fce6593$1...@newsgroups.borland.com...

There's more to it than that. As I understand it, the problem has something
to do with how XP loads DLL's into memory when it has to re-base them due to
conflicting image base addresses. I've seen this problem much more often
when every DLL in a project is based at the same address (0x400000 is the
linker default for DLL's and EXE's). By changing the DLL base addresses to
be more or less unique from the EXE and each other, this problem occurs much
less often.

If you don't want to change your DLL image base addresses, or if the problem
occurs anyway, you can still work around the problem:

1) Once your program is running, open the Modules window (Ctrl+Alt+M)
2) Find the module whose debug information is missing, and right-click on it
to get the popup menu
3) Choose "Reload Symbol Table" and select the appropriate .TDS file for
that module

- Dennis


Maurice Barnum

unread,
Dec 4, 2003, 1:53:26 PM12/4/03
to
> "Michael Kelley" <mke...@imail.com> wrote in message
> news:3fce6593$1...@newsgroups.borland.com...
>> I blew away the *.dsk file and things appear to be OK. This was the first
>> time trying to debug on an XP machine and for some reason members of my
>> development staff thought the the *.dsk file should be checked into our
> SCM
>> system. Setting belonging to another machine (source paths to nonexistent
>> drives, etc) apparently make all the difference.
>
> There's more to it than that. As I understand it, the problem has something
> to do with how XP loads DLL's into memory when it has to re-base them due to
> conflicting image base addresses. I've seen this problem much more often
> when every DLL in a project is based at the same address (0x400000 is the
> linker default for DLL's and EXE's). By changing the DLL base addresses to
> be more or less unique from the EXE and each other, this problem occurs much
> less often.

i think the original poster's problem was something more basic if
blowing away ide/tool droppings made it better. also, the report indicated
that some symbolic information was available, but some wasn't.

regarding the dll base adddress problem: on XP, what happens is that
if the dll is relocated the debugger api fails to give us the path
(documentation already says "path may not be available" and now it
isn't. grr..). without the path, we can't find the symbols, so no debug
info.

later revs (delphi6+? i forget precisely) of the debugger have a
workaround for this issue.

--xmsb

Reply all
Reply to author
Forward
0 new messages