UMDF driver installation does not work on Windows Containers

[AlexBAV]

Describe the bug The product we are developing installs a user-mode driver (UMDF driver) to present a virtual serial port device to the rest of the system and it is compatible with all client and server OS versions (including server core).

However, when we try to install it inside a Windows Container, we get a bunch of errors.

Below is a brief description of what we managed to discover so far:

1. UMDF driver installation fails on any image. Debugging and tracing revealed that undocumented CM_Add_Driver_PackageW cfgmgr32.dll function (called from documented DiInstallDriverW function) reported CR_NO_CM_SERVICES (0x32) error after trying to communicate with some other process over RPC. This error code is also undocumented but gives a hint that some system component is missing. On desktop OS images, another non-illustrative error code (0xd - the data is invalid) is reported.

2. We discovered that if the startup type of the DeviceInstall system service is changed to "Manual", driver installation succeeds. The default state of this service is "Disabled", which is different from default state on non-container OSes (both client and server).

3. When the product creates a new device, the attempt fails. The device node is created and installed driver is configured for it. However, the device remains in an error "stopped" state. If container is running in process isolation mode, device creation succeeds and device is reported in "started" mode. However, the driver host process, WUDFHost.exe is not running. Any attempts to diagnose the problem by checking the relevant WDF/UMDF logs or attempts to diagnose host process startup issues fail.

Is installation of the UMDF driver supported on Windows Containers, and if it is not, if it is ever planned?

To Reproduce Try to install a product with UMDF driver. I'm not sure if the product link may be posted here, but if required, I can provide it over private channel.

Expected behavior Successful installation and operation of UMDF drivers and their virtual devices.

Configuration:

• Edition: Host: Windows 11
• Base Image being used: mcr.microsoft.com/windows:ltsc2019
• Container engine: Docker
• Container Engine version 20.10.21

Additional context

[jwilsonCX]

I would dearly like to see the ability to install [serial port] device drivers within Windows containers as @AlexBAV is suggesting. We have a significant number of sites that still require us to integrate with their legacy serial apparatus (fire panels, security and access control, nursecall, medical devices, etc.). We have built up a large library of such integrations over 20+ years of our product's development, and we'd obviously like to leverage that tried-and-tested code as we migrate our software to cloud via containerization. Rewriting this code would be fraught with difficulty; it would be exceedingly difficult and expensive to test/validate since many of these systems are no longer being manufactured, and thus the only testing possible would be on live production deployments. Plumbing legacy serial communication over IP networks is a solved problem these days via a variety of third party solutions. Unfortunately all of these products hinge on the ability to install a "virtual COM port" driver into Windows to which the software can bind to.

Clearly there are others in the Docker community who would applaud this capability too.

[fady-azmy-msft]

Hey @AlexBAV, installing a UMDF is not currently supported on Windows Container, but we can consider putting this is on our roadmap. Can you share more about what you're trying to accomplish?

[AlexBAV]

@fady-azmy-msft, thank you for getting back to me.

We develop and ship a product that implements virtual serial port devices and provides several advanced configurations (like "connecting" virtual devices together to create virtual bridges, providing shared access to COM ports or connecting them to remote COM ports, TCP/IP endpoints and so on).

For this, we have developed a product that contains an UMDF driver that implements the functionality of a serial device. The driver is accomplished with an in-process COM server providing API for applications to create and control virtual serial devices. It can be easily installed and controlled with command-line, PowerShell or any Automation-compatible programming language.

Some of our customers (like @jwilsonCX described above) are experimenting on bringing old infrastructure to the cloud with a help of Windows Containers. Part of their infrastructure includes legacy applications that only support working with serial ports. The intention is to use our product to create virtual serial devices in a container for the legacy application to work with.

Our UMDF driver will then transfer all sent and received data to the remote TCP/IP endpoint emulating (or providing the actual access to) specific hardware.

Right now, our product supports all shipped Windows versions beginning with Windows 7 (including all server versions, even core), but fails to work in a container image.

[microsoft-github-policy-service[bot]]

This issue has been open for 90 days with no updates. no assignees, please provide an update or close this issue.

[microsoft-github-policy-service[bot]]

This issue has been open for 90 days with no updates. no assignees, please provide an update or close this issue.

[jwilsonCX]

Just received notice that this thread is going stale. @fady-azmy-msft thank you for marking this request as an enhancement -- has there been any traction in the past three months that might suggest whether this feature request will ever see the light of day? How might we track that? Is there any additional insight/rationale that we can proffer to the Windows container gods™ to bolster the case for adding support for UMDF driver installs to Windows containers, beyond what @AlexBAV and I have already furnished?

