I am using OllyDbg to debug a Borland BCB6 program I am working on. In another thread I mentioned that I can't get Olly to find any of my source files, and even with the generous help of others here have still not been able to solve this issue.

Today I discovered the "Log data" window (I've still got a lot to learn about Olly!), and perhaps the cause of my source code problem. In that window I find an error message:

> New process with ID 00000994 created
> 00402DF4 Main thread with ID 00000C40 created
> 00400000 Module PwrMon.exe
> Debugging information (Borland format) available
> Line 2: Syntax error in ' "" PTR'

PwrMon.exe is my program. I see that Olly correctly finds that I have built the project with debug info and identifies the format correctly. Then it reports a syntax error in line 2, but doesn't indicate which file contains the error.

Since the error message refers to a line number, it must be having a problem with a text file, no? But I've searched my .map file and find nothing of the form indicated in the error message. Then I used FileLocator Pro to grep through every file in my project (even binary files) and find no matches to the offending string.

Can someone tell me how Olly goes about locating debug info? Is it read from the .map file? Is it read from the .tds file?

Most importantly, how can I fix this problem?

Thanks,
Leroy

well i dont know but i use windows search for text mostly to find some strings in any files it almost always works
start -->search-->files or folders--->containing text PTR
you need to parse a little but it will list all files that has the string ptr i dunno about filepro so cant comment on its usage

or if this fails i use the dos find.exe
cd\
cd "your path"
find /i "ptr" *.* > results.txt

oh me anon, do yourself a favor and check out FileLocator Pro. Its name doesn't reflect its function - best windows grep I've seen:

http://www.mythicsoft.com/default.aspx
("http://www.mythicsoft.com/default.aspx
")

$12.99 US

hehe you named it differently
why didnt you say ransack ,well i have ransacked a lot
yeah pretty good especially when the file is system and hidden and read only like most of virii out there

well i thought of editing the post above but i will make a new one since it covers lot of ground
btw just since i didnt understand why some thing didnt work

i downloaded the bcb 5.5 free commandline tools and searched through google to find a tut

here is the tut i followed to create my first c++ program

http://www.webnotes.org/bcc55eng.htm


here is the dbghello.cpp in c:\borland\testdos
#include <stdio.h>

int main ()
{
printf("helloworld";
return 0;
}

i used this to compile it
c:&#92;borland&#92;testdos>bcc32 -v hellodbg

C:&#92;Borland&#92;testdos>bcc32 -v hellodbg
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
dbghello.cpp:
Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland

C:&#92;Borland&#92;testdos>

well it created three files
1)hellodbg.exe
2)hellodbg.obj
3)hellodng.tds

so i opened the hellodbg.exe in ollydbg
here is the dissembly




here is my log details
Console file 'C:&#92;Borland&#92;testdos&#92;dbghello.exe'
New process with ID 000002CC created
00401000 Main thread with ID 00000114 created
00400000 Module C:&#92;Borland&#92;testdos&#92;dbghello.exe
Debugging information (Borland format) available
77E10000 Module C:&#92;WINNT&#92;system32&#92;USER32.DLL
77E80000 Module C:&#92;WINNT&#92;system32&#92;KERNEL32.DLL
77F40000 Module C:&#92;WINNT&#92;system32&#92;GDI32.DLL
77F80000 Module C:&#92;WINNT&#92;System32&#92;ntdll.dll
75E60000 Module C:&#92;WINNT&#92;System32&#92;IMM32.DLL
77DB0000 Module C:&#92;WINNT&#92;system32&#92;ADVAPI32.DLL
00401150 Main program



here is the source it shows
in cpu pane
EBP=0012FFB8
dbghello.cpp:3. int main ()

if i use ctrl+f5 i can see that the cursor is positioned in line no 3


here is the call stack details
Call stack of main thread, item 0
Address=0012FF90
Stack=00407C8E
Procedure / arguments=Maybe dbghello.main
Called from=dbghello.__startup+16F
Frame=0012FFB8


