none
Conflict of the COM drivers RRS feed

  • Question

  • Hi,

    Suggest me, please, how can two COM port drivers be in a conflict. I will describe the situation. I have 2 KMDF COM drivers with our custom functionality that we have added to a standard KMDF COM port driver sample from Windows Driver KIt.

    Our functionality works in Kernel Mode.

    The situation is so, that on the current PC we have 3 free COM ports, on which we install our drivers.  So, on two of them I have installed two COM port drivers of one type(Driver 1) and on 3rd one have installed second COM port driver(Driver 2). Drivers support PnP, so in this case I test drivers with devices on COM ports without reboot - they work.

    After reboot I see, that Driver 1 is not installed on COM 1 and COM 2 anymore - it has yellow exclamation mark on every COM port in device manager. Then I try to reinstall the Driver 1 on these two COM ports - can not. And only if I uninstall Driver 2 from COM 3, only then I can Install Driver 1 again.

    So, after reboot if Driver 2 installed, Driver 1 can not be installed.

    Suggest, please, what can be the cause of a such behavior and how to fix it.

    --

    Kind regards,

    Alexey Kisliy

    Monday, October 22, 2012 9:56 AM

Answers

  • Alexey,

        If you can make it a filter driver I would.  Microsoft will continue to fix bugs and improve the COM driver which presents two problems for you:

       1.  Microsoft will issue Windows updates with the new driver which are likely to cause the problem all over again.

       2.  Your complete COM driver will miss these bug fixes or require its own parallel maintenance.

        I don't know what your new IOCTL are doing but I would believe it should be fairly easy to create a KMDF filter to implement them.


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

    • Marked as answer by Oleksii Kyslyi Tuesday, October 23, 2012 6:31 PM
    Tuesday, October 23, 2012 5:06 PM

