none
How to convert COM driver code written with WDM(Windows Driver Model for Windows 2000 in Visual C++ 6.0) to work inside Windows 7(I suppose I have to use new features of Kernel-Mode Driver Framework, Visual Studio 2010 + VisualDDK plugin + WDK)?

    Question

  • Hello to everyone!

    I have one old driver project for COM port written in Visual C++ 6.0 for Windows 2000 and Windows XP. I should to convert it or rewrite for working in Windows XP and Windows 7. What should I do with that project? Just to recompile it in new Visual Studio or move old code to new template project created in Visual Studio 2010? Or I have totally rewrite driver, because it has been written I suppose with WDM(Windows Driver Model), in native code of course(C language), have to rewrite using KMDF(Kernel-Mode Driver Framework)? Or just recompiling in new Visual Studio will be enough?

    Thank you for the answers.



    Monday, August 13, 2012 7:04 AM

Answers

  • You can take the existing driver and move it to a newer WDK.  If you want to support Windows 2000 still use the Vista WDK, if you only want XP use the Windows 7 WDK, and if you only care about Vista or later get the new Visual Studio and convert the project.

    Now before you go too far on this, there are somethings to consider.  You might want to take a look at how much your driver changed from the COM driver of the WDK you used originally.  If it was not much you may want to take the changes and re-implement them in the KMDF COM driver sample from the WDK.

    Under any circumstance, whether you use the old driver or a re-implementation your code was developed before the current testing tools.  First build you driver with /W4 /WX and fix all the failures.  Second run PreFast enabling all the warnings and fix all the errors.  Third run static driver verfifier on the driver, and check all the complaints fixing them as needed. 

    Only after the above should this be loaded on a system.  Then to test the driver use driver verifier, and the HCK tests to ensure everything works.   All the fixing and testing is why I suggest you check the delta from the stock driver of the WDK, you are likely to find it is easier and quicker to move it to the new model.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Monday, August 13, 2012 10:13 AM

