VMware实现单机使用WinDbg进行调试.docx

借助VMware实现单机使用WinDbg进行调试的方法。 安裝VMware Workstation 6.0,WinDbg。具体步骤如下：1 设置 VMware 的虚拟com1.1 运行 VMware ，点击 Edit virtual machine settings1.2 点击 Add. 来运行 VMware 的 Hardware Wizard 1.3 选择 Serial Port，点 下一步1.4 选择 Output to named pipe,点 下一步 1.5 第一框里保持默认的 .pipecom_1 1.6 选中 Yield CPU on poll（VMware Support 中提到了这一点），然后点完成。1.7 这样就完成了虚拟com的设置。1.8 重新启动 VM。2 设置 VMware 虚拟出来的 guest os现在 power on 虚拟出来的 guest os2.1 设置boot.ini在c:下，可以找到boot.ini，可以用记事本打开它。我们需要在 guest os 的启动项上加些参数，才能够使用WinDbg调试它。我们可以在现有的行后面直接加参数，不过强烈推荐复制一个新行，在新行的后面加参数。这样在调试启动有问题的时候，我们可以方便的换回原来的启动方式。下面就是我改好的boot.ini。其中 multi(0)disk(0)rdisk(0)partition(1)WINNT=Microsoft Windows XP Professional /fastdetect 是原来的行。 multi(0)disk(0)rdisk(0)partition(1)WINNT=Microsoft WindowsXP Professional - debug /fastdetect /noguiboot /debug /debugport=com1 /baudrate=115200 新加為用于 WinDbg 调试的行。-boot loadertimeout=10default=multi(0)disk(0)rdisk(0)partition(1)WINNToperating systemsmulti(0)disk(0)rdisk(0)partition(1)WINNT=Microsoft Windows XP Professional /fastdetectmulti(0)disk(0)rdisk(0)partition(1)WINNT=Microsoft WindowsXP Professional - debug /fastdetect /debug /debugport=com1 /baudrate=115200-这里还要注意的是,timeout不要为0，否则直接启动默认的项。新行后面加上了参数 /debug /debugport=com1 /baudrate=115200 ，可以看到 debugport=com1 ，baudrate=115200 。参数的具体作用，可以参考 WinDbg 的帮助文件。2.2 设置com1端口的速度在 guest os 的设备管理器中把com1端口的速度也就是每秒位数项，设为和上面一样的115200。3 设置 WinDbg我们需要告诉WinDbg通过pipe进行连接和连接的速度。可以在命令提示符（cmd.exe）下加参数-b -k com:port=.pipecom_1,baud=11520,pipe 运行WinDbg（VMware Support 中没有提到 baud=11520 这个参数，其实这是个比较重要的参数）。更方便的方法是在桌面建立一个WinDbg的快捷方式，在该快捷方式的属性，目标框中，加上参数 -k com:port=.pipecom_1,baud=11520,pipe 。这样运行这个快捷方式启动的WinDbg就完成了设置。参数的具体作用，可以参考 WinDbg 的帮助文件。 4 推荐的操作顺序4.1 首先运行 VMware ，启动 Guest OS ，到系统启动选择，选择 Microsoft WindowsXP Professional - debug 项，先不要按回车。4.2 通过刚才设置好的快捷方式运行WinDbg。4.3 在 Guest OS 中选择 Microsoft WindowsXP Professional - debug 项，按回车。4.4 稍等片刻，就连接上了。如果很长时间没有连接上的话，可以按 WinDbg 菜单中的 Debug-Kernel Connection-Resynchronize。 Break ，你就可以向 WinDbg 下命令了。? 其他?.1 VMware Support 中还提到了可以通过修改虚拟机的配置文件来改变虚拟串口的速度，有兴趣的话可以参考 VMware Support 中的方法。?.2 WinDbg 的菜单项 View-Show Version 可以看到一些相关信息。参考Driver Debugging with WinDbg and VMWare /lotr0/windbg-vmware.htmlVMware Support 相关部分 /support/ws3/doc/ws32_devices3.html One of the first useful things you will want to do when in the bowels of ring 0 is attack the thing from a debugger point of view. In my case I like using Windows Debugger windbg (hey its free, fully functional and does remote debugging really well), and found it neccessary to find a way to have it work with VMWare. The trick to get it to work in VMWare is to get the host OS to believe it is able to connect to a serial port. Through VMWare, to accomplish this, you need to create a named pipe. The following steps will guide you to configuring VMWare (in my case v3.2): 1. Open up the Configuration Editor (Settings-Configuration Editor) 2. Click Add to run the Hardware Wizard 3. Select Serial Port, and then click the Next button 4. Select the Use named pipe radio button 5. Use the default pipe name. It SHOULD be .pipecom_1. If it is not, change it to that. 6. Select This end is the Server. 7. Select The other end is an application. 8. Click the Advanced Button. 9. Select the Yield CPU on poll checkbox This is an important step as the Kernel in the target virtual machine uses the port in polled mode, not interrupt mode. 10. Click the Finish button, and then click Ok to close the Configuration Editor. Once you have configured your VMWare session, you need to power it on. You will be able to confirm that the new virtual serial port is added by clicking on the Devices-serial0 menu item. You should note it is saying Connecting. This means its now ready for a remote connection. Once the actual virtual machine is configured, you need to configure the target operating system installed in the virtual machine to support remote debugging. This is accomplished by editing the boot.ini found in the root of the C: drive. To do this, you need to add a /debugport=some_com_port /baudrate=some_baud_rate to the end of an operating systems line. I would not recommend doing it to the one that is there. It would be better to copy the line and paste it with the ammendments, and then use the OSs menu selection to determine which mode you would like to boot into. This is what my boot.ini looks like for XP Pro as the operating system in the virtual machine: boot loader timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)WINDOWS operating systems multi(0)disk(0)rdisk(0)partition(1)WINDOWS=Microsoft Windows XP Professional /fastdetect multi(0)disk(0)rdisk(0)partition(1)WINDOWS=Microsoft Windows XP Professional - Debug /fastdetect /debugport=com1 /baudrate=115200 You will notice that the second option sets the debugport to com1, and sets the baudrate to 115200. I am told you can tweak this out to get even more speed out. But it seems fine for me at this speed, so I havent mucked with it at all. If you do try this, drop me an email and let me know how it works out. If you set up your boot.ini fine, save it and reboot. You should be prompted with something that looks like this: At this point you have completed setting up the VMWare side of things. Now you need to set up the host to connect to it. This is actually rather easy. You just need to tell windbg at the command like to connect to the pipe, like this: windbg -k com:port=.pipecom_1,pipe If you are using WinDbg 6.x or newer, a better alternative is to use: windbg -b -k com:pipe,port=.pipecom_1,resets=0 Thanks needs to go to Randhir Dugal for pointing out the new format for the latest Windbg version. I am a rather anal type guy when it comes to security, so I actually made a shortcut on my desktop to WinDbg and added these command line arguments to the Target line. Originally this was so I could run WinDbg with differnet credentials as I do not run with administrator privileges on a day to day basis. I found that with XPs normal security settings for com ports, you can still work in a least privileged environment while doing the development WITHOUT having to use runas. (You are logged into W2K/XP as a least priviledged environment arent you? If not, you really should read my article on how, and why this is important to do so.) At this point fire up the debug