Bluetooth and Wireless display not working on Windows Server 2022

vali20 thnks

Also, the Bluetooth headphones don't seem to be able to remember the volume level, they always start at 100% when using this hack which is pretty disturbing...

Edit: Apparently, it is a "feature" called "absolute volume". It has to be disabled, at least with the headphones I use, as explained here: https://www.tenforums.com/tutorials/151957-how-enable-disable-bluetooth-absolute-volume-windows-10-a.html

Edit2: It also unlocks WAY more volume - before, sound was crippled on Bluetooth, only mild at max, now I cannot go to 100% safely let's say =))) this "feature" was introduced in 1809 apparently, as expected, another crap.

https://pixeldrain.com/u/oSdnLgGc

They're ALMOST gone off the Internet, because of this whole "PM me" non-sense I will never understand. You'd expect by now Microsoft would have backported this already, the reason for it not being there in the first place being beyond any comprehensible understanding - why strip out OS features from the version supposed to be feature rich? Not to mention, you'd expect Server to be able to behave as an audio sink, i.e. play media from your phone to the "server"'s speakers. But no, they strip the whole thing away, like whaaaat???

Anyway, enough of my rant, here you go. It was on page 137 on Google, past a bunch of Chinese forums and paywalls and what not. We now have it again, thankfully. It works, but for me personally BTAGService/headset role (i.e. when using teleconference apps) BSODs the system when accessing the microphone page in the Sounds Control Panel, for example.

BC_BLUETOOTH_VERIFIER_FAULT (bfe)
The Bluetooth profile driver verifier has caught a violation.
Look at the call stack to determine the misbehaving driver.
Arguments:
Arg1: 0000000000000003, An attempt was made to allocate or initialize an invalid BRB type
Arg2: ffffc20fa8bfd240, Brb pointer
Arg3: 0000000000008203, PDO extension (if available)
Arg4: 0000000000000000, Reserved

It's in bthport!BthInitializeBrb, coming from BthAllocateBrb and bthfenum!ScoChannelOpen. bthfenum comes from this archive, bthport is stock 20348. It happens right at the beginning, it passes some id that the Bluetooth stack from 20348 does not recognize, yet the stack in 19041 knew about. Maybe at some point I will debug it further, if I knew the ID at least, I could look for the meaning and determine the correct one to use and from there some binary patch/driver and go from there. It is fixable, I just do not have any more time to spend on this for now. Last 5 days, among other things, I battled with getting Server 2022 to fully work on my laptop, I already had to patch away a crash in the Waves audio crap it ships with.

Personally, I don't use conferencing apps on my PC (because, yeah, it drains battery like crazy compared to the iPhone), so not a big deal, but still, I'd want full functionality ofc. Will revisit this in the future. For now, at least it's better, since Windows never gets confused and pick the headset profile to play music through - it has happened in the past, unfortunately. To be honest, this packages only being the core, what is required, the stack actually works rock solid, no clunkiness like on client Windows. Once it works, it connects, disconnects etc immediatly when demanded, yeah, it works. And in general, things on Server work, once you get them to actually... work.

If we'd get some proper files from this build, everything would pretty much be sorted, community backported, the support is there, I am even sure the files are compiled somewhere on Microsoft's servers and just not shipped. The fact that they scroll by this issue and only mention support in vNext. Why? It takes a proper dev an afternoon to put the bits in and have this shipped, it's not rocket science if people can almost pull it off with drivers from alien builds and WITHOUT any source code.

It's just lame. Don't get me started on the whole precision touchpad support - they forgot to ship a driver that is already in WinPE (hidi2c.sys) and a bunch of registry configuration data... again, just why...?