All replies

  • You can take the existing driver and move it to a newer WDK.  If you want to support Windows 2000 still use the Vista WDK, if you only want XP use the Windows 7 WDK, and if you only care about Vista or later get the new Visual Studio and convert the project.

    Now before you go too far on this, there are somethings to consider.  You might want to take a look at how much your driver changed from the COM driver of the WDK you used originally.  If it was not much you may want to take the changes and re-implement them in the KMDF COM driver sample from the WDK.

    Under any circumstance, whether you use the old driver or a re-implementation your code was developed before the current testing tools.  First build you driver with /W4 /WX and fix all the failures.  Second run PreFast enabling all the warnings and fix all the errors.  Third run static driver verfifier on the driver, and check all the complaints fixing them as needed. 

    Only after the above should this be loaded on a system.  Then to test the driver use driver verifier, and the HCK tests to ensure everything works.   All the fixing and testing is why I suggest you check the delta from the stock driver of the WDK, you are likely to find it is easier and quicker to move it to the new model.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Monday, August 13, 2012 10:13 AM
  • Thank you for the answer.

    I need to convert my driver for working under Windows XP and Windows 7 at the same time. Which version of Visual Studio I should choose to work on the project: Visual Studio 2010 + VisualDDK plugin + WDK or Visual Studio 2012 + WDK?

    And of course I prefer do not re-implement some parts of old code in the KMDF. It would be just excellent if just converting and error fixing will enough. If my driver differs terrifically from the COM driver of the WDK, is it obligatory to re-write old parts of code using KMDF or will enough just to convert with error fixing?

    Where can I find COM stock WDK driver to check the delta between my driver and stock one?

    --

    Kind regards,

    Alexey Kisliy




    Monday, August 13, 2012 1:38 PM
  • Well what OS'es are you targeting.  Going the VS2012 route means you are limited to Vista and later.   If you are going with the older OS'es you should be building with the WDK which has its own compiler.  If you want to integrate with VS use ddkbuild from http://www.hollistech.com/   I would not use VisualDDK for any reason, it has bugs and is not an approved method of creating a driver.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Monday, August 13, 2012 1:46 PM
  • I'm targeting on support of Windows XP and Windows 7.

    What does it mean "WDK which has its own compiler". WDK of 7600.16385.0 build doesn't have its own compiler? Building with the WDK which has its own compiler means just usual Build of the project solution in Visual Studio after WDK is installed?

    Will be DDKBuild work with WDK version of 7600.16385.1? Here http://www.hollistech.com/ is written that the last DDKBuild version works only with WDK of 7600.16385.0 build. I have installed 7600.16385.1. Should I downgrade WDK installed on my machine?

    --

    Kind regards,

    Alexey Kisliy

    Monday, August 13, 2012 2:03 PM
  • Ever since it went from DDK to WDK the compiler to build the product is included in the package.  What is not included is the IDE from visual studio.  DDKBuild will work with 7600.16385.1 is just doesn't work with older WDK's anymore.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Monday, August 13, 2012 2:10 PM
  • Thank you for the answer.

    So Visual Studio 2010 Professional + DDKBuild + WDK 7600.16385.1 will be ok for my purposes?

    --

    Kind regards,

    Alexey Kisliy

    Monday, August 13, 2012 2:15 PM
  • Yes, it should work fine.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Monday, August 13, 2012 2:16 PM
  • Thank you. It's clear now.

    --

    Kind regards,

    Alexey Kisliy

    Monday, August 13, 2012 2:26 PM
  • If you already have VS professional (or more expensive) - fine. Don't buy VS just to make a driver. VC++ express or even any free editor will suffice.

    -- pa

    Monday, August 13, 2012 3:13 PM
  • have you tested your driver on XP?  XP will load a windows 2000 driver just fine. That is far simpler than rewriting. COM ports have not had much change since win2k, so from a compat point of view you should also be pretty safe.

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

    Monday, August 13, 2012 4:40 PM
  • My driver works excellent on XP. It does not work on Windows 7. It is written on WDM and I'm afraid, that I will need to re-write it, not just convert.

    Suggest, please, which type of project in Visual Studio 2010 Professional with DDKBuild and WDK should I create for converting the old driver into project with Windows 7 support?

    --

    Kind regards,

    Alexey Kisliy



    Monday, August 13, 2012 8:48 PM
  • how does it not work? bluescreen/bugcheck? doesn't load? have you attached a kernel debugger and root caused the problem? without knowing the problem, a rewrite is not going to help you


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

    Monday, August 13, 2012 8:56 PM
  • It doesn't load. It doesn't work. The system says, that COM port driver has error 37 - just does not work. I have not yet debugged it. Tomorrow will try to debug. Suggest me, please, how to convert it into VS 2010? VS 2010 by default does not have project template for *.sys files creating.

    What does it mean "root caused the problem"? And one more question: how to attach kernel debugger?

    Thank you in advance for your answers.

    --

    Kind regards,

    Alexey Kisliy



    Monday, August 13, 2012 9:05 PM
  • You need to step back a bit from your visual studio orientation. The WDK 7600.16385.1 tools, as noted upthread, contain a complete set of command line/make file oriented build utilities to create .sys files, but they are not integrated at all with visual studio. Just to confuse things, the Win8 WDK is integrated with Visual Studio 2012, but you cannot build anything for XP with those tools.

    First create a standard WDK 7600.16835.1 project for your driver using a SOURCES  file as documented in the help for that WDK and in the many samples that come with it. Once you have a basic understanding of how to build a driver using these tools you can integrate your WDK project (the one with the sources file ) into visual studio 2010 using my ddkbuild.bat batch file by creating an "external makefile" project out of the existing WDK project. I more or less document how to do this here:

    http://hollistech.com/Resources/ddkbuild/ddkbuild.htm

    The doc is for an older version of VS, but it is accurate enough.


    Mark Roddy Windows Driver and OS consultant www.hollistech.com

    Tuesday, August 14, 2012 1:43 PM
  • Is your win7 64-bit? Is this a signing issue?

    -- pa

    Tuesday, August 14, 2012 2:07 PM
  • the win7 WDK installs the kernel debugger (windbg.exe) and there is a tutorial document there on getting started.  by root causing the problem, that means you understand exactly what the point of failure is.  "it doesn't load" is not root cause, that is a side effect of something else, probably a missing import resolution.


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

    Tuesday, August 14, 2012 5:08 PM
  • No. I develop for Windows 7 32-bit.

    --

    Kind regards,

    Alexey Kisliy 

    Tuesday, August 14, 2012 5:33 PM
  • Hi, I've read this usefull reference documentation: http://msdn.microsoft.com/en-us/library/windows/hardware/gg583865%28v=vs.85%29.aspx

    There are described how to port driver from WDM to KMDF. Now I'm analysing the WDM code. My question is next: how to figure out, which parts of WDM code and in which cases I have to port to KMDF? Or I have just compile/build/assemble a new project in WDK 7600.16385.1 with my old WDM code, then using DDKBuild start working with the project inside of Visual Studio 2010, then fix all the bugs and...Ok. I've fixed everything for example, but how can I figure out, which parts of the WDM driver code I have to port to KMDF and which leave intact?

    Thank you in advance for the answers .

    --

    Kind regards,

    Alexey Kisliy




    Wednesday, August 15, 2012 11:29 AM
  • ..."it doesn't load" is not root cause, that is a side effect of something else, probably a missing import resolution.

    Sorry, but what is "missing import resolution"? Googled it, but have not found.

    --

    Kind regards,

    Alexey Kisliy


    Wednesday, August 15, 2012 11:34 AM
  • Missing import resolution, means your driver is referencing a symbol that is no longer exported by the kernel.  For example if you call OldFunc and that has now been removed that will fail that way.  Turn on SetupApi logging in Windows 7 and try loading your driver, this should help explain the failure.  As Doron pointed out if it works fine with XP, then try to make it work on Win 7 before starting over.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Wednesday, August 15, 2012 12:29 PM
  • Hi, All,

    I've successfully imported my old project into Visual Studio 2010 IDE using DDKBuild. Fixed all the errors. Then built the *.sys file. After that I've turned on SetupApi in Windows 7(on the target machine of course) and tried to load my driver - without success. And in setupapi.dev.log I've got next error:

    Device not started: Device has problem: 0x25: CM_PROB_FAILED_DRIVER_ENTRY.

    I've tried to debug the driver with Windbg.exe today, but without success. Just my Windbg.exe on the host machine has not been connected to the Target machine with a driver. I've tested linking of my two machines with serial cable - linking works just fine.

    So, point me, please, what can be the problem inside the driver in case of loading error pointed above.

    And of course next days I will try to debug DriverEntry function and try to figure out, why it does not load on Windows 7.

    --

    Kind regards,

    Alexey Kisliy

    Friday, August 17, 2012 3:47 PM
  • You did setup debugging on the client machine with bcdedit I assume?  If not or to confirm things grap the OSRSYSTOOL http://www.osronline.com/article.cfm?article=537 and use it for setting everything needed for debugging. 

    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Friday, August 17, 2012 4:02 PM
  • CM_PROB_FAILED_DRIVER_ENTRY means that your driver has been loaded and its DriverEntry called but returned some error.

    Windbg is your friend, try harder with it. Could it be that you have only one com port and the debugger is using it? The serial cable for windbg should be as described in the windbg help, not every "laplink" cross cable is good for it.

    -- pa


    • Edited by Pavel A Sunday, August 19, 2012 2:32 AM
    Sunday, August 19, 2012 2:30 AM
  • You did setup debugging on the client machine with bcdedit I assume?  If not or to confirm things grap the OSRSYSTOOL http://www.osronline.com/article.cfm?article=537 and use it for setting everything needed for debugging.

    I did setup on the client machine(target machine, on which is my COM port with my driver) with bcdedit, of course. Now I try to run my driver on Windows 7 32-bit. I think I do not need OSRSYSTOOL.

    --

    Kind regards,

    Alexey Kisliy


    Monday, August 20, 2012 1:46 PM
  • Hi, All,

    Now I try to force debugging process, but unsuccessfully. I will describe the situation.

    So, I've tried at first run debugging process through serial cable between two physical machines - unsuccessfully. Now I try to run debugging process between my laptop(physical machine, Windows 7 64-bit) and VMWare Workstation 8 Virtual machine with Windows 7 Ultimate 32-bit.I've did next preparations using this article http://briolidz.wordpress.com/2012/03/28/windows-driver-debugging-with-windbg-and-vmware/:

    1) On the virtual machine:

    1. Created virtual serial port 2 and did setup \\.\pipe\BriolidzDbgPipe for the Used named pipe. Chose "This end is the server" and "The other end is virtual machine", but of course played yet with the "This end is the client" and "The other end is application" - unsuccessfully. Checked "Yield CPU on poll".

    2. Executed next bcdedit commands in cmd.exe running under administrator rights:

    bcdedit /set {current} debug yes
    bcdedit /set {current} debugtype serial
    bcdedit /set {current} debugport 2
    bcdedit /set {current} baudrate 115200

    bcdedit /set {bootmgr} displaybootmenu yes

    bcdedit /timeout 10

    3. Putted *.inf file for my driver into C:\Windows\inf folder.

    4. Installed my driver(*.sys file for the COM port number 2).

    2) On the host(debugging machine):

    1. Installed Windows Driver Kit 7.1;

    2. In command line running with administrator rights executed next command:

     set _NT_EXECUTABLE_IMAGE_PATH= {my path1}

    set _NT_SOURCE_PATH={my path2}

    3. Have run WinDBG.exe with Administrator rights.

    4. Have pointed symbol file path as:  
    SRV*c:\symbols*http://msdl.microsoft.com/download/symbols and created folder c:\symbols.

    5. Have chosen File->Kernel Debug->Com tab and typed in next settings: 

    Baud Rate: 115200

    Pipe: checked

    Reconnect: checked

    Resets: 0

    Port: \\.\pipe\BriolidzDbgPipe . Pressed ok.

    After this I've got message:

    Waiting for pipe...

    Waiting to reconnect...

    After this I've started virtual machine and got next message. You can see it from picture below(yes on this picture I've played with another serial named pipe, but anyway I've did everything like described above).

    All the time I get this messages in WinDbg command pane:


    So, what do I wrong and how can I run debugging process and step into DriverEntry function?

    And all the time after this message in this window my virtual COM port on the target machine disappears from the Device Manager.

    --

    Kind regards,

    Alexey Kisliy




    Monday, August 20, 2012 2:26 PM
  • It is hard to tell what is wrong - from the screenshot, you are indeed connected to the target and can do commands.

    If you want your own driver to be COM2 on the target (the VM), COM2 cannot be used for kernel debugger. It must be a real serial port (if this can be said about a virtual thing on a virtual machine).

    Read the windbg help file first, before andy 3rd party blogs and advices. Look up in the index about setup on VMware ("Attaching to a Virtual machine").

    Try to start with some small and simple WDK example driver.

    If you need to debug a phyiscal machine - check that you have correct cable.

    Also, instead of suffering with %#$! bcdedit, just run msconfig and select startup in debug mode and all the settings. Ok, real programmers don't use msconfig, but this is just to let you start.

    -- pa


    • Edited by Pavel A Monday, August 20, 2012 3:11 PM
    Monday, August 20, 2012 3:07 PM
  • Thank you for the answer, Pavel.

    I can not insert commands I think, because from the screenshot you can see, that debugger is busy. But may be from "Add to Command Output" window. Don't know.

    So as I've got right I can not debug my own COM2 driver installed on the virtual machine? As I've got this third party article is wrong and my own driver can be debugged only on the real physical machine with physical COM port, right? I've read index "("Attaching to a Virtual machine")" - there goes about kernel debugging, but doesn't mention about whether it is possible to debug COM driver on the virtual COM port on the VM.

    About serial cable: I have one - it is USB-COM cable. I've connected with it my laptop and PC with a COM port, on which my own driver is installed. I've checked with Hyperterminal - connection of these PCs works just fine, I can send messages between them through Hyperterminal. By the way my laptop(host machine, debugging machine, on which I develop the driver) doesn't have COM port. Should I find COM-COM serial cable and host machine with a physical COM-port?

    --

    Kind regards,

    Alexey Kisliy

    Monday, August 20, 2012 3:58 PM
  • if you driver is failing to load because of a missing import, setting a breakpoint on your DriverEntry is not going to help you.  it will help if DriverEntry is returning failure for some reason

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

    Monday, August 20, 2012 4:59 PM
  • It's clear. I will recheck of course whether my driver is missing the import. The point is, how to force the process of debugging. 
    Monday, August 20, 2012 6:50 PM
  • 1. Yes you can't enter commands when debugger is busy. Do Debug/Break and wait until the prompt kd> appears. "Add to command output" isn't it.

    2. Of course you can debug your COM driver, but it should not be the "virtual" com port on the guest. These virtual ports are owned by Vmware. Sorry if I misunderstood your prev. reply. You can try to open it by some app running in the same guest VM, such as hyperterminal.

    Also your COM port cannot be used by the kernel debugger.

    3. An USB to serial dongle is ok, I use it often and it works great. The serial end must be connected to the target and USB end to the host. Pinout on the serial end must be like this.

    The windbg helpfile unfortunately no longer provides the cable pinout.

    -- pa

    Monday, August 20, 2012 7:34 PM
  • 1.  "Add to command output" isn't it. - So, then with which menu item I can enter commands if not with this? 

    2. Sorry, but it's unclear for me. So, the conclusion is just that, that I can not debug my driver on these virtual COM ports owned by Vmware, right? So next conclusion will, that in my case I can debug my own driver only on physical machine with a physical COM port, right? What does it mean - COM port cannot be used by the kernel debugger? My COM driver is a kernel mode driver. So, I need to debug it in a kernel mode. How can I do that if COM port cannot be used by the kernel debugger? May be another debugger exists that can debug COM drivers that work in kernel mode? 

    3. So, if I can send messages through the hyperterminal between two physical machines connected with COM-USB cable, can I say that this cable is ok for my purposes(debugging of the COM driver that works in kernel mode)?

    --

    Kind regards,

    Alexey Kisliy 

    Monday, August 20, 2012 7:58 PM
  • 1. You can enter commands only when the "command line" input box appears at the bottom of windbg window and you see the "kd>" prompt. Then just type there. But it won't show up until windbg connects to the target and breaks in.

    2. At this point we probably should ask what your driver/device does? Is it replacement of a standard serial driver (why?) or what is your actual hardware device? the answer will be useful to decide what is the best course to debug it.

    3. Hyperterminal working between the machines is nesessary but not enough. If the cable is good, windbg usually connects quickly and reliably. If not, the cable is probably not good. Use baudrates 19200 or 38400 to test. 

    -- pa



    • Edited by Pavel A Monday, August 20, 2012 10:56 PM
    Monday, August 20, 2012 10:49 PM
  • 1. It's clear now. Thanks.

    2. My device is a standard COM port on one controller. The only difference is, that it has one additional shared memory(memory buffer). That is all. In other cases it's just a usual COM port. Yes, may be now I should compare the code of a standard serial port driver example from WDK with my old code without debugging - don't know... May be I will do that to figure out differences, how much it differs from a standard COM port. 

    Yes it's replacement of a standard serial driver, just with a description of this shared memory inside my custom COM port. Sorry, but I have no specification, can not describe deeper what for device it is. 

    So, is it enough of information to figure out the course of how to debug my driver? 

    3. Sorry for reasking: if hyperterminal will work peroperly between two machines with baudrates 19200 and 38400, can I just be sure that this way is ok for me? Or how can figure out whether my cable feets my needs? 

    --

    Kind regards,

    Alexey Kisliy 


    Tuesday, August 21, 2012 2:35 AM
  • Thank you, guys,

    Successfully debug my driver. Now I can see what does not work.

    --

    Kind regards,

    Alexey Kisliy

    Tuesday, August 21, 2012 1:39 PM
  • Now I'm debugging my driver.I have entry point function with next signature:

    NTSTATUS
    DriverEntry(
        IN PDRIVER_OBJECT DriverObject,
        IN PUNICODE_STRING RegistryPath
        )

    Suggest , please, whether field DriverObject->DeviceObject of the PDRIVER_OBJECT structure should be coming into the function already filled not just 0x00000000? And if yes, what can I do with this parameter(IN PDRIVER_OBJECT DriverObject) to force it be initialized from the very beginning?

    Because now DriverObject->DeviceObject has value 0x00000000 and this is the cause why my driver does not work.

    --

    Kind regards,

    Alexey Kisliy

    Tuesday, August 21, 2012 2:39 PM
  • Please consider starting a new question, it is getting hard to find you question to respond.  No the DeviceObject will not be set to a device object, you haven't created one yet.  It is rare that you should be using that field under most circumstances.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Tuesday, August 21, 2012 2:45 PM
  • Thanks. It's clear now.

    --

    Kind regards,

    Alexey Kisliy

    Tuesday, August 21, 2012 3:00 PM