Develop a Virtual COM port driver for windows XP & above

Hello Everyone,

First things First, I am new to Windows device driver development so please forgive

me if i don’t get some of your answers & ask you to elaborate on the same.
Now I have been assigned a task to develop a Virtual COM port driver that would communicate with a USB printer. Our client has a Printer that can be connected to the PC through serial port or USB port. When ever we connect the printer through the USB port then the name of the printer appears under “Other devices”. Our task is to develop a virtual com port driver that would enable the user to send data & commands to the USB printer through any serial application( for eg: hyper terminal). Client doesn’t ahve any windows USB driver for its printer.

Things I have tried:

I started by installed VS2015 along with WDK 10 on my PC, downloaded the sample WDK projects form GitHUB, compiled VirtualCOM project under source/serial/virtualcom folder, installed it on the target machine through command prompt with the help of devcon.exe.
Once the driver is sucuccefully installed on the system it appears under Ports( COM & LPT). I am able to send data to the virtual com port through a PC application & see the same on hyper terminal.

Now as I mentioned earlier that the printer appears under "“Other devices” & my virtualcom port UMDF driver appears under “Ports(COM & LPT)”. Now My concern is am I going in the right direction. i.e., developing a virtual COM port UMDF driver I found a book “Windows 7 device driver by Ronald D. Reeves” & in its UMDF driver section it says that we can send an I/O request form one device stack to another device stack through IWDFFileHandleTargetFactory interface by creating the I/O target with the help of Win32 CreateFile API. So as my virtual COM port driver appears as a device under “Ports(COM & LPT)” & Client’s printer appears as a device under “Other devices” & each device has its device stack So I thought we will be able to map the I/O controls of my virtual COM port driver to the client’s printer. So under CMyQueue::OnDeviceIoControl function in my UMDF virtual COM port driver code I opend the printer through CreateFile API & then tried to maked it as the I/O target of my virtual COM port driver by passing the File handler obtained from CreateFile to IWDFFileHandleTargetFactory::CreateFileHandleTarget. After these modification when I install the driver it asks for a system restart, after which yellow exclamation (!) appears on the virtual COM port in the Device Manager.

Now here I am stuck & have the following queries.

  1. Is Virtual COM port UMDF driver is the right way of implementing the virtual COM port driver that my client require. If YES then what am I missing & if the answer is NO then what id the write approach.

Thank you in advance for you help & guidance

xxxxx@chetu.com wrote:

Now I have been assigned a task to develop a Virtual COM port driver that would communicate with a USB printer. Our client has a Printer that can be connected to the PC through serial port or USB port. When ever we connect the printer through the USB port then the name of the printer appears under “Other devices”. Our task is to develop a virtual com port driver that would enable the user to send data & commands to the USB printer through any serial application( for eg: hyper terminal).

You didn’t ask us for a design review, but I’m going to give one
anyway. You’re calling this a USB printer. Does it use a printer
driver? Or is it just a dumb device that happens to have a printer at
the other end? Do you know what USB device class it uses? That’s in
the descriptors.

Simulating COM is not the best way to talk through a USB device. It can
be made to work, but it’s awkward, and it doesn’t take advantage of
USB. In my view, a better plan is to provide a DLL for applications to
use that hides the lower details. Your DLL can use the serial APIs if
it’s talking to a real COM port, and the WinUSB APIs if it’s talking to
a USB device.

Client doesn’t ahve any windows USB driver for its printer.

They may not have WRITTEN a USB driver, but it certainly HAS a USB
driver. It would not be listed in Device Manager if it did not. Most
of the stock USB device classes have in-the-box Microsoft drivers
assigned to them. You should open the Properties in Device Manager and
look at the driver details to see what driver was assigned. That will
tell you what kind of interface it is currently expecting.

I started by installed VS2015 along with WDK 10 on my PC, downloaded the sample WDK projects form GitHUB, compiled VirtualCOM project under source/serial/virtualcom folder, installed it on the target machine through command prompt with the help of devcon.exe.
Once the driver is sucuccefully installed on the system it appears under Ports( COM & LPT). I am able to send data to the virtual com port through a PC application & see the same on hyper terminal.

It appears under “Ports” because you have created a fake device and are
driving that device.

Now as I mentioned earlier that the printer appears under "“Other devices” & my virtualcom port UMDF driver appears under “Ports(COM & LPT)”. Now My concern is am I going in the right direction. i.e., developing a virtual COM port UMDF driver I found a book “Windows 7 device driver by Ronald D. Reeves” & in its UMDF driver section it says that we can send an I/O request form one device stack to another device stack through IWDFFileHandleTargetFactory interface by creating the I/O target with the help of Win32 CreateFile API. So as my virtual COM port driver appears as a device under “Ports(COM & LPT)” & Client’s printer appears as a device under “Other devices” & each device has its device stack…

