按照所能调试的程序, 所需要在两台电脑上做的配置分, 实际上根据windows有没有域配置, 在不在同一个局域网中有多种可能的组合, 这里只说我自己试过的三种配置:
前提是同一个局域网内, 没有域, 都是在WORKGROUP工作组内.
定义:
local machine: 开发者使用的机器, 以开发者为中心说事, 自己是locale, QA或用户是remote的
remote machine: 运行你的软件的最终用户, 或qa.
办法一(在两台XP SP2中文上验证过):
1. local machine的预先要求:
VS2008 IDE打开被调试代码, 注意不必要是原封不动地打开build目标程序时的原始solution/project, 只要打开对应的源代码文件即可, 当然最方便的还是打开全套的solution, 用着谁就有谁. 这里只是说明, 对于使用csc 命令行编译出来的只有几十行的小程序, 也同样适用, 前提只是要你在IDE中打开对应的源文件.
2. 当前登录的(使用IDE的那个淫)用户名和该用户的密码, 必需与remote machine上目前登录的那个淫的用户名/密码完全一致, 仅仅用户名一致是不够的, 密码也必需一致.
3. 把local machine机器上
C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\Remote Debugger\
这个目录 copy到 remote machine上任一位置, 这个目录不大, 网上的资料一般是说要"安装"这个remote debugger server, 其实不必, 复制即可. 更有甚者, 放在某个共享目录下, 建一个快捷方式即可, 连复制都不必.
4. 对于local machine和remote machine, 都需要保证 DCOM分布式服务是打开的, 具体设置请看:
这一步在我的情形下是多余的, 两个机器本就如此, 默认就已经是对的了, 但这可能是一个必要条件(我没验证过把它们关掉还行不行), 网上很多资料都要求这个.
5. 关于本地安全策略:
这个默认值是错的, 必需手工做一遍(确切说是两遍, 两台机器都得做, 对于win2k电脑不需要这一步):
一图胜千言, 相信上面已经很明确, WIN XP的默认选择是"仅来宾 - 本地用户以来宾身份验证", 必需改为"经典 - 本地用户以自己的身份验证", 否则可能碰到VS IDE attach远程进程时报告说用户名/密码不对的错误
6. remote machine上, 要运行的目标程序, 每个exe, DLL都必需有一个对应的pdb文件, 与对应的exe/dll位于同一目录下. 可能让很多人吃惊的是, VS2008这样的开发环境默认在 Release配置下也是同样生成调试信息的. 你所需要做的是在当初build代码时就把所有的pdb文件打包保存好, 以备日后被QA或客户运行你的程序出了问题砸场子时拿出来帮助调试, 就象现在这样.
同样跟这个pdb 文件有关的是:
6.1 你不必担心因为生成调试信息而让EXE/DLL变大, 程序调试符号信息的技术日新月异, 大部头的信息并不在EXE/DLL中, 而是在独立的PDB文件中, 不论对native 的C/C++项目, 还是managed .NET项目, 都是.pdb文件.
6.2 对于调试符号的格式, 实际证明pdbonly 足矣, 我没碰到调试时信息不全的事, 不必是full. 其中pdbonly和full都是项目属性中调试信息格式的可选项. 对于.NET 程序:
csc /? 输出中有下面一条:
D:\work\CSharp>csc /? | grep pdbonly /debug:{full|pdbonly} Specify debugging type ('full' is default, and enables attaching a debugger to a running program) |
实际使用中我没发现不同, 使用pdbonly 没碍着我成功地attache 一个运行中的程序(这程序还是远程的)进行调试.
6.3 而在不能成功载入远程程序的符号信息时, 微软还会给出下面一个错误对话框:
必需说明, Release版的manached 项目, 打开optimize的情况下, 不妨碍远程调试, 微软在上面一行说可不能成功载入符号信息的原因是:
A. 程序编译时打开了optimize
B. 没有Debug 信息.
其中B是可能的错误原因, 在我这里的情况, A则不是, 至少不一定是. 对于C#/.NET程序, 打开优化编译一样可以跟踪调试.
后面的建议是说切换到debug模式, 之所以如此建议是因为默认的Debug模式正好保证了A, B两点: 没有打开优化, 同时生成符号信息(注意Release版本的默认配置也会生成符号信息).
这个对话框有点误导, 我第一反应是怀疑pdb 文件中的符号信息还不够完全, 是不是应该是full, 后来的实验反证了这一点. 第二个是盲目地切换到Debug配置下, 结果当然也不行.
6.4 在VS2008的IDE中, 下面选项必需关闭, 否则会出现符号信息载入失败的错误:
又一次地, Output窗口中微软以这样的信息来误导你:
好象这两个条件是 AND 的关系, 第一反应当然先把optimize关闭全部编译一遍目标程序, 这对大项目可是很费时间的. 第二个才想到上面的选项对话框. 从字面意思上, 也不容易看出"Enable Just My Code"与这个东西有关. 可能微软把来自远程的pdb文件都认为不是自己的代码, 它公开的.NET代码也是这种情况.
7. 在remote machine上运行目标程序, 同时也打开msvsmon, 一般它的server name是:
用户名@机器名.
这个名字要记下来.
8. 在local machine的IDE中, 打开Debug菜单, 选择"Attach to process...", 在
在其中的 Qualifier 中手工写入步骤7中记下来的remote server名字, 大小写不敏感, 但强烈建议仔细比对一字不差(大小写也不差)地精确输入. 输入后按回车键, 下面的进程列表会列出在remote machine上运行的程序列表. 选择到目标进程后, 如果成功解决了上面的符号信息载入问题, 接下来就跟本地调试没有两样了. 可以同时调试managed code和native code, 在VS2008中, 同时挂接两种要调试的目标环境同样很快. 设置断点等待着remote machine的触发.
9. 在remote machine中, 作一个能触发程序流程走到8中设置断点处的操作.
方法二, 这个只能用于调试native 代码, 优点是极其简单. 不需要用户名/密码方面的同步限制.
1. 配置msvsmon如下:
从名字就看得出来, 不需要认证, local machine与remote machine之间只靠 IP和端口号两个东西进行识别和通讯.
2. 在local machine一端, 需要这样来attach 进程:
注意 Qualifier中的内容与1中的server name一致, 而第一项的Transport必需选择成如上图中的配置, 否则会有下面的错误:
方法三. 与方法二绝大多数步骤和要求都相同, 这个方法我还没在网上有看到过, 省去了要求两台机器以同样帐号登录(remote machine为win2k SP4 中文, local machine为XP SP2中文测试过):
1. 还是要求remote machine上有一个帐号与local machine的帐号同名, 同密码. 但只需要添加该帐号, 而不必注销当前的用户以此帐号登录.
2. 右键单击 msvsmon.exe文件, (在win2k上要在右键的同时按住SHIFT键)选择其中的运行方式(A)..., 在弹出的对话框中输入用户名和密码, 注意这个用户名和密码跟local machine上当前登录的开发者用户要相同:
此时, 查看Tool->Permission 为:
意思是表示接受跟本机上zhao用户相同用户名和密码的其它机器上的用户发起的连接. 这里是说remote machine对local machine的验证.
问题在于两者的连接是双向的, local machine同样需要对remote 机器进行验证, 所以要求remote machine上代表debug server 的用户名/密码也必需与开发者本机当前用户相同.
否则, 以直接双击msvsmon.exe的方式运行, 是以remote machine上当前登录的用户比如Administrator, 此时在IDE中Attach 远程进程, 也可以成功连接debug server, 但是会出现下面的错误:
据说VS2005的远程调试比VS2003简化了不少, 但实际上仍然十分费事, 整明白上面这一套东西花了我一整个上午.
阅读(4957) | 评论(0) | 转发(0) |
