DeviceInterfaces, legacy names and .NET

NTDEV
1

I recently ran into trouble using a DeviceInterface with .NET 2.0. I
have a WDM driver that implements a Device Interface and does not create
a legacy name. This particular device is a Serial Port device but I
have found that this problem appears to exist with all the .NET stream
classes. When I call the SetupDiXXX functions to get a device interface
I get back something like
\?\vs03port#com#6&1b7299&3&0000#{86e0d1e0-8089-11d0-9ce4-08003e301f73}.
With Win32 I then call CreateFile and pass it this string. However I
have found that if I use FileStream or SerialStream with the string
returned by SetupDIXXX then I get an error that an illegal character is
in the path. It turns out that the ‘?’ is the illegal character and
because if I change the string to
\.\vs03port#com#6&1b7299&3&0000#{86e0d1e0-8089-11d0-9ce4-08003e301f73}
I get FileStream will not open Win32 devices such as disk partitions and
tape drives. Avoid use of "\." in the path.

According to Microsoft support they don’t allow \ for security reasons
because they don’t want users to use the SerialPort class to open
devices \PHYSICALDRIVE0 or \C: which I can understand but isn’t this
the wrong way to be preventing that? Shouldn’t they use the SetupDiXXX
functions to validate that the path passed in belongs to the class of
devices that the stream supports, in my case the Serial Port class.

Am I missing something here or did the .NET group implement their
security incorrectly?

  • Steve -
2

It does seem that they have erred on the side of paranoia. You’ll have to
use [DllImport] and roll your own CreateFile import. Declare the return
value (handle) as System.IntPtr. FileStream has a constructor that takes a
HANDLE value encoded as an IntPtr, and a boolean indicating whether the
handle was opened in overlapped mode.

– arlie

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Whitman, Steve
Sent: Tuesday, November 08, 2005 9:42 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] DeviceInterfaces, legacy names and .NET

I recently ran into trouble using a DeviceInterface with .NET 2.0. I have a
WDM driver that implements a Device Interface and does not create a legacy
name. This particular device is a Serial Port device but I have found that
this problem appears to exist with all the .NET stream classes. When I call
the SetupDiXXX functions to get a device interface I get back something like
\?\vs03port#com#6&1b7299&3&0000#{86e0d1e0-8089-11d0-9ce4-08003e301f73}.
With Win32 I then call CreateFile and pass it this string. However I have
found that if I use FileStream or SerialStream with the string returned by
SetupDIXXX then I get an error that an illegal character is in the path. It
turns out that the ‘?’ is the illegal character and because if I change the
string to
\.\vs03port#com#6&1b7299&3&0000#{86e0d1e0-8089-11d0-9ce4-08003e301f73} I
get FileStream will not open Win32 devices such as disk partitions and tape
drives. Avoid use of "\." in the path.

According to Microsoft support they don’t allow \ for security reasons
because they don’t want users to use the SerialPort class to open devices
<file:> \PHYSICALDRIVE0 or <file:> \C: which I can
understand but isn’t this the wrong way to be preventing that? Shouldn’t
they use the SetupDiXXX functions to validate that the path passed in
belongs to the class of devices that the stream supports, in my case the
Serial Port class.

Am I missing something here or did the .NET group implement their security
incorrectly?

- Steve -

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com</file:></file:>

3

DeviceInterfaces, legacy names and .NETI already though about doing that
trick and it should work for FileStream but unfortunately the SerialPort
class doesn’t allow you to assign a stream to the SerialPort. We already
have a solution that we developed for the .NET 1.1 framework but we where
hoping to use the new class in the future. Alas, I guess we won’t be able
to.

What I would really like to know is if the .NET develoers were just being
overly paranoid or they were lazy with the way that they have implemented
this code. It seems that they have blocked a whole class of applications
that use Device Interfaces and never create legacy names.

  • Steve -