And that’s a mistake. Your virtual COM driver should ***BE*** the
driver for this device. Your client’s printer should not appear under
“Other devices”. It should appear under “Ports (COM & LPT)”, if that’s
going to be the primary interface for the device.

That means that your INF file needs to claim the hardware ID for the
printer, not a fake hardware ID.

So I thought we will be able to map the I/O controls of my virtual COM port driver to the client’s printer.

How do you expect to communicate with the printer? What commands will
you use? Are you sending URBs? How do you know which URBs to send?


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

More questions:

  1. do you ever want to use the windows printing APIs to talk and print to the printer? If yes, a virtual com port is absolutely the wrong path

  2. do you know the underlying USB device protocol? IOW, how to communicate with it? Many printers which do not conform to the usb print class spec are a device behind an Arduino. Is that the case here? Many times in these cases it conforms to the usb CDC spec and just lacks an INF match. If that is the case, you write the INF to match the ID and load usbser.sys on the device and your work is done.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Wednesday, July 6, 2016 9:36 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Develop a Virtual COM port driver for windows XP & above

xxxxx@chetu.com wrote:
> Now I have been assigned a task to develop a Virtual COM port driver that would communicate with a USB printer. Our client has a Printer that can be connected to the PC through serial port or USB port. When ever we connect the printer through the USB port then the name of the printer appears under “Other devices”. Our task is to develop a virtual com port driver that would enable the user to send data & commands to the USB printer through any serial application( for eg: hyper terminal).

You didn’t ask us for a design review, but I’m going to give one anyway. You’re calling this a USB printer. Does it use a printer driver? Or is it just a dumb device that happens to have a printer at the other end? Do you know what USB device class it uses? That’s in the descriptors.

Simulating COM is not the best way to talk through a USB device. It can be made to work, but it’s awkward, and it doesn’t take advantage of USB. In my view, a better plan is to provide a DLL for applications to use that hides the lower details. Your DLL can use the serial APIs if it’s talking to a real COM port, and the WinUSB APIs if it’s talking to a USB device.

> Client doesn’t ahve any windows USB driver for its printer.

They may not have WRITTEN a USB driver, but it certainly HAS a USB driver. It would not be listed in Device Manager if it did not. Most of the stock USB device classes have in-the-box Microsoft drivers assigned to them. You should open the Properties in Device Manager and look at the driver details to see what driver was assigned. That will tell you what kind of interface it is currently expecting.

> I started by installed VS2015 along with WDK 10 on my PC, downloaded the sample WDK projects form GitHUB, compiled VirtualCOM project under source/serial/virtualcom folder, installed it on the target machine through command prompt with the help of devcon.exe.
> Once the driver is sucuccefully installed on the system it appears under Ports( COM & LPT). I am able to send data to the virtual com port through a PC application & see the same on hyper terminal.

It appears under “Ports” because you have created a fake device and are driving that device.

> Now as I mentioned earlier that the printer appears under "“Other devices” & my virtualcom port UMDF driver appears under “Ports(COM & LPT)”. Now My concern is am I going in the right direction. i.e., developing a virtual COM port UMDF driver I found a book “Windows 7 device driver by Ronald D. Reeves” & in its UMDF driver section it says that we can send an I/O request form one device stack to another device stack through IWDFFileHandleTargetFactory interface by creating the I/O target with the help of Win32 CreateFile API. So as my virtual COM port driver appears as a device under “Ports(COM & LPT)” & Client’s printer appears as a device under “Other devices” & each device has its device stack…

And that’s a mistake. Your virtual COM driver should BE the driver for this device. Your client’s printer should not appear under “Other devices”. It should appear under “Ports (COM & LPT)”, if that’s going to be the primary interface for the device.

That means that your INF file needs to claim the hardware ID for the printer, not a fake hardware ID.

> So I thought we will be able to map the I/O controls of my virtual COM port driver to the client’s printer.

How do you expect to communicate with the printer? What commands will you use? Are you sending URBs? How do you know which URBs to send?


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.


NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>

Thank You Tom & Doron for replying.

> You didn’t ask us for a design review, but I’m going to give one
anyway. You’re calling this a USB printer. Does it use a printer
driver? Or is it just a dumb device that happens to have a printer at
the other end? Do you know what USB device class it uses? That’s in
the descriptors.

The printer is a class 7 USB device that takes strings from the serial port. this strings contains the data along with the alignment details that the printer need to consider while printing the data. for eg.

K3>Hello There



