Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 226
  • Last Modified:

Tracing a run-time error to a line of source code

I am using MSVC 5.0.  I made a release build of my project ( 1 exe and several dlls).  I get a run-time error in one of the DLLs consistently when running the release build.  The run-time error does not happen with a debug build.  

My question is:

Is there a way for me to take the CS:EIP pointer that i'm given at the time of the error and somehow trace it back to a line of source code?  I've made a map file, but I haven't been able to get anything useful out of it.

thanks in advance for any help
Bob Brickhouse
Product Developement
Grayson Wireless
0
brickb
Asked:
brickb
1 Solution
 
alfredjCommented:
I can't answer your question specifically, but you might be able to
solve your problem by downloading (if you havent already)  the
<A HREF=www.microsoft.com/visualc/download> Visual C++ service pack</A>  from  www.microsoft.com/visualc/download.  Many strange
optimizer problems went away when I upgraded.

0
 
nietodCommented:
You don't need the CS value.  But the EIP should be one of the addresses in your map file.

Unfortunately, it could be an address from the run-time library, or from a DLL.  So it might not help.

This is not the best way to debug.  Can you print "progress" messages to find out where the problem is occurring.   OutputDebugString is great in this capacity.
0
 
abesoftCommented:
The major problem with tracing an instruction pointer back to a map file is that the DLL is (actually, it may be) re-mapped when it is loaded into memory.  So the register is pointing at a location that is offset from the actual code in the map file.

So, in order to get back to the actual line, you will need to figure out the offset that the DLL was loaded at.  Matt Pietrek wrote a utility for MSJ that did this: it was called LoadProf32, but I can't seem to find it at the MS site right now- their search engine makes my proxy gag somehow, or maybe it's the other way around ;)  Anyway, one of the things that LoadProf32 would do is report on the offset that each DLL is loaded at.  (It also reported a lot of useful info about the initialization time for each module loaded:  I highly recommend this utility...)

Taking the load offset, and seeing if it was different from the anticipated load offset, you will know where the fault actually happened.  This should let you look back into your map file to find out where it happened.  

If you combine this with a good post-mortem (like a stack dump from Dr Watson) you should be able to trace into things a little more.

Of course, you will still be only getting to the function level- the actual line won't be available to you, since that info is completely missing from a release build.  But you WILL be able to either read through the assembler (if you're comfortable with that) or go back to the source and add extra logging statements to track down the actual line.

Good luck!
0

Featured Post

Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

Tackle projects and never again get stuck behind a technical roadblock.
Join Now