By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,723 Members | 1,255 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,723 IT Pros & Developers. It's quick & easy.

How to debug application built on another machine?

P: n/a
My application crashed (with the "cannot read memory, press OK to
terminate or Cancel to debug" message) on the machine that has VC7.1. I
just copied the original project with pdb file to that machine, opened
the project, pressed Cancel to the above message, and chose this
instance of Visual Studio. But I couldn't step through my code, only
through internal MFC code.

Does anybody knows what am I doing wrong?
Nov 17 '05 #1
Share this Question
Share on Google+
8 Replies


P: n/a
When the debugger is attached you can see whether it could load the pdb in
the debug output window. It should say something like "symbols loaded" next
to your exe or dll.

"Mihajlo Cvetanović" <ma*@RnEeMtOsVeEt.co.yu> wrote in message
news:uL**************@TK2MSFTNGP09.phx.gbl...
My application crashed (with the "cannot read memory, press OK to
terminate or Cancel to debug" message) on the machine that has VC7.1. I
just copied the original project with pdb file to that machine, opened the
project, pressed Cancel to the above message, and chose this instance of
Visual Studio. But I couldn't step through my code, only through internal
MFC code.

Does anybody knows what am I doing wrong?

Nov 17 '05 #2

P: n/a
When the debugger is attached you can see whether it could load the pdb in
the debug output window. It should say something like "symbols loaded" next
to your exe or dll.

"Mihajlo Cvetanović" <ma*@RnEeMtOsVeEt.co.yu> wrote in message
news:uL**************@TK2MSFTNGP09.phx.gbl...
My application crashed (with the "cannot read memory, press OK to
terminate or Cancel to debug" message) on the machine that has VC7.1. I
just copied the original project with pdb file to that machine, opened the
project, pressed Cancel to the above message, and chose this instance of
Visual Studio. But I couldn't step through my code, only through internal
MFC code.

Does anybody knows what am I doing wrong?

Nov 17 '05 #3

P: n/a
Mihajlo,
My application crashed (with the "cannot read memory, press OK to
terminate or Cancel to debug" message) on the machine that has VC7.1. I
just copied the original project with pdb file to that machine, opened the
project, pressed Cancel to the above message, and chose this instance of
Visual Studio. But I couldn't step through my code, only through internal
MFC code.

Does anybody knows what am I doing wrong?


The debugger is probably not finding the symbols for your libraries. Once
you start debugging, open the Modules Window, and you should see your
exe/dlls in that list. My bet is that they say "symbols not loaded". If so,
you can right click on each one and select "Reload Symbols", which will
bring up a Open File dialog where you can browse for the correct pdb file.

Also, you'll want to load your source files in VS as well.
--
Tomas Restrepo
to****@mvps.org
http://www.winterdom.com/
Nov 17 '05 #4

P: n/a
Mihajlo,
My application crashed (with the "cannot read memory, press OK to
terminate or Cancel to debug" message) on the machine that has VC7.1. I
just copied the original project with pdb file to that machine, opened the
project, pressed Cancel to the above message, and chose this instance of
Visual Studio. But I couldn't step through my code, only through internal
MFC code.

Does anybody knows what am I doing wrong?


The debugger is probably not finding the symbols for your libraries. Once
you start debugging, open the Modules Window, and you should see your
exe/dlls in that list. My bet is that they say "symbols not loaded". If so,
you can right click on each one and select "Reload Symbols", which will
bring up a Open File dialog where you can browse for the correct pdb file.

Also, you'll want to load your source files in VS as well.
--
Tomas Restrepo
to****@mvps.org
http://www.winterdom.com/
Nov 17 '05 #5

P: n/a
Thank you fellows for the useful info, the error was the most obvious
one: the application and the project don't match, with a half an hour
distance.

This only proves the point that whatever job you're trying to rush on
Friday at 9 PM (like debugging the crash on another machine), it can't
come out good.

Saying that, I have another question. Is there a way to force the
debugger to use inappropriate PDB? Granted, it would show the wrong info
in some parts of the code, but it would still be usable in other parts.
Nov 17 '05 #6

P: n/a
Thank you fellows for the useful info, the error was the most obvious
one: the application and the project don't match, with a half an hour
distance.

This only proves the point that whatever job you're trying to rush on
Friday at 9 PM (like debugging the crash on another machine), it can't
come out good.

Saying that, I have another question. Is there a way to force the
debugger to use inappropriate PDB? Granted, it would show the wrong info
in some parts of the code, but it would still be usable in other parts.
Nov 17 '05 #7

P: n/a
Saying that, I have another question. Is there a way to force the
debugger to use inappropriate PDB? Granted, it would show the wrong info
in some parts of the code, but it would still be usable in other parts.


Yes, in many cases it is possible:
http://www.debuginfo.com/articles/de...#loadunmatched

Regards,
Oleg
[VC++ MVP]

Nov 17 '05 #8

P: n/a
Oleg Starodumov wrote:
Saying that, I have another question. Is there a way to force the
debugger to use inappropriate PDB? Granted, it would show the wrong info
in some parts of the code, but it would still be usable in other parts.


Yes, in many cases it is possible:
http://www.debuginfo.com/articles/de...#loadunmatched


That's it, ChkMatch is what I was after (the only better solution is
that the debugger allows debug info mismatch). Thank you for the very
usable 50 kB piece of code.
Nov 17 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.