Here “Hello There” is the data need to be printed & all other info within <> are alignment information &

instructs the printer to print.

>>Simulating COM is not the best way to talk through a USB device. It can
be made to work, but it's awkward, and it doesn't take advantage of
USB. In my view, a better plan is to provide a DLL for applications to
use that hides the lower details. Your DLL can use the serial APIs if
it's talking to a real COM port, and the WinUSB APIs if it's talking to
a USB device.

Here we will not be using any application. Client wants to use hyper terminal as the application. So client will send the above string through the hyper terminal

>>They may not have WRITTEN a USB driver, but it certainly HAS a USB
driver. It would not be listed in Device Manager if it did not. Most
of the stock USB device classes have in-the-box Microsoft drivers
assigned to them. You should open the Properties in Device Manager and
look at the driver details to see what driver was assigned. That will
tell you what kind of interface it is currently expecting.

When I go to the properties window & click on the Driver details tab under Drivers a pop up appears that says "No files are required or have been loader for this device"

>>And that's a mistake. Your virtual COM driver should ***BE*** the
driver for this device. Your client's printer should not appear under
"Other devices". It should appear under "Ports (COM & LPT)", if that's
going to be the primary interface for the device.

Ok so does that mean under "Ports (COM & LPT)" there will be two entries on of the virtual COM port driver & the other will be of the printer or both the virtualCOM port & printer will have a single entry under "Ports (COM & LPT)"

>>1) do you ever want to use the windows printing APIs to talk and print to the
printer? If yes, a virtual com port is absolutely the wrong path

No we will not use windows API to talk to the printer

How do you expect to communicate with the printer? What commands will
you use? Are you sending URBs? How do you know which URBs to send?

To be very frank have no idea on how to communicate with the printer. Please guide me in the same

xxxxx@chetu.com wrote:

The printer is a class 7 USB device that takes strings from the serial port.

When I go to the properties window & click on the Driver details tab under Drivers a pop up appears that says “No files are required or have been loader for this device”

The Windows default for a device in class 7 (“USB printer class”) is to
have a null driver, which is what you see. Such a device is listed in
Device Manager, but cannot be used, because there is no driver to accept
requests. You will have to do what I suggested, and have you driver
become the primary driver for the device. Your INF file will have to
specify the device’s VID and PID.

Here we will not be using any application.

HyperTerminal is an application. Further, it’s an application that does
not exist in systems newer than Vista. Microsoft stopped including it.

Client wants to use hyper terminal as the application. So client will send the above string through the hyper terminal

That’s foolishness. It would take you one day to write a console
application that accepted input strings and wrote it out to the USB
endpoints using WinUSB. That would be easier than a virtual COM port
driver. Because they have such a long history, the Windows COM port
driver interfaces are burdened with legacy considerations that are not
always entirely rational.

Ok so does that mean under “Ports (COM & LPT)” there will be two entries on of the virtual COM port driver & the other will be of the printer or both the virtualCOM port & printer will have a single entry under “Ports (COM & LPT)”

There will be a single entry under Ports. Once you supply a driver, the
other non-driver entry goes away.

> How do you expect to communicate with the printer? What commands will
> you use? Are you sending URBs? How do you know which URBs to send?

To be very frank have no idea on how to communicate with the printer. Please guide me in the same

You have to know this. Have you read the USB Device Class Specification
for Printers? It’s only 11 pages long. All it says is that printing
data goes out to a bulk OUT pipe, and status can come back on an
optional bulk IN pipe. You have to know which endpoint numbers to use;
that will either be in the specs for the device or in the descriptors.
The device specs will tell you how the packets have to be formatted.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Amit Kumar wrote:

To be very frank have no idea on how to communicate with
the printer. Please guide me in the same

How could we possibly know how to communicate with *your* printer? Especially one where, apparently, you print by typing in commands by hand via HyperTerminal…

>>That’s foolishness. It would take you one day to write a console
application that accepted input strings and wrote it out to the USB
endpoints using WinUSB. That would be easier than a virtual COM port
driver. Because they have such a long history, the Windows COM port
driver interfaces are burdened with legacy considerations that are not
always entirely rational.

We are following this Virtual COM port path because of our client’s which as follows:

our client has 5 types of printers & he wants us to develop a driver which when installed on a PC would install multiple virtual COM port on the PC. These virtual com port driver show show up in Device Manager instantly after the driver installation. Each of the five printers will have multiple virtual COM ports associated with it & the number of virtual port that need to be installed for each printer will be decided by the user during the installation of the driver(installer will contain an window through which the user can enter the number of virtual com port he requires against each Printer). the user can use any one of the virtual com port associated with a particular printer to send commands to that printer. For eg: if during installation process if the user wants to have 2 virtual COM ports for each of the five printer & after installation COM45, COM46… COM53, COM54 gets created. During the driver installation of after the driver installation we need to to map two COM ports to each of the printers.

