Printable View
Hi,
I'm using Visual C++ 6.0 (go ahead & laugh, but I have no choice), and I was wondering if there's any way to execute the debug .exe on a remote system and debug it from my dev machine?
I'd rather not install the whole program I'm fixing on my machine because, well -- it sucks, and I don't want to blow up my own machine...
First Google hit for "visual studio remote debugging" looks promising. EDIT: Oh wait, you said 6.0? Hmm ;)Quote:
Originally Posted by cpjust
And still it is possibleQuote:
Originally Posted by brewbuck
You have to copy some file to the remote computer ( I do not remember the exact list - read manual)
In the build menu - select Debug Remote connection ...
Just read the http://msdn2.microsoft.com/en-us/library/aa293540.aspx
6.0 did have remote debugging facilities. But I think only on the professional version.
Meanwhile, http://msdn2.microsoft.com/en-us/lib...29(VS.71).aspx
Not saying it didn't, but the Google hit I mentioned wasn't relevant to that version.Quote:
Originally Posted by Mario F.
I tell you one thing that the docs aren't real clear on, in the "Remote Executable Path" be sure to use a UNC path the evaluates correctly in the context of both machines - for example: "\\192.168.1.10\C$\MyApp\MyApp.exe".
So to get that path to work, you'll have to turn off simple file sharing on the remote machine and you'll need to have already authenticated for access to C$ before debugging.
gg
I do not remember it is necesaryQuote:
Originally Posted by Codeplug
The path should be the local path of remote computer because it is remote debugger monitor running there, who search for the executable to startQuote:
Executable for Debug Session Enter the name and path of the executable file as the debugger host computer sees it.
I use it every day and it's needed for me...but I'm debugging a large project with multiple DLL's that I step in and out of. Simply following the instructions may work for single EXE - but if it doesn't, make the remote executable path visible to both machines.
gg
Thanks, I'll give all that a try.
Wow, my first remote debugging -- I can't wait! :D
As I remember - there is a list of "used dlls" that you should add setting up the remote exe to debug.Quote:
Originally Posted by Codeplug
And they'll be found and be available for debugging as well
It's coming back to me.....I think the problem was that only the EXE could be debugged if the remote executable path wasn't absolute for both machines.
Another technique I've seen people use is to copy all your debug binaries and PDB's to the same "remote executable path" directory structure on both machines. So if you use "C:\MyApp\MyApp.exe", you would copy everything needed to that directory on both machines.
gg
I did that, but when I press F5 I get "The remote machine '\\qa-vm-w2k3-sp1\c$\Program Files\MyCompany\My Program\MyProgram.exe' could not be found."Quote:
Originally Posted by Codeplug
I'm wondering if it's having problems with the spaces in the path?
I tried putting quotes around the whole path, but that didn't help.
You may need to use the 8.3 format for the entire pathname - ie. "Program Files" -> "Progra~1" ect...
What I do is map a drive to the program directory on both machines. So on the debugging machine, I would map R:\ to "\\qa-vm-w2k3-sp1\c$\Program Files\MyCompany\My Program\" using "map network drive", and on the remote machine map R:\ to "C:\Program Files\MyCompany\My Program\" (using the subst command).
Then your remote executable path will simply be "R:\MyProgram.exe". Another nice thing about doing it this way is that you can setup a simple "post build command" to copy the the target to R:\ so your ready to F5 as soon as you make a change :)
Your post build command would be "copy $(TargetPath) R:\".
gg
Thanks, I used subst to map those paths to a drive and shortened the .exe name to 8.3 format. Now when I press F5 it pauses for a few seconds like it's trying to connect, but then gives me the same error.Quote:
Originally Posted by Codeplug
Let me make sure I'm doing everything right:
- In the Project Settings, Debug/General tab, I added "V:\MyProg~1.exe" to the "Remote executable and filename" field.
- In Build->Debugger Remote Connection, TCP/IP, Settings, I have "V:\MyProg~1.exe" in the "Target machine name or address" field.
- On the remote machine, in the Debug Monitor Settings, I have "V:\MyProg~1.exe" in the "Target machine name or address" field.
When I click "Connect" in the Debug Monitor program it has a dialog that says "Connecting..." which never changes until I click "Disconnect". Is it ever supposed to say "Connected" or anything?
OK, for those last 2 I changed it from V:\... to just the machine name of the remote machine and it got further. It failed because the Windows DLLs were different on the two machines, but at least it's connecting now. :)
Wow, we're still locked inside the 8.3 era :eek:Quote:
Originally Posted by cpjust
And here I was, thinking it was standard to use non-8.3 names nowadays.
So what makes it restricted to 8.3? It it should call itself a Windows program?
Oh well. Good luck with it anyway. Remote debugging could have been made easier last time I checked >_<
OK, now I'm able to step through and debug the remote .exe, but only after clicking OK to dozens of dialogs such as:
Is there a way to prevent it from giving me those messages and just run?Quote:
The project 'C:\WINDOWS\system32\rpcrt4.dll' does not match the corresponding file on the remote machine.
Are you using the same OS with the same service packs, etc? [May not be viable, but if you can, it will solve the problem].
--
Mats
No, my dev machine is XP Pro Sp2 & remote machine is Win2003 server R2.Quote:
Originally Posted by matsp
Is there any way to stop those messages with different OSes?
Sure - you just have to let the debugger know what DLL's you care about debugging.
Project Settings -> Debug tab -> Category: "Addition DLLs" -> Uncheck "Try to locate other DLLs"
Also, in the list of modules there, remove anything that you don't care about debugging, like rpcrt4.dll, ntdll.dll, user32.dll, etc, etc...
gg
You can take the used dlls from the local sytem32 dir and copy them (for debug purposes) into the folder of remote exe. It should select the dll from the current folder first - and they will be the same as on the local comp
I don't care about debugging any DLLs, I just want to step through the .exe. I unchecked everything, but that didn't help. :(Quote:
Originally Posted by Codeplug
Well, I wouldn't mess with OS dll's - trying to use XP system dll's on Server2003 may not work very well.
End the end, there's little use for stepping-into a dll you don't have the source code for. And if you don't need to step into a dll, you can remove it from the module list under additional dll's.
On a side note - when I have a "core dump" that I need to analyze, I use the Windows Debugger and the Microsoft Symbol Server - which will automatically download the needed symbols for any MS OS dll (which is needed for accurate stack trace sometimes). Some of my co-workers only use the windows debugger (and build off the command line) - but I'm not that "hard core" :)
gg
>> I unchecked everything, but that didn't help.
Do your settings look like this?
gg
Well I didn't delete everything in the "modules" list, I just removed the checkmarks beside the dozens of DLLs listed there as well as the "Try to locate DLLs" box.Quote:
Originally Posted by Codeplug
Remove all the modules in the list and make it look like mine - then I think the popups should go away.
gg
Hey that works! :)Quote:
Originally Posted by Codeplug
So then what does just unchecking them do?
I'm guessing that it just prevents the loading of debug information unchecked DLLs - but doesn't prevent the warning about them not being the same across machines.
gg