“Arlie Davis” wrote in message
news:xxxxx@ntdev…
It does seem that they have erred on the side of paranoia. You’ll have to
use [DllImport] and roll your own CreateFile import. Declare the return
value (handle) as System.IntPtr. FileStream has a constructor that takes a
HANDLE value encoded as an IntPtr, and a boolean indicating whether the
handle was opened in overlapped mode.

– arlie

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Whitman, Steve
Sent: Tuesday, November 08, 2005 9:42 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] DeviceInterfaces, legacy names and .NET

I recently ran into trouble using a DeviceInterface with .NET 2.0. I have a
WDM driver that implements a Device Interface and does not create a legacy
name. This particular device is a Serial Port device but I have found that
this problem appears to exist with all the .NET stream classes. When I call
the SetupDiXXX functions to get a device interface I get back something like
\?\vs03port#com#6&1b7299&3&0000#{86e0d1e0-8089-11d0-9ce4-08003e301f73}.
With Win32 I then call CreateFile and pass it this string. However I have
found that if I use FileStream or SerialStream with the string returned by
SetupDIXXX then I get an error that an illegal character is in the path. It
turns out that the ‘?’ is the illegal character and because if I change the
string to
\.\vs03port#com#6&1b7299&3&0000#{86e0d1e0-8089-11d0-9ce4-08003e301f73} I
get FileStream will not open Win32 devices such as disk partitions and tape
drives. Avoid use of "\." in the path.
According to Microsoft support they don’t allow \ for security reasons
because they don’t want users to use the SerialPort class to open devices
\PHYSICALDRIVE0 or \C: which I can understand but isn’t this the wrong way
to be preventing that? Shouldn’t they use the SetupDiXXX functions to
validate that the path passed in belongs to the class of devices that the
stream supports, in my case the Serial Port class.
Am I missing something here or did the .NET group implement their security
incorrectly?
- Steve -

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

I think the last few years have shown that their paranoia is quite
justified. At least for now, the class of applications that are likely to
use SetupDi* + CreateFile are much more likely to be written in Win32/C/C++
than in any managed language. I expect (hope) that will change, and when it
does, I hope this situation changes. But until then, we just have to do
some extra interop work.

Sorry for straying from strict NTDEV material.

– arlie

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Steven Whitman
Sent: Tuesday, November 08, 2005 2:30 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] DeviceInterfaces, legacy names and .NET

DeviceInterfaces, legacy names and .NETI already though about doing that
trick and it should work for FileStream but unfortunately the SerialPort
class doesn’t allow you to assign a stream to the SerialPort. We already
have a solution that we developed for the .NET 1.1 framework but we where
hoping to use the new class in the future. Alas, I guess we won’t be able
to.

What I would really like to know is if the .NET develoers were just being
overly paranoid or they were lazy with the way that they have implemented
this code. It seems that they have blocked a whole class of applications
that use Device Interfaces and never create legacy names.

  • Steve -

“Arlie Davis” wrote in message
news:xxxxx@ntdev…
It does seem that they have erred on the side of paranoia. You’ll have to
use [DllImport] and roll your own CreateFile import. Declare the return
value (handle) as System.IntPtr. FileStream has a constructor that takes a
HANDLE value encoded as an IntPtr, and a boolean indicating whether the
handle was opened in overlapped mode.

– arlie

5

I fwd’ed the issue to someone I know .net land (the core execution team,
not the CLR though) hoping to find the person who can answer this.

Thx
d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Steven Whitman
Sent: Tuesday, November 08, 2005 11:30 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] DeviceInterfaces, legacy names and .NET

DeviceInterfaces, legacy names and .NETI already though about doing that

trick and it should work for FileStream but unfortunately the SerialPort

class doesn’t allow you to assign a stream to the SerialPort. We
already
have a solution that we developed for the .NET 1.1 framework but we
where
hoping to use the new class in the future. Alas, I guess we won’t be
able
to.