Printer1 mapped to COM45 & COM46
Printer2 mapped to COM47 & COM48
Printer3 mapped to COM49 & COM50
Printer4 mapped to COM51 & COM52
Printer5 mapped to COM53 & COM54

So that whenever user plug in Printer1 he/she will be able to send data to it only through COM45 or COM46 via hyper terminal & same will be valid for all other printers.

So this is the big picture. Now to give myself a head start I am trying my luck with UMDF virtual COM port driver & trying it to map it with one of the printer.

Please let me know if I am taking the wrong direction.

xxxxx@chetu.com wrote:

We are following this Virtual COM port path because of our client’s which as follows:

I understand that. Your clients design is flawed. It is the product of
antiquated thinking and will result in heartache and tears.

our client has 5 types of printers & he wants us to develop a driver which when installed on a PC would install multiple virtual COM port on the PC. These virtual com port driver show show up in Device Manager instantly after the driver installation. Each of the five printers will have multiple virtual COM ports associated with it…

Why multiple COM ports? Is he expecting to send to a single printer
from multiple applications at once? How does he expect that to work?
What happens if they both send at the same time?

… & the number of virtual port that need to be installed for each printer will be decided by the user during the installation of the driver(installer will contain an window through which the user can enter the number of virtual com port he requires against each Printer). the user can use any one of the virtual com port associated with a particular printer to send commands to that printer. For eg: if during installation process if the user wants to have 2 virtual COM ports for each of the five printer & after installation COM45, COM46… COM53, COM54 gets created. During the driver installation of after the driver installation we need to to map two COM ports to each of the printers.

Printer1 mapped to COM45 & COM46
Printer2 mapped to COM47 & COM48
Printer3 mapped to COM49 & COM50
Printer4 mapped to COM51 & COM52
Printer5 mapped to COM53 & COM54

Remember that this assignment won’t happen when the DRIVER is
installed. It will happen when the DEVICES are detected for the first
time. If there are 5 printers, the user is going to be asked the
“number of ports?” question 5 times. You may be able to cache that
answer somewhere, but this is something that you’ll have to think
carefully about, taking the installation scenarios into account.

So this is the big picture. Now to give myself a head start I am trying my luck with UMDF virtual COM port driver & trying it to map it with one of the printer.

Please let me know if I am taking the wrong direction.

I think your CLIENT is taking the wrong direction. Given your flawed
goals, your approach is the correct one. How’s that for a backhanded
compliment? :wink:

You will have to modify the sample in a couple of ways. You will
eventually have to change it to expose multiple COM ports instead of
just one, but that can wait. You will have to modify the INF file to
match the printer VIDs and PIDs instead of creating a fake device. You
will have to modify the bottom end to send the data as appropriately
formatted packets in WinUSB calls. You may want to look at one of the
UMDF USB samples for hints at how to do that.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Thank you everyone for your valuable suggestion.

I have already tried to modify the inf file using the PID and VID of printer but when I had installed this inf file, I got a message your driver not installed properly and it prompt an error message in device manager " The drivers for this device are not installed. (Code 31)".

I am new bee in windows driver development, So if you don’t mind then please give a right direction how i can implement vid and pid in virtual com port inf file.

thank you so much.

First step is to look in %windir%\inf\setupapi.dev.log and see why the code 31 showed up

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@chetu.com
Sent: Thursday, July 7, 2016 11:02 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Develop a Virtual COM port driver for windows XP & above

Thank you everyone for your valuable suggestion.

I have already tried to modify the inf file using the PID and VID of printer but when I had installed this inf file, I got a message your driver not installed properly and it prompt an error message in device manager " The drivers for this device are not installed. (Code 31)".

I am new bee in windows driver development, So if you don’t mind then please give a right direction how i can implement vid and pid in virtual com port inf file.

thank you so much.


NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>

Hello Tim & Doron,

Thank you for you feed back & ur backhanded compliment :-p

This time indtead of installing the virtual COM port driver i updated it with the following command

devcon.exe update VirtualSerial.inf “USB\VIDxxx&PIDxxxx”

after executing the command the printer that was appearing under “other devices” disappeared & was mapped to the virtual COM port under “Ports” I confirmed this by right clicking on the “Properties-> Details->Hardware Ids” It showed the VID & PID of of the printer. The COM port gets removed when we detach the printer.

But the Yellow Exclamation mark still remains on the installed driver. So as advised by Doron I then checked the setupapi.dev.log file. In that I found the following error lines.

