For our USB device I have written a virtual com port driver. We use WinUSB and WUDFRD (UMDF) as lower driver. In the INF-file the PORTS-class is referenced and in the Models section the USB device:
When the USB device is connected to the PC, a device is correctly added, and according to the VirtualSerial example I configure the COM port. Get the portName from the PropertyStore and set the DEVICEMAP\SERIALCOMM key. The ComDb is (from who?) updated with the next free port.
When I disconnect the USB device, the SERIALCOMM key is deleted (done myself in OnCleanup). But the ComDb is not updated (the bit is not deleted). Btw. IObjectCleanup::OnCleanup() is called two times.
The questions are, who is responsible for the ComDb (serial?, wudrfd?) and what prevents the release of the ComDbEntry. Or do I need to release it myself?
The com port name is persisted for as long as your driver is installed on the device, the ComDb entry is not tied to physical reported presence. The ports class coinstaller does the ComDb work. To release the name, uninstall your driver software on the devnode
d
Bent from my phone
From: xxxxx@ifak-system.commailto:xxxxx Sent: ?11/?7/?2013 6:06 AM To: Windows System Software Devs Interest Listmailto:xxxxx Subject: [ntdev] [(virtual) com port; UMDF] ComDb Entry not released
Hallo.
For our USB device I have written a virtual com port driver. We use WinUSB and WUDFRD (UMDF) as lower driver. In the INF-file the PORTS-class is referenced and in the Models section the USB device:
When the USB device is connected to the PC, a device is correctly added, and according to the VirtualSerial example I configure the COM port. Get the portName from the PropertyStore and set the DEVICEMAP\SERIALCOMM key. The ComDb is (from who?) updated with the next free port.
When I disconnect the USB device, the SERIALCOMM key is deleted (done myself in OnCleanup). But the ComDb is not updated (the bit is not deleted). Btw. IObjectCleanup::OnCleanup() is called two times.
The questions are, who is responsible for the ComDb (serial?, wudrfd?) and what prevents the release of the ComDbEntry. Or do I need to release it myself?
thank you very much, even if this is not the desired answer
If I understand you, the driver is installed, when the USB device is first time plugged in. But to deinstall it, we need something like “devcon remove …”. Can’t hardly be done by the driver itself, hm? And that would mean, every other USB device with same pid from our company will work on same COM port number?
What would be the way to get the requested behaviour? (Plugin USB device -> COM Port appears / Unplug USB device -> COM Port disappears [completely!]). Install/Remove by hand outside the driver in a always running service (handle something like device arrival and device remove completed).
No driver can uninstall itself. What you want to do is not supported by windows. A device with the same.pid/vid will be a new device instance and thus a new com port number…unless they both have the same serial number, in which case that is a spec violation
d
Bent from my phone
From: xxxxx@ifak-system.commailto:xxxxx Sent: ?11/?7/?2013 7:38 AM To: Windows System Software Devs Interest Listmailto:xxxxx Subject: RE:[ntdev] [(virtual) com port; UMDF] ComDb Entry not released
Hello Doron,
thank you very much, even if this is not the desired answer
If I understand you, the driver is installed, when the USB device is first time plugged in. But to deinstall it, we need something like “devcon remove …”. Can’t hardly be done by the driver itself, hm? And that would mean, every other USB device with same pid from our company will work on same COM port number?
What would be the way to get the requested behaviour? (Plugin USB device -> COM Port appears / Unplug USB device -> COM Port disappears [completely!]). Install/Remove by hand outside the driver in a always running service (handle something like device arrival and device remove completed).
For an USB device:
* You install the driver (divxcmd /i xxx.inf 16)
* When device is plugged in -> device manager recognized and add the device (without !) * When device is unplugged -> device is removed (without !) -> after these steps the driver is still installed on system, but not the device
For our USB Virtual COM Port: * You install the driver (same procedure as above) * when the device is plugged in -> device manager recognized and add the device (without any additional installation step; done in the ports class installer) * when the device is removed -> there are still leftovers (ComDb); not completely removed in device manager!
Isn’t that a design flaw? Or I am something missing?
Which means neither of the above actions are equivalent to devcon remove. Right click, uninstall in device manager is equivalent. In other words the lifetime of the install state of the device is not tied to physical presence once the driver is installed, it is tied to a specific action in software to remove the driver and the install state from the devnode.
Your first step staged the driver package so it is available on the system, thus removing the step of using devcon.
What bigger problem are you trying to solve ?
d
Bent from my phone ________________________________ From: xxxxx@ifak-system.commailto:xxxxx Sent: ?11/?7/?2013 11:54 PM To: Windows System Software Devs Interest Listmailto:xxxxx Subject: RE:[ntdev] [(virtual) com port; UMDF] ComDb Entry not released
Perhaps I ambiguous expressed the expectations.
For an USB device: * You install the driver (divxcmd /i xxx.inf 16) * When device is plugged in -> device manager recognized and add the device (without !) * When device is unplugged -> device is removed (without !) -> after these steps the driver is still installed on system, but not the device
For our USB Virtual COM Port: * You install the driver (same procedure as above) * when the device is plugged in -> device manager recognized and add the device (without any additional installation step; done in the ports class installer) * when the device is removed -> there are still leftovers (ComDb); not completely removed in device manager!
Isn’t that a design flaw? Or I am something missing?
I still have difficulties to understand. I will show you step by step, what I mean:
Lets take the UMDF VirtualSerial example from the WinDDK:
To install the driver on the target pc you can use “DIFxCmd /i VirtualSerial.inf 16”. This will install the driver into the file repository
To create a Virtual Com Port you can use “devcon install virtualserial.inf UMDF\VirtualSerial”. This will create a new Com Port in the device manager (next free claimed). In the registry the “DEVICEMAP\SERIALCOMM” get a new entry (inserted by the virtualserial.dll device driver), and the ComDb entry under “CurrentControl\Control\COM Name Arbiter” is updated with the according bit set.
To remove this Virtual Com Port you can use “devcon remove UMDF\VirtualSerial”. This removes the entry in the device manager. The registry entry under SERIALCOMM is removed. And the bit in the ComDb ist deleted! The driver is still available in the file repository (completely removable by “DIFxCmd /u VirtualSerial.inf 32”.
Now to our own Virtual Com Port (btw. build directly on the WinDDK example):
The most important changes are:
(INF) instead “UMDF\VirtualSerial” as hwid in the Models section we have “USB\VID_XXXX&PID_XXXX” (with our vendor & product id)
(INF) additional entries for WinUsb as lower filter service (no extra WinUsb inf file needed)
(DLL) extra code for needed functionality.
When we go the same steps as in installing/using VirtualSerial the following happens:
“DIFxCmd /i our_driver.inf 16”
Works as expected. Driver is inserted in file repository.
plugin USB device (not “devcon install …”! -> this is done automatically)
As above a new COM Port is created in device manager. SERIALCOMM updated (as coded in dll). AND of course the appropriate ComDb Entry bit is set.
Unplug USB device (not “devcon remove …”! -> this is also done automatically)
As above the COM Port is removed from device manager, the SERIALCOM key is deletete, BUT THE COMDB IS NOT UPDATED!
-> Is that really the expected behaviour?
Last thought: Could it be, that I have bugs in my driver dll and therefore the driver is not really finished while removing the device. And this crash prevents the correct disabling of the ComDb bit?
I’m very sorry to be so annoying, but I do want to understand the logic behind this!
Unplug USB device (not “devcon remove …”! -> this is also done automatically)
As above the COM Port is removed from device manager, the SERIALCOM key is deletete, BUT THE COMDB IS NOT UPDATED!
This is a physical removal of the device. It is NOT equivalent to devcon remove. A virtual device cannot be physically removed so perhaps this is why you are confused. Go to the virtual com port stack in device manager and choose disable. You will see exactly the same thing as the USB com device example…SERIALCOM is cleaned up, ComDb port name still claimed
d
Bent from my phone
From: xxxxx@ifak-system.commailto:xxxxx Sent: ?11/?8/?2013 5:39 AM To: Windows System Software Devs Interest Listmailto:xxxxx Subject: RE:[ntdev] [(virtual) com port; UMDF] ComDb Entry not released
I still have difficulties to understand. I will show you step by step, what I mean:
Lets take the UMDF VirtualSerial example from the WinDDK:
1) To install the driver on the target pc you can use “DIFxCmd /i VirtualSerial.inf 16”. This will install the driver into the file repository
2) To create a Virtual Com Port you can use “devcon install virtualserial.inf UMDF\VirtualSerial”. This will create a new Com Port in the device manager (next free claimed). In the registry the “DEVICEMAP\SERIALCOMM” get a new entry (inserted by the virtualserial.dll device driver), and the ComDb entry under “CurrentControl\Control\COM Name Arbiter” is updated with the according bit set.
3) To remove this Virtual Com Port you can use “devcon remove UMDF\VirtualSerial”. This removes the entry in the device manager. The registry entry under SERIALCOMM is removed. And the bit in the ComDb ist deleted! The driver is still available in the file repository (completely removable by “DIFxCmd /u VirtualSerial.inf 32”.
Now to our own Virtual Com Port (btw. build directly on the WinDDK example):
The most important changes are: + (INF) instead “UMDF\VirtualSerial” as hwid in the Models section we have “USB\VID_XXXX&PID_XXXX” (with our vendor & product id) + (INF) additional entries for WinUsb as lower filter service (no extra WinUsb inf file needed) + (DLL) extra code for needed functionality.
When we go the same steps as in installing/using VirtualSerial the following happens:
1) “DIFxCmd /i our_driver.inf 16” Works as expected. Driver is inserted in file repository.
2) plugin USB device (not “devcon install …”! -> this is done automatically) As above a new COM Port is created in device manager. SERIALCOMM updated (as coded in dll). AND of course the appropriate ComDb Entry bit is set.
3) Unplug USB device (not “devcon remove …”! -> this is also done automatically) As above the COM Port is removed from device manager, the SERIALCOM key is deletete, BUT THE COMDB IS NOT UPDATED!
-> Is that really the expected behaviour?
Last thought: Could it be, that I have bugs in my driver dll and therefore the driver is not really finished while removing the device. And this crash prevents the correct disabling of the ComDb bit?
I’m very sorry to be so annoying, but I do want to understand the logic behind this!