What I would really like to know is if the .NET develoers were just
being
overly paranoid or they were lazy with the way that they have
implemented
this code. It seems that they have blocked a whole class of
applications
that use Device Interfaces and never create legacy names.

  • Steve -

“Arlie Davis” wrote in message
news:xxxxx@ntdev…
It does seem that they have erred on the side of paranoia. You’ll have
to
use [DllImport] and roll your own CreateFile import. Declare the return

value (handle) as System.IntPtr. FileStream has a constructor that
takes a
HANDLE value encoded as an IntPtr, and a boolean indicating whether the
handle was opened in overlapped mode.

– arlie

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Whitman, Steve
Sent: Tuesday, November 08, 2005 9:42 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] DeviceInterfaces, legacy names and .NET

I recently ran into trouble using a DeviceInterface with .NET 2.0. I
have a
WDM driver that implements a Device Interface and does not create a
legacy
name. This particular device is a Serial Port device but I have found
that
this problem appears to exist with all the .NET stream classes. When I
call
the SetupDiXXX functions to get a device interface I get back something
like
\?\vs03port#com#6&1b7299&3&0000#{86e0d1e0-8089-11d0-9ce4-08003e301f73}.

With Win32 I then call CreateFile and pass it this string. However I
have
found that if I use FileStream or SerialStream with the string returned
by
SetupDIXXX then I get an error that an illegal character is in the path.
It
turns out that the ‘?’ is the illegal character and because if I change
the
string to
\.\vs03port#com#6&1b7299&3&0000#{86e0d1e0-8089-11d0-9ce4-08003e301f73}
I
get FileStream will not open Win32 devices such as disk partitions and
tape
drives. Avoid use of "\." in the path.
According to Microsoft support they don’t allow \ for security reasons
because they don’t want users to use the SerialPort class to open
devices
\PHYSICALDRIVE0 or \C: which I can understand but isn’t this the wrong
way
to be preventing that? Shouldn’t they use the SetupDiXXX functions to
validate that the path passed in belongs to the class of devices that
the
stream supports, in my case the Serial Port class.
Am I missing something here or did the .NET group implement their
security
incorrectly?
- Steve -

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

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

You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

6

I brought this to the NTDEV list because it seemed like the best place
to go for this type of issue. The DDK instructs driver developers to
use Device Interfaces but then the newest MS technology doesn’t work
with them. It seems like there was a disconnect someplace and I wasn’t
sure if that disconnect was with me or elsewhere.

  • Steve -

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Arlie Davis
Sent: Tuesday, November 08, 2005 2:46 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] DeviceInterfaces, legacy names and .NET

I think the last few years have shown that their paranoia is quite
justified. At least for now, the class of applications that are likely
to
use SetupDi* + CreateFile are much more likely to be written in
Win32/C/C++
than in any managed language. I expect (hope) that will change, and
when it
does, I hope this situation changes. But until then, we just have to do
some extra interop work.

Sorry for straying from strict NTDEV material.

– arlie

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Steven Whitman
Sent: Tuesday, November 08, 2005 2:30 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] DeviceInterfaces, legacy names and .NET

DeviceInterfaces, legacy names and .NETI already though about doing that
trick and it should work for FileStream but unfortunately the SerialPort
class doesn’t allow you to assign a stream to the SerialPort. We
already
have a solution that we developed for the .NET 1.1 framework but we
where
hoping to use the new class in the future. Alas, I guess we won’t be
able
to.

What I would really like to know is if the .NET develoers were just
being
overly paranoid or they were lazy with the way that they have
implemented
this code. It seems that they have blocked a whole class of
applications
that use Device Interfaces and never create legacy names.

  • Steve -

“Arlie Davis” wrote in message
news:xxxxx@ntdev…
It does seem that they have erred on the side of paranoia. You’ll have
to
use [DllImport] and roll your own CreateFile import. Declare the return
value (handle) as System.IntPtr. FileStream has a constructor that
takes a
HANDLE value encoded as an IntPtr, and a boolean indicating whether the
handle was opened in overlapped mode.