! sig: VerifyTrustFailed for C:\Windows\system32\DRIVERS\UMDF\Virtualserial.dll.
! sig: Error 0x800b0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.

sig: Error 0xe0000241: The INF was signed with an Authenticode™ catalog from a trusted publisher.

I then tried to resolved these issue by the following steps,

  1. I double clicked the virtualserial.cer file that gets generated under the debug folder once I compile the driver code.
  2. then on the pop-up window that appears I click the Install Certificate tab
  3. The certificate Import wizard appears then I click next->next->finish
  4. then another popup appears that says “The Import was successful”

but this process do not resolve my problem.

What am I missing.? could you please guide me out through the problem.

You need to educate yourself on test signed drivers (search msdn)

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@chetu.com
Sent: Friday, July 8, 2016 10:57 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Develop a Virtual COM port driver for windows XP & above

Hello Tim & Doron,

Thank you for you feed back & ur backhanded compliment :-p

This time indtead of installing the virtual COM port driver i updated it with the following command

devcon.exe update VirtualSerial.inf “USB\VIDxxx&PIDxxxx”

after executing the command the printer that was appearing under “other devices” disappeared & was mapped to the virtual COM port under “Ports” I confirmed this by right clicking on the “Properties-> Details->Hardware Ids” It showed the VID & PID of of the printer. The COM port gets removed when we detach the printer.

But the Yellow Exclamation mark still remains on the installed driver. So as advised by Doron I then checked the setupapi.dev.log file. In that I found the following error lines.

! sig: VerifyTrustFailed for C:\Windows\system32\DRIVERS\UMDF\Virtualserial.dll.
! sig: Error 0x800b0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.

sig: Error 0xe0000241: The INF was signed with an Authenticode™ catalog from a trusted publisher.

I then tried to resolved these issue by the following steps,
1) I double clicked the virtualserial.cer file that gets generated under the debug folder once I compile the driver code.
2) then on the pop-up window that appears I click the Install Certificate tab
3) The certificate Import wizard appears then I click next->next->finish
4) then another popup appears that says “The Import was successful”

but this process do not resolve my problem.

What am I missing.? could you please guide me out through the problem.


NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>

>the five printer & after installation COM45, COM46… COM53, COM54 gets created.

Oh my God.

Not only you use serial ports, which are outdated for printers for like 10 years.

You also insist on having the obsolete MS-DOS numbering for them, which is not important at all, if the device follows the “serenum” protocol.

It is a VERY good idea to switch to USB and use the standard USB printer support.

And yes, HyperTerminal is outdated too.


Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

Hello There.

Thank You Doron after going through test signed driver my driver is installing properly., when i go to its properties it says that This device is working properly.

>Why multiple COM ports? Is he expecting to send to a single printer
from multiple applications at once? How does he expect that to work?
What happens if they both send at the same time?

No our client doesn’t have the intention to send data to a single printer from multiple application at once.

Now I am trying to send some data from a serial application to the USB printer via my virtual com port driver. So in order to achieve that I have made the following changes to my driver.

In the .inf file of my virtual comport driver i have added the following lines from umdf_fx .inf files

Initially It was

[Microsoft.NTamd64]
%VirtualSerialDeviceName%=VirtualSerial_Install,UMDF\VirtualSerial

i changed it to

[Microsoft.NTamd64]
%VirtualSerialDeviceName%=VirtualSerial_Install, USB\VID_XXX&PID_XXX

; =================== UMDF VirtualSerial Device ==================================

initially it was

[VirtualSerial_Install.NT.Wdf]
UmdfService=VirtualSerial,VirtualSerial_Install
UmdfServiceOrder=VirtualSerial
UmdfKernelModeClientPolicy = AllowKernelModeClients
UmdfFileObjectPolicy = AllowNullAndUnknownFileObjects
UmdfFsContextUsePolicy = CanUseFsContext

now i changed it to

[VirtualSerial_Install.NT.Wdf]
KmdfService=WINUSB, WinUsb_Install
UmdfDispatcher=WinUsb
UmdfService=VirtualSerial,VirtualSerial_Install
UmdfServiceOrder=VirtualSerial
UmdfKernelModeClientPolicy = AllowKernelModeClients
UmdfImpersonationLevel=Impersonation

; Needed for Win7 support
[WinUsb_Install]
KmdfLibraryVersion = 1.9

As per my understanding when ever an application tries to write to the printer by calling the Win32 API write( ) function then CMyQueue::OnWrite( ) function of my virtual com port driver will be called so I made the following modification to CMyQueue::OnWrite( ) function as