All replies

  • Your INF files are probably specifying the same hardware ID (in this case ACPI ID) for the devices.  Unless one of the devices has a uniq ID and you use that one for your driver you have a problem.  I would recommend modifying your driver so that is has all the standard COM functionality unless it finds a registry setting or recieves a new IOCTL from a user program to put in the special handling.


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

    Monday, October 22, 2012 11:12 AM
  • Thank you for the answer, Donald.

    I have not found in my inf-files the hardware ID(ACPI ID) you have mentioned above.

    This is my inf file. It is very similar for both COM drivers:

    May be you can see the problem? The inf file has been checked with ChkInf  - everything is ok except signing, but you said, that without signing drivers will work on Windows 7 successfully.

    ;====================================================================
    ;
    ; COMDriver.inf
    ;
    ; Installation file (.inf) for the COMDriver.
    ;
    ; (c) Copyright 2012  GmbH
    ;
    ; Port drivers setup
    ;
    ; Supported operating systems:
    ;   Windows XP
    ;   Windows 7
    ;
    ;====================================================================


    ;--------------------
    ; Konstanten
    ;--------------------

    [Strings]

    ;==Hersteller
    PROVIDER = "DKT GmbH"

    ;==Hersteller Abkürzung
    DKT  = "DKT"

    ;==DeviceClass
    DeviceClassName = "Ports"  ;Description of Device class

    ;==Device Name
    DKT-COM  = "DKT-COM"  ;Device in device class

    [DestinationDirs]
    DefaultDestDir = 12     ;; System32\Drivers

    [ControlFlags]
    ExcludeFromSelect=*

    ;--------------------
    ; Start
    ;--------------------

    [Version]

    Signature  = "$Windows NT$"
    Class   = %DeviceClassName%
    ClassGuid  = {4D36E978-E325-11CE-BFC1-08002BE10318}
    Provider  = %PROVIDER%
    DriverVer = 29/08/2012, 3.0.1.0


    ;--------------------
    ; Driver information
    ;--------------------

    [Manufacturer]

    %DKT%    = DeviceList


    ;--------------------
    ; Device Installation
    ;--------------------

    [DeviceList]

    %DKT-COM%  = DKT-COM-Install, DKT\DKT-COM

    [DKT-COM-Install]

    Addreg  = DKT-COM-AddReg


    [DKT-COM-AddReg]

    HKR, , PortSubClass, 1, 01    ; COM
    HKR, , EnumPropPages32, ,"msports.dll,SerialPortPropPageProvider"


    [DKT-COM-Install.Services]

    AddService = dktCOM, 0x00000002, DKT-COM-Service-Inst, DKT-COM-EventLog-Inst


    [DKT-COM-Service-Inst]

    DisplayName = "DKT-COM Driver"
    ServiceType = 1                ; SERVICE_KERNEL_DRIVER
    StartType = 2                ; SERVICE_AUTO_START
    ErrorControl = 1                ; SERVICE_ERROR_IGNORE
    ServiceBinary = %12%\dktCOM.sys  ;12 = Drivers directory
    LoadOrderGroup = port


    [DKT-COM-EventLog-Inst]

    AddReg  = DKT-COM-EventLog-AddReg


    [DKT-COM-EventLog-AddReg]

    HKR, , EventMessageFile, 0x00020000, "%%SystemRoot%%\System32\IoLogMsg.dll;%%SystemRoot%%\System32\drivers\dktCOM.sys"
    HKR, , TypesSupported, 0x00010001, 7

    --

    Kind regards,

    Alexey Kisliy  






    Monday, October 22, 2012 12:45 PM
  • My drivers has the whole functionality of the standard KMDF COM driver sample and I've added just additional IOCTLs.

    --

    Kind regards,

    Alexey Kisliy


    Monday, October 22, 2012 2:08 PM
  • That above is the old inf from old WDM driver.

    I have new one from KMDF and there I have found these equal ACPI IDs:

    Driver 1:

    ; For XP and later
    [MSFT.NTx86]
    ; DisplayName           Section           DeviceId
    ; -----------           -------           --------
    %PNP0500.DevDesc%=       Serial_Inst,      *PNP0500, *PNP0501 ; Driver1
    %PNP0501.DevDesc%=       Serial_Inst,      *PNP0501, *PNP0500 ; Driver1

    Driver 2:

    ; For XP and later
    [MSFT.NTx86]
    ; DisplayName           Section           DeviceId
    ; -----------           -------           --------
    %PNP0500.DevDesc%=       Serial_Inst,      *PNP0500, *PNP0501 ; Driver2
    %PNP0501.DevDesc%=       Serial_Inst,      *PNP0501, *PNP0500 ; Driver2

    --

    Kind regards,

    Alexey Kisliy


    Monday, October 22, 2012 3:21 PM
  • your first INF has this

    [DeviceList]

    %DKT-COM%  = DKT-COM-Install, DKT\DKT-COM

    DKT\DKT-COM is the hardware ID in the INF.  who enumerates this hardware ID? how are you installing this driver? with devcon install?

    in your second INF you have PNP0501 and 500, which are standard ISA UART 16550 COM port HW IDs.  the in box driver will also match to this hardware id


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

    Monday, October 22, 2012 4:24 PM
  • I don't understand what does it mean "who enumerates this hardware ID?". What do you mean? Explain, please.

    No, I don't install drivers using devcon, because I have PnP drivers. I just put inf file into Windows\Inf folder, sys-file into Windows\system32\drivers folder and then manually in device manager I install driver for the com ports. Later it will be done using InstallSchield.

    So for my Driver 1 and Driver 2 these PNP0501 and 500 should be different?

    --

    Kind regards,

    Alexey Kisliy

    Monday, October 22, 2012 4:52 PM
  • Alex (jumping back in after being out of the office) the problem is that PNP0501 and PNP0500 will grab all com ports, but you have installed a driver for a specific com port that is different hence the conflict.  Is the third com port your own hardware and if so could you make it unique enough to not normally be recognized as a com port?  If not you are faced with the challenge of replacing an in-box driver which is never a good idea.

    One other question, could the IOCTL's you added be done in a filter driver for the standard COM driver or do they need to interact with the hardware?


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

    Monday, October 22, 2012 5:00 PM
  •       Who enumerates the hardware ID

    where did the string "DKT\DKT-COM" come from? did you make it up?


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

    Monday, October 22, 2012 5:10 PM
  •       Who enumerates the hardware ID

    where did the string "DKT\DKT-COM" come from? did you make it up?


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

    Yes, we write "DKT\DKT-COM". In Driver 1 and in Driver 2 these hardware IDs are different. But I should say - this is from old inf from 2006. KMDF version of COM ports created by WinDDK has *PNP0500, *PNP0501 in inf files mentioned above.

    --

    Kind regards,

    Alexey Kisliy


    Tuesday, October 23, 2012 8:59 AM
  • Alex (jumping back in after being out of the office) the problem is that PNP0501 and PNP0500 will grab all com ports, but you have installed a driver for a specific com port that is different hence the conflict.  Is the third com port your own hardware and if so could you make it unique enough to not normally be recognized as a com port?  If not you are faced with the challenge of replacing an in-box driver which is never a good idea.

    One other question, could the IOCTL's you added be done in a filter driver for the standard COM driver or do they need to interact with the hardware?

    Thank you very much for the answer, Donald.

    Yes I always will install my drivers for a specific com ports.

    My third com port is usual com port on the PC without specific functionality like all others. Yes we replace in-box driver with a standard COM port driver just with added some IOCTL's to it to communicate in Kernel Mode with our software(Driver 1) and hardware(Driver 2). Driver 1 works just with our software that works in Kernel Mode. And Driver 2 communicates with a hardware device that is connected to the third com port(or another one).

    I don't know whether IOCTL's I've added could be done in a filter driver. Just never tried. But this is what you always told me to do on this forum during last 2-3 monthes. Just I've added IOCTL's to the standard COM port driver sample and it seems like it work. Just I face this problem with hardware IDs.

    Is it possible just to fix the problem with hardware IDs and left driver implemented like it is without writing a filter driver(for IOCTL's) over usual COM port driver?

    --

    Kind regards,

    Alexey Kisliy

    Tuesday, October 23, 2012 9:31 AM
  • So, what will be your real ID: *PNP something or DKT\DKT-COM?

    If the latter, you just install your driver on it and give it a different service name so it won't conflict with serial.sys in any way. If the former - do as Mr. Burn advices, because he knows better: either completely replace the in-box serial.sys with yours for _all_ ports, or write a filter over in-box serial.sys, which will only attach to your port.  While installing different drivers on instances of same h/w ID is possible, it is _not recommended_ (IOW, it's asking for trouble).

    -- pa

    In old inf for Windows 2000 and XP as I understood right my IDs are DKT1\DKT1-COM and DKT2\DKT2-COM for Driver 1 and Driver 2. Something like that. But for inf files which have been created by WinDDK 7.1 - it is "PNP something".

    What do you mean under service name?

    I do not use serial.sys. I have used serial.sys as example and have added there some IOCTLs in both drivers(different IOCTLs for every driver).

    What did you mean under "If the former"?

    I can not completely replace the in-box driver with one driver type. I have two drivers. So, on some COM ports I install first driver, on others second driver.

    I install different drivers on instances of the same h/w ID, but it does not work. Drivers are like in a conflict.

    It's interesting, what Mr. Burn will answer on my previous questions.

    --

    Kind regards,

    Alexey Kisliy

    Tuesday, October 23, 2012 1:33 PM
  • In old inf for Windows 2000 and XP as I understood right my IDs are DKT1\DKT1-COM and DKT2\DKT2-COM for Driver 1 and Driver 2. Something like that. But for inf files which have been created by WinDDK 7.1 - it is "PNP something".

    So which one will be the real one that you will actually have? Is this correct that DKT1-COM is for the old non-PnP (?) driver, and you no longer have the DKT1 thing in the new  system? These IDs do not belong to KMDF or WDK, only you know what they are (or should be).

    The "DKT1" probably is some sort of "software bus" driver, which "creates" DKT1\DKT1-COM device. /* This is called "enumeration". If these terms (enumeration, services) are new to you, please have a look in the WDK documentation. */

    -- pa

    I have KMDF modified serial COM port driver samples with added my IOCTLs. I test with these my two drivers both infs: old infs and new ones - drivers do not work together.

    Right. DKT1-COM is for old non-PnP drivers. In the new system as I've said I test old and new infs, so try using infs with "DKT1" and "PnP something" hw IDs- drivers do not work together.

    Actually under "DKT1" stands the name of our customer - it's just a string. And there is no "software bus" drivers - just COM port samples with added IOCTLs.

    Thank you for pointing about "enumeration" and "services".

    --

    Kind regards,

    Alexey Kisliy

    Tuesday, October 23, 2012 2:29 PM
  • Mr. Burn, could you be so kind to throw light on a problem... What will your last verdict, filter driver or we can do something with existing drivers?

    --

    Kind regards,

    Alexey Kisliy

    Tuesday, October 23, 2012 4:52 PM
  • Alexey,

        If you can make it a filter driver I would.  Microsoft will continue to fix bugs and improve the COM driver which presents two problems for you:

       1.  Microsoft will issue Windows updates with the new driver which are likely to cause the problem all over again.

       2.  Your complete COM driver will miss these bug fixes or require its own parallel maintenance.

        I don't know what your new IOCTL are doing but I would believe it should be fairly easy to create a KMDF filter to implement them.


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

    • Marked as answer by Oleksii Kyslyi Tuesday, October 23, 2012 6:31 PM
    Tuesday, October 23, 2012 5:06 PM
  • Mr. Burn, one more question. In the case of filter driver creation this conflict of the drivers hardware IDs will disappear and our COM drivers will work at the same time?

    And one more question: should I implement filter driver for both our drivers(Driver 1 stands for communication with our software and Driver 2 stands for communication with a hardware device that is connected to a Com port)?

    P.s. Because now our drivers work together after installing without reboot and after reboot I see that Driver 1 is not installed correctly anymore(yellow exclamation mark on every COM port with installed Driver 1 in device manager.)

    --

    Kind regards,

    Alexey Kisliy
    Wednesday, October 24, 2012 10:55 AM
  • And one more question, why in Windows XP approach of adding IOCTL's into standard COM port driver sample did the job for us for years, worked well and now in Windows 7 this approach does not work good enough? 

    --

    Kind regards,

    Alexey Kisliy 


    Wednesday, October 24, 2012 11:14 AM
  • Alexey,

        The conflict disappears since your hardware driver goes away and the only driver left is the Microsoft driver.  I don't know enough about your model, but typically you want the filter to work over all the devices, but have smarts for the one you need.

        As far as the XP question, this is something Doron or one of the Microsoft folks could probably give more detail.  This type of problem could happen for any PnP OS, but I believe XP may have been more likely to maintain the driver mapping.


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

    Wednesday, October 24, 2012 1:40 PM
  • Mr. Holan, what would you say about questions in last my posts above?

    --

    Kind regards,

    Alexey Kisliy

    Wednesday, October 24, 2012 1:49 PM
  • win7 tries to be more consistent with device install state

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

    Wednesday, October 24, 2012 3:02 PM
  • Thank you, Mr. Holan. 

    It's clear now. 

    --

    Kind regards,

    Alexey Kisliy 

    Wednesday, October 24, 2012 3:43 PM
  • While installing different drivers on instances of same h/w ID is possible, it is _not recommended_ (IOW, it's asking for trouble).

    -- pa

    Dear Pavel A,

    Could you please tell, how it is possible to install different COM port drivers on instance of same h/w ID without conflict?

    Now we use on one COM port standard Microsoft in-box COM Driver and on another COM port we use standard Microsoft in-box COM Driver with modified for our purposes IOCTLs and ISRs. So, we have problem of same Hardware IDs and our two drivers can not be installed simultaniously on a System(Windows 7).

    We actually need to run mentioned above two drivers parallel, but now after reboot our modified in-box COM driver deactivates with yellow exclamation mark standard Microsoft in-box COM driver.

    --

    Kind regards,

    Oleksii Kyslyi


    • Edited by Oleksii Kysl Wednesday, September 23, 2015 8:02 AM
    Wednesday, September 23, 2015 8:02 AM