none
Windows kernel driver development environment RRS feed

  • Question

  • Hi all,

    I am a total noob for windows driver development and recently I am assigned a project to develop drivers for windows 10 and 8.1

    I have a PC with windows 8.1 and visual studio 2017. I have WinDbg. I have tried to do local debugging but I was not successful and somewhere it was recommended not to do it as its very limiting.

    1.What would be the best setup to do kernel driver development with least hassle.

    2.Does Os loader works in windows 8.1?

    3.What are the things I need to keep in my mind before advancing?

    Can I use windows 7 as a target, and develop and debug drivers for windows 10? On below link its said that windows 7 have bugs regarding WDK Test Target Setup.

    https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/f446de0e-e18f-45ff-8add-ed0a428d2762/wdk-test-target-setup-x64-fails-when-run-on-windows-7-computer?forum=wdk

    Kindly show me the path. I am trying too many things and going nowhere?



    Regards,

    Mrigendra Chaubey

    Tuesday, March 13, 2018 7:30 AM

All replies

  • What kind of driver are you writing?

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Tuesday, March 13, 2018 4:27 PM
  • I am trying to write kernel drivers.

    I reached till here.

    Windows 8.1 64 bit host.

    windows 10 64 bit target inside virtualbox.

    Once windows 10 is installed, go to Devices -> Run insert guest additions CD image. After this enable drag and drop.

    Install visual studio 2017 on host. All tools will be installed with it.

    Path for 64 bit WinDbg

    C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Windows Kits\Debugging Tools for Windows (X64)

    Find WinDbg (usually above path) and get a VirtualBox image of your target - called “Debuggee” - installed in VirtualBox. Then open the virtual machine configuration and activate a serial port (COM1).

    Important part is serial connection between host and target.

    In the “Serial Ports” configuration select 

    Portnumber COM1

    Port mode “Host Pipe” and choose a 

    name for the path, i.e. \.\pipe\windebugpipe.

    “Connect to existing pipe/socket” unchecked.

    Now, on the Host, also open a command prompt as Administrator and fire up WinDbg.

    Windbg -b -k com:pipe,port=.\\.\pipe\windebugpipe,resets=0,reconnect

    WinDbg is now waiting for a connection to the debuggee.

    Restart the virtual machine. The VM should connect to your debugger. The debugger will probably already kick in in the boot process and stop the VM while windows is still starting up, so don’t be irritated if it stops loading.

    Press “g” and Enter in the Debugger command prompt to let Windows continue booting. If the debugger doesn’t kick in the first time, try to reboot the VM

    Waited 20 mins until windows 10 VM boots up. On WinDbg command prompt I see this KDTARGET: Refreshing KD connection

    Maybe debug connection is lost.

    How to proceed from here?

    Another attempt with visual studio

    Created a hello world project and build it.

    In driver->configure devices 

    Transport : Serial

    Port : \\.\pipe\windebugpipe

    baud : 115200

    Now if I click on this icon on top

    Debugging Tools for Windows - Kernel Debugger

    I am logged out and logged in as wdkuser. What is this?

    How to proceed in this way?


    Thursday, March 15, 2018 5:17 PM
  • Local kernel debugging is very limited, as you say.  You cannot set breakpoints, and you cannot catch blue screens.  Two computers tends to be most convenient, but if you don't have actual hardware (and sometimes even if you do), you can use one machine with a VM.

    You can do your development on any recent operating system.

    I don't know what you mean by "os loader".

    You can certainly target Windows 7 and run on Windows 10, as long as you don't need any "cutting edge" features of the kernel.  The signing requirements on Windows 10 are different, but you'll get to that later.  Most hard-core driver developers do not use the debug deployment stuff built-in to Visual Studio, although you may be able to get it to work.  Most of us build on machine A, then copy the new binary over to machine B by hand for testing.

    Doron's question above is the most important.  Your tools and your development/debug flow depend strongly on what kind of driver you need to build.


    Tim Roberts, Driver MVP Providenza & Boekelheide, Inc.

    Thursday, March 15, 2018 5:37 PM
  • "Most hard-core driver developers do not use the debug deployment stuff built-in to Visual Studio."

    Then how do they debug? How do they see the result/effect of their driver?



    Thursday, March 15, 2018 6:01 PM
  • They build the driver package, manually copy it over to the test machine, install the updated driver. And have an active debugger connection. Again, what KIND of kernel mode driver are you writing? Usb? Networking? Etc.

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Thursday, March 15, 2018 11:21 PM
  • Hi

    The driver will be having a bunch of IOCTL, I2C and UART calls to control a certain piece of hardware. Just a typical hardware, and the requirement is it should be able to run on windows 10.

    Right now I am failing to even run a hello world driver. I followed this

    https://docs.microsoft.com/en-us/windows-hardware/drivers/gettingstarted/writing-a-very-small-kmdf--driver

    but errors such as there were deployment errors, followed by failure to create process instance for debugging etc comes and hinder me to do anything more.

    1.How and which files should I copy to where in windows 10 virtual machine?

    2."And have an active debugger connection." What is this debugger? Is this a hardware debugger or a software one such as WinDbg? How to ensure I have an active debugger connection?

    Kindly respond. 

    Friday, March 16, 2018 8:33 AM
  • Ok I was able to install the driver in virtual box windows 10.

    I dragged and dropped the driver folder inside windows 10 and right clicked on system information (INF) file. It was installed.

    Now how do I see it running and be able to see the debug prints?

    1. Using WinDbg? Then how?

    Friday, March 16, 2018 10:05 AM
  • Also can I follow this book for windows driver development basics.

    Windows-7-Device-Driver-Addison-Wesley-Microsoft-Technology-Series

    Friday, March 16, 2018 10:50 AM
  • The driver will be having a bunch of IOCTL, I2C and UART calls to control a certain piece of hardware. Just a typical hardware

    So, is it a "kernel mode service" that talks to some I2C and UARTs on behalf of usermode apps? Or does it simulate an UART to the apps while the real hardware is i2c? (and you have a platform where I2C is exposed to Windows drivers?)

    -- pa

    Friday, March 16, 2018 12:31 PM
  • The Windows 7 Device Driver book you refer to is one of the worst pieces of trash ever developed.   There was a set of reviews in OSR's NT Insider that described how terrible it was.  Whatever else you decide to do, throw the book out (or better burn it so no one else picks it up).   Get the Developing Drivers for the Windows Driver Foundation book by Microsoft Press, while old it is still very good.

    If the driver is going to access hardware directly, the right click of the INF file is the wrong thing to do.  It will cause the driver to fail at start time, unless the driver is a legacy driver (i.e. no plug and play).   You are better off on this, develop an INF file that can be installed through the Device Manager or Devcon.


    Don Burn Windows Driver Consulting Website: http://www.windrvr.com

    Friday, March 16, 2018 1:52 PM
  • Windows 8.1 and later supports right click install of pnp drivers.  it is the same as pnputil /a <inf> /i ... IOW it will add the driver package to the driver store and find all appliable devices that match the newly added driver and see if the new driver is the best driver to install.

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Friday, March 16, 2018 5:00 PM
  • Yes he hardware will expose I2C lines. I2C protocol will be used to configure the device. There will be IOCTL switches too. A user space app will be using this driver to configure the device.Its not a PnP driver.

    The problem I am facing is I am unable to run a hello world driver in the target.I have detailed my problems above as what I am facing.

    I am from linux driver side previously so its all new to me.

    How do we debug kernel drivers in production level way with sufficient satisfaction?

    What is your setup?

    Can you tell where my debug setup is wrong or where I am doing a mistake?


    Friday, March 16, 2018 5:45 PM
  • if the hardware is exposing hardware resources like i2c, there will be a pnp driver that controls the i2c hw interface.  it could be an inbox driver or something you write. it could be this driver you are talking about or another one. PnP doesn't just mean dynamic discovery of a device that you plug in (e.g. USB), but also means managing fixed HW resources and participating in how that hw is started, powered up/down, etc

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Friday, March 16, 2018 7:08 PM
  • My question is not about its PnP or not. The problem I face is more smaller of a nature, like running a hello world kernel driver.Rest I will figure out later once my development environment is setup and working fine so that I can do experiments.

    Does development environment for kernel drivers depends on if its PnP or not?

    Friday, March 16, 2018 7:13 PM
  • PnP or not will change how the driver is deployed and started.  You should be using KMDF no matter if it is PNP or not.  if the VS deployment is giving you problems, deploy yourself.  you will need to figure out the KM debugger so that you can debug your driver as it executes

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Friday, March 16, 2018 11:41 PM
  • "you will need to figure out the KM debugger so that you can debug your driver as it executes"

    I told my problem in the beginning but the discussion was diverted in other direction. The debugger and its problems I have detailed and all you are saying is figure it out yourself. How to figure out? Its closed source thing, how people figure out things if the tools and applications are not working?

    Saturday, March 17, 2018 8:03 AM
  • Its closed source thing, how people figure out things if the tools and applications are not working?

    Learning every kind of environment unfortunately takes some time and effort. Even with Linux getting used to kgdb takes time and fixing an issue takes even more time.

    Some people learn faster from others. If this is your case, ask someone else to show you the movements.

    -- pa



    • Edited by Pavel A Saturday, March 17, 2018 8:12 PM
    Saturday, March 17, 2018 8:11 PM