VOID
STDMETHODCALLTYPE
CMyQueue::OnWrite(
In IWDFIoQueue *pWdfQueue,
In IWDFIoRequest *pWdfRequest,
In SIZE_T BytesToWrite
)

{
//IWDFMemory* pRequestMemory = NULL;
//IWDFIoRequest* pSavedRequest = NULL;
//SIZE_T availableData = 0;
// SIZE_T savedRequestBufferSize = 0;
HRESULT hr = S_OK;
IWDFMemory * pInputMemory = NULL;
UNREFERENCED_PARAMETER(pWdfQueue);
BytesToWrite = 5;
//
// Get memory object
//

UNREFERENCED_PARAMETER(pWdfQueue);

// Implemented code for write

IWDFUsbTargetPipe * pOutputPipe = m_Device->GetOutputPipe();

// pWdfRequest->GetInputMemory(&pRequestMemory);

pWdfRequest->GetInputMemory(&pInputMemory);

hr = pOutputPipe->FormatRequestForWrite(
pWdfRequest,
NULL, //pFile
pInputMemory,
NULL, //Memory offset
NULL //DeviceOffset
);

if (FAILED(hr))
{
pWdfRequest->Complete(hr);
}
else
{
ForwardFormattedRequest(pWdfRequest, pOutputPipe);
}

SAFE_RELEASE(pInputMemory);

return;
}

I made the above modification by taking some clue from the umdf_fx usb driver sample code. But it seems like I am missing some thing that is why I am not able to send any data to the virtual com port. I am able to open the virtual COM port but I am not able to send any data to the printer attached to the virtual COM port.

Please guide me through the right path, so that I will be able to send some data to my printer.

Attach a debugger to the driver, set up break points on callbacks for create, write, ioctl and see what happens.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@chetu.com
Sent: Monday, July 11, 2016 12:28 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Develop a Virtual COM port driver for windows XP & above

Hello There.

Thank You Doron after going through test signed driver my driver is installing properly., when i go to its properties it says that This device is working properly.

>>Why multiple COM ports? Is he expecting to send to a single printer
from multiple applications at once? How does he expect that to work?
What happens if they both send at the same time?

No our client doesn’t have the intention to send data to a single printer from multiple application at once.

Now I am trying to send some data from a serial application to the USB printer via my virtual com port driver. So in order to achieve that I have made the following changes to my driver.

In the .inf file of my virtual comport driver i have added the following lines from umdf_fx .inf files

Initially It was

[Microsoft.NTamd64]
%VirtualSerialDeviceName%=VirtualSerial_Install,UMDF\VirtualSerial

i changed it to

[Microsoft.NTamd64]
%VirtualSerialDeviceName%=VirtualSerial_Install, USB\VID_XXX&PID_XXX

; =================== UMDF VirtualSerial Device ==================================

initially it was

[VirtualSerial_Install.NT.Wdf]
UmdfService=VirtualSerial,VirtualSerial_Install
UmdfServiceOrder=VirtualSerial
UmdfKernelModeClientPolicy = AllowKernelModeClients UmdfFileObjectPolicy = AllowNullAndUnknownFileObjects UmdfFsContextUsePolicy = CanUseFsContext

now i changed it to

[VirtualSerial_Install.NT.Wdf]
KmdfService=WINUSB, WinUsb_Install
UmdfDispatcher=WinUsb
UmdfService=VirtualSerial,VirtualSerial_Install
UmdfServiceOrder=VirtualSerial
UmdfKernelModeClientPolicy = AllowKernelModeClients UmdfImpersonationLevel=Impersonation

; Needed for Win7 support
[WinUsb_Install]
KmdfLibraryVersion = 1.9

As per my understanding when ever an application tries to write to the printer by calling the Win32 API write( ) function then CMyQueue::OnWrite( ) function of my virtual com port driver will be called so I made the following modification to CMyQueue::OnWrite( ) function as

VOID
STDMETHODCALLTYPE
CMyQueue::OnWrite(
In IWDFIoQueue pWdfQueue,
In IWDFIoRequest pWdfRequest,
In SIZE_T BytesToWrite
)

{
//IWDFMemory
pRequestMemory = NULL;
//IWDFIoRequest
pSavedRequest = NULL;
//SIZE_T availableData = 0;
// SIZE_T savedRequestBufferSize = 0;
HRESULT hr = S_OK;
IWDFMemory * pInputMemory = NULL;
UNREFERENCED_PARAMETER(pWdfQueue);
BytesToWrite = 5;
//
// Get memory object
//

UNREFERENCED_PARAMETER(pWdfQueue);

// Implemented code for write

IWDFUsbTargetPipe * pOutputPipe = m_Device->GetOutputPipe();

// pWdfRequest->GetInputMemory(&pRequestMemory);

pWdfRequest->GetInputMemory(&pInputMemory);

hr = pOutputPipe->FormatRequestForWrite(
pWdfRequest,
NULL, //pFile
pInputMemory,
NULL, //Memory offset
NULL //DeviceOffset
);

if (FAILED(hr))
{
pWdfRequest->Complete(hr);
}
else
{
ForwardFormattedRequest(pWdfRequest, pOutputPipe);
}

SAFE_RELEASE(pInputMemory);

return;
}