– arlie

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

You are currently subscribed to ntdev as: xxxxx@cognex.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

7

Well the disconnect is not specific to device interfaces and the device
management api. The .NET framework provides a pretty good development
toolset for system management software except that it is missing about half
of the platform sdk, and the pieces it does have are incomplete, frequently
it appears haphazardly incomplete.

I’ve mentioned this disconnect to Microsoft, and the response I got back is
that there is this net resource out there, pInvoke.net where you can find 50
different and frequently not quite correct ways to implement some of the
missing platform apis. Meanwhile those of us using C# and .Net to do system
management software are stuck in pInvoke or managed C++ wrapper hell. Each
in our own private hell mind you, reinventing the platform SDK in our
isolated workshops over and over and over again. What a waste of bandwidth.
That said, C# is better than the *COM* stuff it has replaced, and it seems
that the 2.0 framework inches the platform api support forward.

=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Whitman, Steve
Sent: Tuesday, November 08, 2005 3:31 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] DeviceInterfaces, legacy names and .NET

I brought this to the NTDEV list because it seemed like the
best place to go for this type of issue. The DDK instructs
driver developers to use Device Interfaces but then the
newest MS technology doesn’t work with them. It seems like
there was a disconnect someplace and I wasn’t sure if that
disconnect was with me or elsewhere.

  • Steve -

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Arlie Davis
Sent: Tuesday, November 08, 2005 2:46 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] DeviceInterfaces, legacy names and .NET

I think the last few years have shown that their paranoia is
quite justified. At least for now, the class of applications
that are likely to use SetupDi* + CreateFile are much more
likely to be written in Win32/C/C++ than in any managed
language. I expect (hope) that will change, and when it
does, I hope this situation changes. But until then, we just
have to do some extra interop work.

Sorry for straying from strict NTDEV material.

– arlie

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Steven Whitman
Sent: Tuesday, November 08, 2005 2:30 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] DeviceInterfaces, legacy names and .NET

DeviceInterfaces, legacy names and .NETI already though about
doing that trick and it should work for FileStream but
unfortunately the SerialPort class doesn’t allow you to
assign a stream to the SerialPort. We already have a
solution that we developed for the .NET 1.1 framework but we
where hoping to use the new class in the future. Alas, I
guess we won’t be able to.

What I would really like to know is if the .NET develoers
were just being overly paranoid or they were lazy with the
way that they have implemented this code. It seems that they
have blocked a whole class of applications that use Device
Interfaces and never create legacy names.

  • Steve -

“Arlie Davis” wrote in message
> news:xxxxx@ntdev…
> It does seem that they have erred on the side of paranoia.
> You’ll have to use [DllImport] and roll your own CreateFile
> import. Declare the return value (handle) as System.IntPtr.
> FileStream has a constructor that takes a HANDLE value
> encoded as an IntPtr, and a boolean indicating whether the
> handle was opened in overlapped mode.
>
> – arlie
>
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@cognex.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag
> argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

8

I’m find it quite handy to forget the SDK altogether and to use
C# the way it’s intended to be used. In fact, I’m almost
convinced that the right vehicle to write that kind of
application is ASP.NET. In the rare cases I needed to access an
SDK entry point, I wrote a quick and dirty wrap. I personally
believe that it’s not that good an idea to mix C++ and .NET, but
then I may be wrong; it’s a personal preference kind of issue.

Alberto.

----- Original Message -----
From: “Mark Roddy”
To: “Windows System Software Devs Interest List”

Sent: Tuesday, November 08, 2005 5:29 PM
Subject: RE: [ntdev] DeviceInterfaces, legacy names and .NET

