I am newbie in the world of driver development and have created a basic hello world kmdf driver which compiles in VisualStudio, I want to debug it in a virtual machine just in case something goes wrong so I setup the connection between windbg and the virtual machine using a serial port though I’m now confused since I’m now in debugging the virtual machine kernel whilst my driver source file is on my physical computer, so would I need to put the driver source file onto the virtual machine and then debug using windbg?
What I assumed when I was setting up the connection was that I would write drivers on the physical machine and debug them on the virtual machine through the connection, so I assumed that windbg should be on the virtual machine.
I am newbie in the world of driver development and have created a basic hello world kmdf driver which compiles in VisualStudio, I want to debug it in a virtual machine just in case something goes wrong so I setup the connection between windbg and the virtual machine using a serial port though I’m now confused since I’m now in debugging the virtual machine kernel whilst my driver source file is on my physical computer, so would I need to put the driver source file onto the virtual machine and then debug using windbg?
What I assumed when I was setting up the connection was that I would write drivers on the physical machine and debug them on the virtual machine through the connection, so I assumed that windbg should be on the virtual machine.
Thanks I managed to sort out communication through the serial port though when I have loaded the driver I can’t seem to find the driver in the list of loaded modules or in the processes through windbg. When I check in osrloader active services it is stated that the driver is running. So do I need to do anything else beside osrloaders register service and start service to actually get the driver loaded and running.
> Thanks I managed to sort out communication through the serial port though > when I have loaded the driver I can’t seem to find the driver in the list > of loaded modules or in the processes through windbg. When I check in > osrloader active services it is stated that the driver is running. So do I > need to do anything else beside osrloaders register service and start > service to actually get the driver loaded and running. > > — > NTDEV is sponsored by OSR > > Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev > > OSR is HIRING!! See http://www.osr.com/careers > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer >
>You know that those are instructions for setting up debugging through visual studio and that the op is using windbg instead, right?
Yes I know. Once provisionning has completed, you can debug the target machine with WinDbg or Visual Studio.
If you setup Visual Studio to use “Debugging tools for Windows - kernel mode” as the debug engine than you will have the exact same debugging environnement with Visual Studio and WinDbg.
I guess its just me, but if I were going to tell somebody to RTFM I would
at least point them at the right FM.
Mark Roddy
On Mon, Dec 1, 2014 at 3:51 PM, wrote:
> >You know that those are instructions for setting up debugging through > visual studio and that the op is using windbg instead, right? > > Yes I know. Once provisionning has completed, you can debug the target > machine with WinDbg or Visual Studio. > > If you setup Visual Studio to use “Debugging tools for Windows - kernel > mode” as the debug engine than you will have the exact same debugging > environnement with Visual Studio and WinDbg. > > — > NTDEV is sponsored by OSR > > Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev > > OSR is HIRING!! See http://www.osr.com/careers > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer >
>I guess its just me, but if I were going to tell somebody to RTFM I would at least point them at the right FM.
Why do you say that ? That is the rigth page to learn how to provision a test machine with Visual Studio. And I repeat; provisionning a computer with Visual Studio does not mean that Visual Studio will be used for debugging.
I hope the following link won’t be broken into two lines:
I setup kernel debugging over network using visual studio following the instructions here (http://msdn.microsoft.com/en-us/library/windows/hardware/hh439353(v=vs.85).aspx). It can successfully deploy the driver to the target machine, but it cannot debug. I also tried using Windbg to connect to the target (to the port and using the key that I got after provisioning using visual studio) but it cannot connect. Can you please give me some insight?
Check that the debug settings on the target machine do match those
set during provisioning. Just type the following command on the target
machine (administrative privileges required):
bcdedit /dbgsettings
Note that the IP address is the host’s IP address.
If the settings do match then you could have a network firewall issue.
The problem is, the OP didn’t ask how to provision a test machine. In fact, I suggest he doesn’t even TRY to provision a test machine.
He asked how to setup debugging.
I don’t recommend that the OP try to debug his driver from within Visual Studio, either.
OP… Ignore this provisioning shit. Just setup debugigng, running WinDbg separately. It’s easier to get working, it’s faster, and it’s how all the cool kids do it.
If you’re using a specific VM (like here at OSR, we use VMWare) you can Google for “setting up WinDbg VMWare” or something similar and get specific instructions.
This is all annoying the first time or two you do it, but it’s pretty straight forward after that.
But, I repeat… do not initially spend time configuring your test system in VS for debugging. Get something running first, and THEN decide if you want to use the build-in VS testing stuff.
Managed to sort it guys, I can now load the driver and I set a bu breakpoint so I can debug my basic driver upon entry. Thanks for the help. I’m going to stick to windbg for debugging drivers and visual studio for coding the drivers.
That is what provisionning does among other things like installing the Windows Driver Testing Framework, Debugging Tools for Windows, VC Redistributables… For instance, the “devcon” utility is installed, so when the OP will be confortable with kernel debugging, he will be able to install/update drivers manually and quickly.