I made the above modification by taking some clue from the umdf_fx usb driver sample code. But it seems like I am missing some thing that is why I am not able to send any data to the virtual com port. I am able to open the virtual COM port but I am not able to send any data to the printer attached to the virtual COM port.

Please guide me through the right path, so that I will be able to send some data to my printer.


NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>

xxxxx@chetu.com wrote:

>> Why multiple COM ports?
No our client doesn’t have the intention to send data to a single printer from multiple application at once.

Then why multiple COM ports? There’s no point.

I made the above modification by taking some clue from the umdf_fx usb driver sample code. But it seems like I am missing some thing that is why I am not able to send any data to the virtual com port. I am able to open the virtual COM port but I am not able to send any data to the printer attached to the virtual COM port.

What does that mean? Does that mean your CMyQueue::OnWrite handler
doesn’t get called, or does it mean your handler runs but nothing gets
to the printer?


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

I tried to attach a debugger to the driver so that I can debug the code & find the issue, but I am unable to debug the driver code. I searched the internet to find a step by step guide for debugging the UMDF driver & found this link that contains a series of videos which illustrates the debugging process.

https://msdn.microsoft.com/en-us/windows/hardware/drivers/wdf/videos--debugging-umdf-drivers

The process that i followed are as follows as shown in above videos:

  1. I successfully compiled the Virtual COM port driver, traversed to the Debug folder of Virtual COM port driver then copied the content of the Debug folder to a new folder in my C:\ drive.
  2. I copied the devcon.exe , wdfverifier.exe , windbg.exe & wudfext.dll to the new folder
  3. Installed the application verifier.
  4. Then I connect my printer device to my system & install the driver with the following command

devcon.exe update VirtualSerial.inf “USB\VIDxxx&PIDxxxx”

my device gets properly installed & appears under Ports Then without removing the device when I double click on wdfverifier.exe an pop up appears that says

"An unexpected and fatal error has occurred- details:

drivers\wdf\kmdf\tests\tools\wdfverifier\devicelist.cpp(296)
void_thiscall AllWdfDevices::AddUmdfDriversTo(struct
_SP_DEVINFO_DATA &,class WdfQa::Common::ObjectArray &)
Error 2<2> encountered
System Mesage: The system cannot find the file specified."

and then the nothing happens. So as the wdfverifier.exe is running so I am not able to debug the driver code.

Please guide me through the process of debugging the UMDF driver code. Is there any link or book that illustrates the step by step process of debugging the UMDF driver.?

xxxxx@chetu.com wrote:

The process that i followed are as follows as shown in above videos:

  1. I successfully compiled the Virtual COM port driver, traversed to the Debug folder of Virtual COM port driver then copied the content of the Debug folder to a new folder in my C:\ drive.
  2. I copied the devcon.exe , wdfverifier.exe , windbg.exe & wudfext.dll to the new folder

And WUDFUPDATE_01009.dll and winusbcoinstaller2.dll?

  1. Installed the application verifier.
  2. Then I connect my printer device to my system & install the driver with the following command

devcon.exe update VirtualSerial.inf “USB\VIDxxx&PIDxxxx”

Please show us the entire VirtualSerial.inf.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

>>And WUDFUPDATE_01009.dll and winusbcoinstaller2.dll?

I had WUDFUPDATE_01009.dll but winusbcoinstaller2.dll was missing so i downloaded it from from internet & copied it to the folder. Is this the right way?

> Please show us the entire VirtualSerial.inf.

I have made the following changes to VirtualSerial.inf on hit & trial basic as I didn’t get any substantial info regarding the same for msdn. please bear with me if the changes look completely nonsense & guide me through the right path.

;
; VirtualSerial.inf
;

[Version]
Signature=“$Windows NT$”
Class=Ports
ClassGuid={4D36E978-E325-11CE-BFC1-08002BE10318}
Provider=%MSFTUMDF%
CatalogFile=WUDF.cat
DriverVer=07/11/2016,23.17.8.950

[Manufacturer]
%MSFTUMDF%=Microsoft,NTamd64

[Microsoft.NTamd64]
%VirtualSerialDeviceName%=VirtualSerial_Install, USB\VID_1201&PID_4954