[Alikont]

Hello

We're also interested in running tests for graphic applications inside containers and we would like to be able to run UMDF Indirect Display Driver inside Windows Container.

[riyapatel-ms]

@jwilsonCX I am in the process of investigating the feasibility of this feature in our current roadmap. While we don't have a mechanism for external tracking, I've filed this in our backlog of feature requests (item 45580789). Will provide an update soon.

[jwilsonCX]

@jwilsonCX I am in the process of investigating the feasibility of this feature in our current roadmap. While we don't have a mechanism for external tracking, I've filed this in our backlog of feature requests (item 45580789). Will provide an update soon.

Thanks for keeping the flame alive, Riya! Please let me know if you need any additional rationale for this feature beyond what is already posted.

[AlexBAV]

@jwilsonCX I am in the process of investigating the feasibility of this feature in our current roadmap. While we don't have a mechanism for external tracking, I've filed this in our backlog of feature requests (item 45580789). Will provide an update soon.

Crossing fingers...

[riyapatel-ms]

Hey team, here are some updates (unfortunately still no news of when/if this will get picked up): Sounds like there are 2 issues here.

1. The first is the request to be able to install user mode drivers within the container. That will likely require a fairly significant investment. We'll have to study how valuable this would be.
2. The second issue seems to be folks would like to access the physical serial port (correct me if this is an incorrect assumption) from within a container. This request is likely less intensive but will also likely have less of a story on AKS, but it might be interesting in some on-premise situations.

Both of these issues will require some further study.

[jwilsonCX]

Hi @riyapatel-ms ,

1. The first is the request to be able to install user mode drivers within the container.  That will likely require a fairly significant investment.  We'll have to study how valuable this would be.

I'll have to let @AlexBAV comment on the implications of this, as it's beyond my pay grade.

2. The second issue seems to be folks would like to access the physical serial port (_correct me if this is an incorrect assumption_) from within a container.  This request is likely less intensive but will also likely have less of a story on AKS, but it might be interesting in some on-premise situations.

This may just be a bit of confusion over semantics, but I don't think the intent here was necessarily to have the container process access a "physical" serial port (or other hardware resource) that resides on the host itself. As you noted, such a scenario wouldn't make a lot of sense when the container (or more precisely, the pod hosting the container) is being scheduled via something like AKS.

Instead, the intent is to install the user mode driver so that it is capable of emulating a serial port so that legacy software running inside the container can "see" the serial port and bind to it (i.e. a virtual COM port). This is no different than how @AlexBAV solution works today on virtual machines, where there is no underlying physical serial port hardware, everything is entirely virtualized.

Maybe worth noting that if one actually did want to access the host's serial port from inside the container (say in a simple on-prem Docker Desktop deployment) then it could still be facilitated with the above configuration by installing the same virtual COM port driver on the host, and then linking the two with a "virtual null modem cable" via the local network.

Jason

[AlexBAV]

Hi @ryapatel-ms,

@jwilsonCX is absolutely right. The first would be highly desirable, allowing this particular, as well as plenty of other scenarios to be easily achievable. (See for example what @Alikont suggests above).

The second one is more a niche task, mostly for local scenarios where the underlying hardware is known and fixed.

[microsoft-github-policy-service[bot]]

This issue has been open for 90 days with no updates. @riyapatel-ms, please provide an update or close this issue.

[connexallcloud]

This issue has been open for 90 days with no updates. @riyapatel-ms, please provide an update or close this issue.

We need you desperately @riyapatel-ms! Please don't let this thread die a lonely and unfulfilled death at the hands of the cruel and callous github policy bot!

Jason

[riyapatel-ms]

Hey team, the github policy bot can't take us down this easily :) in terms of updates, this is still in our backlog, if we need more information on the ask I'll be sure to loop you guys in

[microsoft-github-policy-service[bot]]

This issue has been open for 90 days with no updates. @riyapatel-ms, please provide an update or close this issue.

[riyapatel-ms]

pinging to keep alive

[jwilsonCX]

pinging to keep alive

Thank you Riya for keeping the dream alive! May the flame of hope for UMDF driver support in Windows containers never die!

[microsoft-github-policy-service[bot]]

This issue has been open for 90 days with no updates. @riyapatel-ms, please provide an update or close this issue.

[jwilsonCX]

Looks like we just celebrated the first anniversary of our very first bot notice on this thread. They grow up so fast!

Still hoping to hear word that this request will be taken up by the MS container team. Despite the passage of time, the business requirement for this enhancement remains the same.