here is obj file scan results in analyse
Unnamed window
Object file Group Scanning results
dbghello.obj 1 No matches


so i think olly properly recognises .tds file and also shows the source without problems there is no need for .pdb files as i believed or any .map files may be only the .tds file is enough

and line nos may be the line nos in your source code
i cant attach a photo here else i would have attached a screenshot
here



PS SO AFTER I POSTED THIS I ASLO TESTED A MSG BOX (TEST WIN)
with this bcc32 -tW -v
and loaded it in olly bingo i see the source

EBP=0012FFB8
hellodbg.cpp:4. WINAPI WinMain (HINSTANCE hInstance,HINSTANCE hPrevInstance,LPSTR lpCmdLine,int nCmdShow)
and it recognises that .tds file
Log data, item 14
Message= Debugging information (Borland format) available
and the cursor is on line 3 in source window

and i view filed the hellodbg.tds
and i see it holding information like this
header
00000000 FB0A.................

.Ð..L...
...L...%
.P..~..'
.
00000040 ..F...)
.. ”.0..+
.. 4..Æ..0
.. „..Œ........

*********************************************

000018B0 ..ˆ
..‰
...
.
.BCC32 5.5.1.......CV
...................
.
.


***********************************************

000023F0 .....................ï......c0ntw.asm..hellodbg.cpp.HINSTANCE_
00002430 _.unused.WinMain..hInstance..hPrevInstance..lpCmdLine.nCmdSho
00002470 w.HWND__.MessageBoxA.std.@std@size_t.@std@ptrdiff_t.@std@w
000024B0 int_t..@std@wctype_t.ULONG.USHORT.UCHAR.PSZ.DWORD.BOOL.BY
000024F0 TE.WORD.FLOAT.INT.UINT.POINTER_64_INT.LONG32.INT32.ULONG
00002530 32.DWORD32.UINT32.INT_PTR.UINT_PTR.LONG_PTR..ULONG_PTR..UHA
00002570 LF_PTR.HALF_PTR..HANDLE_PTR.SIZE_T.SSIZE_T..DWORD_PTR.LONG64
000025B0 .INT64.ULONG64.DWORD64.UINT64.CHAR.SHORT.LONG.WCHAR.PCH
000025F0 AR.LPCH.PCH.LPCCH.PCCH.NPSTR.LPSTR.PSTR.LPCSTR.PCSTR.T

*************************************************
0000BC30 _array&#036;ui%@&#036;bdtr&#036;qv.þ@__rwstd@%__rb_tree&#036;i75std@%pair&#036;xi60std@%b
0000BC70 asic_string&#036;c19std@%char_traits&#036;c%17std@%allocator&#036;c%%%100__rwst
0000BCB0 d@%__select1st&#036;75std@%pair&#036;xi60std@%basic_string&#036;c19std@%char_tr
0000BCF0 aits&#036;c%17std@%allocator&#036;c%%%i%12std@%less&#036;i%93std@%allocator&#036;75s
0000BD30 td@%pair&#036;xi60stWZrH.þ@__rwstd@%__rb_tree&#036;i75std@%pair&#036;xi60std@%b
0000BD70 asic_string&#036;c19std@%char_traits&#036;c%17std@%allocator&#036;c%%%100__rwst

*********************************
end of file
0005FFF0 ........FB0A...

Thanks for your help. No need to attach a photo, I believe it works for you<g>. From your log file:

> Console file 'C:&#92;Borland&#92;testdos&#92;dbghello.exe'
> New process with ID 000002CC created
> 00401000 Main thread with ID 00000114 created
> 00400000 Module C:&#92;Borland&#92;testdos&#92;dbghello.exe
> Debugging information (Borland format) available
---- I get an error message here in my log file --------
> 77E10000 Module C:&#92;WINNT&#92;system32&#92;USER32.DLL

Now from my log file:

> New process with ID 00000994 created
> 00402DF4 Main thread with ID 00000C40 created
> 00400000 Module PwrMon.exe
> Debugging information (Borland format) available
> Line 2: Syntax error in ' "" PTR'