[SourceDisksFiles]
Virtualserial.dll=1
WudfUpdate_01009.dll=1

[SourceDisksNames]
1 = %MediaDescription%

; =================== UMDF VirtualSerial Device ==================================

[VirtualSerial_Install.NT]
CopyFiles=UMDriverCopy
Include=WINUSB.INF ; Import sections from WINUSB.INF
Needs=WINUSB.NT ; Run the CopyFiles & AddReg directives for WinUsb.INF

[VirtualSerial_Install.NT.hw]
AddReg=VirtualSerial_Install_AddReg

[VirtualSerial_Install.NT.Services]
AddService=WUDFRd,0x000001fa,WUDFRD_ServiceInstall
AddService=WinUsb,0x000001f8,WinUsb_ServiceInstall ; this service is installed because its a filter.

[VirtualSerial_Install.NT.CoInstallers]
CopyFiles=CoInstallers_CopyFiles
AddReg=CoInstallers_AddReg

[VirtualSerial_Install.NT.Wdf]
;add
KmdfService=WINUSB, WinUsb_Install
;add
UmdfDispatcher=WinUsb
UmdfService=VirtualSerial,VirtualSerial_Install
UmdfServiceOrder=VirtualSerial
UmdfKernelModeClientPolicy = AllowKernelModeClients
;UmdfFileObjectPolicy = AllowNullAndUnknownFileObjects
;UmdfFsContextUsePolicy = CannotUseFsContexts
; Enable impersonation for the PLAY_FILE IOCTL
UmdfImpersonationLevel=Impersonation

; Needed for Win7 support
[WinUsb_Install]
KmdfLibraryVersion = 1.9

[VirtualSerial_Install]
UmdfLibraryVersion=1.9.0
ServiceBinary=%12%\UMDF\Virtualserial.dll
DriverCLSID={C8ECC087-6B79-4de5-8FB4-C03358A29617}

[VirtualSerial_Install_AddReg]
HKR,“LowerFilters”,0x00010008,“WinUsb” ; FLG_ADDREG_TYPE_MULTI_SZ | FLG_ADDREG_APPEND
HKR,“WinUsbPowerPolicyOwnershipDisabled”,0x00010001,1 ; our driver takes ownership of power policy.
; When the UMDF Idle/Wake APIs are called with WdfDefault setting
; These keys tell UMDF to enable idle and wake by default
HKR,WudfPowerPolicySettings,“WdfDefaultIdleInWorkingState”,0x00010001,1
HKR,WudfPowerPolicySettings,“WdfDefaultWakeFromSleepState”,0x00010001,1

[WUDFRD_ServiceInstall]
DisplayName = %WudfRdDisplayName%
ServiceType = 1
StartType = 3
ErrorControl = 1
ServiceBinary = %12%\WUDFRd.sys

[WinUsb_ServiceInstall]
DisplayName = %WinUsb_SvcDesc%
ServiceType = 1
StartType = 3
ErrorControl = 1
ServiceBinary = %12%\WinUSB.sys

[CoInstallers_CopyFiles]
WudfUpdate_01009.dll

[CoInstallers_AddReg]
HKR,CoInstallers32,0x00010000,“WUDFUpdate_01009.dll”

[DestinationDirs]
UMDriverCopy=12,UMDF ; copy to drivers\UMDF
CoInstallers_CopyFiles=11

[UMDriverCopy]
Virtualserial.dll

; =================== Generic ==================================

[Strings]
MSFTUMDF=“Chetu1”
MediaDescription=“Microsoft Sample Driver Installation Media”
WudfRdDisplayName=“Windows Driver Foundation - User-mode Driver Framework Reflector”
VirtualSerialDeviceName=“Practical Automation Driver”
WinUsb_SvcDesc=“WinUSB Driver”

xxxxx@chetu.com wrote:

>> And WUDFUPDATE_01009.dll and winusbcoinstaller2.dll?
I had WUDFUPDATE_01009.dll but winusbcoinstaller2.dll was missing so i downloaded it from from internet & copied it to the folder. Is this the right way?

You shouldn’t need to download it. It is part of the WDK, just like
WUDFUpdate. In fact, it’s in the same directory as WUDFUpdate.

I have made the following changes to VirtualSerial.inf on hit & trial basic as I didn’t get any substantial info regarding the same for msdn. please bear with me if the changes look completely nonsense & guide me through the right path.

This seems more or less correct. Have you checked that your driver DLL
is present in System32\Drivers\UMDF? Can you export the registry at
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\USB\VID_1201&PID_4954
so we can see that it all got installed correctly? Have you done enough
debug prints to see that your driver is actually getting loaded?


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.