Accessing a UMDF Driver as a COM Port

I have a working UMDF driver that I would like to access as a COM port
via CreateFile(). I’m under the (naive) impression that all I have to do is
create a device interface
(IWDFDevice->CreateDeviceInterface(&GUID_DEVINTERFACE_COMPORT, NULL)),
assign a symbolic name (IWDFDevice->CreateSymbolicLink(L
“\DosDevices\COM30”)) and enable the device (
IWDFDEvice->AssignDeviceInterfaceState(&GUID_DEVINTERFACE_COMPORT, NULL,
TRUE).

Could someone please provide a brief synopsis of the steps. I guess I’ll go
back to the DDK examples, but sometimes its difficult to separtate registry
settings the driver needs (e.g. serial.sys) vs. those needed by the OS.

Thanks,
Greg

WORKING ASSUMPTIONS:
---------------------------------------
-UMDF drivers run in the Local Service security context and won’t be able to
creatre SERIALCOMM keys, however these settings are for legacy applications
and shouldn’t stop me from opening a COM port via CreateFile(). Will have
to solve the problem sooner or later with a user app, KMDF filter driver,
driver property page or something.
-XP will make the necessary registry settings to persist the device when I
create it above.
-May have an issue with the DosDevices namespaces. Tried both
\DosDevices\COM30 and \DosDevices\Global\COM30.

Where are you intending to go with this? You won’t be able to talk to your device in almost any terminal program unless you implement a lengthy list of serial IOCTLs.

> via CreateFile(). I’m under the (naive) impression that all I have to do is

create a device interface
(IWDFDevice->CreateDeviceInterface(&GUID_DEVINTERFACE_COMPORT,
NULL)),
assign a symbolic name (IWDFDevice->CreateSymbolicLink(L
“\DosDevices\COM30”)) and enable the device (

You must also support all serial IOCTLs.


Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

> You must also support all serial IOCTLs.

I’m a little confused. I currently have the IQueueCallbackDeviceIoControl
interface/skeleton in place, and do plan on supporting/porting the necessary
IOCTRLs over from a previous WDM implementation I have, but I didn’t know I
needed them in place to perform a simple CreateFile(“COM30”…)?

At this point I just want to see the port open up like it does when I use
the actual device name.

Please advise.

Greg

“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
>> via CreateFile(). I’m under the (naive) impression that all I have to do
>> is
>> create a device interface
>> (IWDFDevice->CreateDeviceInterface(&GUID_DEVINTERFACE_COMPORT,
>>NULL)),
>> assign a symbolic name (IWDFDevice->CreateSymbolicLink(L
>> “\DosDevices\COM30”)) and enable the device (
>
> You must also support all serial IOCTLs.
>
> –
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>

You also need to add your COM port under
HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM. The problem is that
the UMDF process does not have sufficient rights to write the value out.
If you have some other NT service already running with sufficient rights
to write the value, that is a usable workaround. Otherwise, to
experiment with this you can change the ACLs of the key for testing
purposes. WE are hoping to address this issue in a future release of
UMDF

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Greg Thomson
Sent: Tuesday, January 30, 2007 8:18 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Accessing a UMDF Driver as a COM Port

You must also support all serial IOCTLs.

I’m a little confused. I currently have the
IQueueCallbackDeviceIoControl
interface/skeleton in place, and do plan on supporting/porting the
necessary
IOCTRLs over from a previous WDM implementation I have, but I didn’t
know I
needed them in place to perform a simple CreateFile(“COM30”…)?

At this point I just want to see the port open up like it does when I
use
the actual device name.

Please advise.

Greg

“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
>> via CreateFile(). I’m under the (naive) impression that all I have to
do
>> is
>> create a device interface
>> (IWDFDevice->CreateDeviceInterface(&GUID_DEVINTERFACE_COMPORT,
>>NULL)),
>> assign a symbolic name (IWDFDevice->CreateSymbolicLink(L
>> “\DosDevices\COM30”)) and enable the device (
>
> You must also support all serial IOCTLs.
>
> –
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

> IOCTRLs over from a previous WDM implementation I have, but I didn’t know I

needed them in place to perform a simple CreateFile(“COM30”…)?

You can do CreateFile, but if you want existing serial/terminal apps to work -
support IOCTLs. If you want TAPI only (dialup networking) - then it is enough
to support a subset of IOCTLs (never documented IIRC).

CreateFile(“COM30”) will open the file named “COM30” in your current dir, use
\.\COM30 instead.


Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

I manually created the corresponding SERIALCOMM registry entry for COM30
using a device specification of “\Device\000000b8”, but had no luck.

I’m a litte unsure of what target device to specifiy. When I call
IWDFDevice->RetrieveDeviceName() it replies with
“\.\UMDFCtrlDev-49eeb038-b066-11db-b357-0012f09930ea”. When I register a
symbolic link for this device, its registered with a device name of
“\Device\000000b8”. And when I successfully open the device via
CreateFile(), I have to specifiy
“”\?\root#multiportserial#0000#{86e0d1e0-8089-11d0-9ce4-08003e301f73}", the
path enumerated via SetupDiGetDeviceInterfaceDetail().

Any explanations for all these devices?

Greg,

Define no luck. You could not create the value or you could not open
\.\COM30 from your UM application? What is the symbolic link name
string you are passing to create the symbolic link? Perhaps you need to
specify Global?? as the prefix so that it is created in all sessions.

\.\UMDFCtrlDev-49eeb038-b066-11db-b357-0012f09930ea is a side band
device, I wouldn’t use that

\Device\000000b8 is the name of your PDO

\?\root#multiportserial#0000#{86e0d1e0-8089-11d0-9ce4-08003e301f73} is
a symbolic link name, not a device. This symbolic link name actually
points back to your PDO’s name

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Greg Thomson
Sent: Tuesday, January 30, 2007 10:24 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Accessing a UMDF Driver as a COM Port

I manually created the corresponding SERIALCOMM registry entry for COM30

using a device specification of “\Device\000000b8”, but had no luck.

I’m a litte unsure of what target device to specifiy. When I call
IWDFDevice->RetrieveDeviceName() it replies with
“\.\UMDFCtrlDev-49eeb038-b066-11db-b357-0012f09930ea”. When I register
a
symbolic link for this device, its registered with a device name of
“\Device\000000b8”. And when I successfully open the device via
CreateFile(), I have to specifiy
“”\?\root#multiportserial#0000#{86e0d1e0-8089-11d0-9ce4-08003e301f73}",
the
path enumerated via SetupDiGetDeviceInterfaceDetail().

Any explanations for all these devices?

Greg,


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

So that was it, specify “\.\COM30” in CreateFile() and not “COM30”. I was
blown off course when I substitued “COM1” and my other port opened fine.

As a quick note to the next reader in with a simlier problem, make sure your
symbolic link is “\DosDevices\Global\COM30” and not in the local DosDevices
namespace of “\DosDevices\COM30”.

Thanks for all the help! Definitely boosts the thinking process.

Greg

Maxim S. Shatskih wrote:

You can do CreateFile, but if you want existing serial/terminal apps to work -
support IOCTLs. If you want TAPI only (dialup networking) - then it is enough
to support a subset of IOCTLs (never documented IIRC).

CreateFile(“COM30”) will open the file named “COM30” in your current dir, use
\.\COM30 instead.

Yes, and for completeness, let us add that this has to be spelled
“\\.\COM30” in C and C++.


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

Maxim wrote:

> IOCTRLs over from a previous WDM implementation I have,
> but I didn’t know I needed them in place to perform a
> simple CreateFile(“COM30”…)?

You can do CreateFile, but if you want existing serial/terminal
apps to work - support IOCTLs.

Well, careful – this is true for serial ports only. If you are a Modem (and thus a LowerFilter to modem.sys), I believe just the act of CreateFile() will result in DTR IOCTL as well.

> > You can do CreateFile, but if you want existing serial/terminal

> apps to work - support IOCTLs.

Well, careful – this is true for serial ports only. If you are a Modem (and
thus a
LowerFilter to modem.sys), I believe just the act of CreateFile() will result
in DTR
IOCTL as well.

So what? is DTR the only thing to support?

Modems run under TAPI, so, the modem driver must support the subset of serial
IOCTLs used by TAPI.


Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

No, of course it isn’t. My point was that not even CreateFile() will work if you are set up as a modem. (You can open a modem’s COM port through CreateFile(), don’t know why you are mentioning TAPI.)