> Well the disconnect is not specific to device interfaces and
> the device
> management api. The .NET framework provides a pretty good
> development
> toolset for system management software except that it is
> missing about half
> of the platform sdk, and the pieces it does have are
> incomplete, frequently
> it appears haphazardly incomplete.
>
> I’ve mentioned this disconnect to Microsoft, and the response
> I got back is
> that there is this net resource out there, pInvoke.net where
> you can find 50
> different and frequently not quite correct ways to implement
> some of the
> missing platform apis. Meanwhile those of us using C# and .Net
> to do system
> management software are stuck in pInvoke or managed C++
> wrapper hell. Each
> in our own private hell mind you, reinventing the platform SDK
> in our
> isolated workshops over and over and over again. What a waste
> of bandwidth.
> That said, C# is better than the COM stuff it has replaced,
> and it seems
> that the 2.0 framework inches the platform api support
> forward.
>
> =====================
> Mark Roddy DDK MVP
> Windows 2003/XP/2000 Consulting
> Hollis Technology Solutions 603-321-1032
> www.hollistech.com
>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of
>> Whitman, Steve
>> Sent: Tuesday, November 08, 2005 3:31 PM
>> To: Windows System Software Devs Interest List
>> Subject: RE: [ntdev] DeviceInterfaces, legacy names and .NET
>>
>> I brought this to the NTDEV list because it seemed like the
>> best place to go for this type of issue. The DDK instructs
>> driver developers to use Device Interfaces but then the
>> newest MS technology doesn’t work with them. It seems like
>> there was a disconnect someplace and I wasn’t sure if that
>> disconnect was with me or elsewhere.
>>
>> - Steve -
>>
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Arlie
>> Davis
>> Sent: Tuesday, November 08, 2005 2:46 PM
>> To: Windows System Software Devs Interest List
>> Subject: RE: [ntdev] DeviceInterfaces, legacy names and .NET
>>
>> I think the last few years have shown that their paranoia is
>> quite justified. At least for now, the class of applications
>> that are likely to use SetupDi* + CreateFile are much more
>> likely to be written in Win32/C/C++ than in any managed
>> language. I expect (hope) that will change, and when it
>> does, I hope this situation changes. But until then, we just
>> have to do some extra interop work.
>>
>> Sorry for straying from strict NTDEV material.
>>
>> – arlie
>>
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of
>> Steven Whitman
>> Sent: Tuesday, November 08, 2005 2:30 PM
>> To: Windows System Software Devs Interest List
>> Subject: Re:[ntdev] DeviceInterfaces, legacy names and .NET
>>
>> DeviceInterfaces, legacy names and .NETI already though about
>> doing that trick and it should work for FileStream but
>> unfortunately the SerialPort class doesn’t allow you to
>> assign a stream to the SerialPort. We already have a
>> solution that we developed for the .NET 1.1 framework but we
>> where hoping to use the new class in the future. Alas, I
>> guess we won’t be able to.
>>
>> What I would really like to know is if the .NET develoers
>> were just being overly paranoid or they were lazy with the
>> way that they have implemented this code. It seems that they
>> have blocked a whole class of applications that use Device
>> Interfaces and never create legacy names.
>>
>> - Steve -
>>
>> “Arlie Davis” wrote in message
>> news:xxxxx@ntdev…
>> It does seem that they have erred on the side of paranoia.
>> You’ll have to use [DllImport] and roll your own CreateFile
>> import. Declare the return value (handle) as System.IntPtr.
>> FileStream has a constructor that takes a HANDLE value
>> encoded as an IntPtr, and a boolean indicating whether the
>> handle was opened in overlapped mode.
>>
>> – arlie
>>
>>
>>
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as: xxxxx@cognex.com
>> To unsubscribe send a blank email to
>> xxxxx@lists.osr.com
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as: unknown lmsubst tag
>> argument: ‘’
>> To unsubscribe send a blank email to
>> xxxxx@lists.osr.com
>>
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@ieee.org
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com