Your log doesn't have the syntax error after Olly reports finding debug info. Mine does. I expect this is the reason that I don't get source file integration.

My question is: How do I track down the error message I find in my log file? I should point out that my TDS file is a bit over 20MB so perhaps size is an issue. Also, since TDS files are binary, it seems strange that the error message refers to a line number.

I hope you (or someone) has a suggestion as to how I work out this error. OllyDbg is a great addition to my programming toolkit - it would be even better if I could integrate my source files.

well i tried a scanf,printf combo
and to my limited knowledge the line nos point to your source line numbers like i already posted

00401150 >/. 55 PUSH EBP

EBP=0012FFB8
dbghe1.cpp:2. int main ()

00401154 |. 8D45 FF LEA EAX,DWORD PTR SS:[EBP-1]

Stack address=0012FFB7
EAX=00000001
dbghe1.cpp:5. scanf("%s",&v);

00401165 |. 8D55 FF LEA EDX,DWORD PTR SS:[EBP-1]

Stack address=0012FFB7
EDX=00792570
dbghe1.cpp:6. printf("hello %s",&v);

00401176 |. 33C0 XOR EAX,EAX

EAX=00000001
dbghe1.cpp:7. return 0;

0040117A &#92;. C3 RETN

Return to 0040AB06 (dbghe1.0040AB06)
dbghe1.cpp:8. }



i also tried using the td32 debugger
here is the equivalent that it shows
main: int main ()
:00401150 55 push ebp
:00401151 8BEC mov ebp,esp
:00401153 51 push ecx
#dbghe1#5: scanf("%s",&v);
:00401154 8D45FF lea eax,[ebp-01]
:00401157 50 push eax
:00401158 6834D14000 push 0040D134
:0040115D►E86E2C0000 call scanf
:00401162 83C408 add esp,00000008
#dbghe1#6: printf("hello %s",&v);
:00401165 8D55FF lea edx,[ebp-01]
:00401168 52 push edx
:00401169 6837D14000 push 0040D137
:0040116E E8392C0000 call printf
:00401173 83C408 add esp,00000008
#dbghe1#7: return 0;

I don’t doubt that this works fine for you. I expect that I would get the same results if Olly didn’t throw an error while it was (apparently) reading my TDS file. I have verified that Olly is indeed finding and reading my TDS file, so that isn’t the problem.

I’m trying to find a way to work around the error that is preventing Olly from reading in the symbolic information that allows it to relate an EIP address to a source line number.

It might be that BCB6 uses a different TDS format than the BCB5 (free) compiler and that is leading to the error in reading my debug info into Olly.

It might be that BCB6 uses a different TDS format than the BCB5 (free) compiler and that is leading to the error in reading my debug info into Olly.

well my main purpose of posting so much crap was to make you do a small executable like hello world in bcb -6 as well as may be bcg5.5 etc an see if it reads the source and to see if the formats differ etc these small silly problems can be sorted out mostly by not being stuck at one single problem but to diversify your view of thinking rather

or why not cut you powermon whatever into a small component and compile it and see if it still creates the problem etc

if you create two .tds with two different compilers and
do fc/b myfir.exe mysec.exe >res.txt it should point out the differences between two two .tds

it is almost experiments that leads to solutions rather than problems

my 0.00000000000000005 cents

> well my main purpose of posting so much crap was to make
> you do a small executable like hello world

I would have gotten your point sooner had you just come out and said it.

As it turns out, I've been converting godfather+'s MapConv plugin to work with Borland map files. If I load the DLL in OllyDbg, it does find the DLL source code properly. I then created a small (VCL) test project. Same thing, source if found OK.

It would appear that the problem is related to the size of (or the number of symbols in) the TDS file. Not much point in looking further as there's nothing I can do about it. Perhaps the author will look into this.

However, now that I can import Borland map files it is less of an issue, but I would like to be able to use my source files in conjunction with Olly.