Device Object Access for Virtual Serial Driver

Hi, I am new to this forum, I found it by coincidence when looking for more information on windows drivers.
In advance, I am not an professional but am experienced development of software, I read in the FAQ that this is a good idea to mention early.

I am currently working on an virtual serial (COM port) driver for an project.
I read a lot about it, and what I do seems to be not the usual "virtual com driver" which just creates two connected virtual ports.

What I need is an driver which lets an user level application create an virtual port on demand, which is available for other applications to use, and all write and read requests including flow control signals should be passed to that application.

I know this could be also achieved using said common drivers, but I want to use this chance to learn more about windows drivers, so far I managed to write an virtual serial port driver where the writes just end in the void and read always returns an fixed string.

My question now is, how can make my application comunicate with the serial port without opening it using CreateFile, since this would block it from being accessed by external programs.
From what I found out about drivers in general, pretty much all communication between applications and drivers are happening trough IOCTL-Codes, which I already implemented for the normal serial port operation and I could just add some more for custom read and writes to the internal buffers, and to read the flow control signals, but for that the application needs to be able to get an handle for the device, without blocking other applications to do the same.

Coincidentally there happens to be also an another related problem, which actually prevents other aplications from being blocked when the port is already opened by one process.
For some reason I am able to open the port in as many applications as I want, which is not the behavior of normal COM ports.

I would appreciate if someone could help me figure this out, an link to some better documentation would also help, I could not find much to this, probably because this is not a common requirement for drivers.

If you have not called WdfDeviceInitSetExclusive, then your device can be opened by multiple applications. You could add a special ioctl that your controller calls to identify it as the "driver".

(The device can also be made "exclusive" by setting a registry value in the INF. Check https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdfdevice/nf-wdfdevice-wdfdeviceinitsetexclusive.)

Ah, I read about the registry entry in the INF, but I could find absolutely no information on what I need to write in the INF to make it happen.
An AI I asked about it said I need to add
[Device]
Exclusive = 1
SharedMode = 0

But this did not do anything.
WdfDeviceInitSetExclusive was mentioned nowhere, thanks for the info.
Weird is that the sample driver I looked at before did neither had an special INF entry (at least I did not see it) nor this function, and it behaved like an exclusive device, so I tought it should be the default behavior.

The question that now remains is, how can I let an application read and write to the internal buffers and registers without preventing an second application for "claiming" the port ?
The ideal solution would be to allow exact two handles for the port.
Since one application is pretty much guaranteed to run, to the user it would behave like an normal port from then on.

I remember somewhere that you can implement the "exclusiveness" in code as well, maybe it would be possible to do that and just add a counter that blocks further requests if two handles are active ?

I just tried to implement the function in my driver, but the documentation said its only for KMDF, and I indeed cant find it in my IDE.

I forgot to mention that at the beginning, but I started the driver as UMDF project, since the docs suggested you should only use KMDF if needed.

Is this enough of a reason to switch to KMDF, or is there an other way of getting the exclusive behavior ?
Preferably with the mentioned 2 applications limit.