Bluetooth headset mic never appears in Windows 11 because a leftover OEM driver is shadowing Microsoft's inbox stack
Short version: if a Bluetooth headset gives you working stereo audio but no microphone, and "Handsfree Telephony" is already ticked, check whether a third-party driver has claimed the Handsfree node. On my machine a Realtek HFP driver from 2017 had it, and Microsoft's BthHFEnum service was sitting stopped. Removing that package from the driver store fixed it permanently.
This is not specific to one headset or one adapter. It hits any Windows machine that has ever had a Realtek Bluetooth software bundle installed, which covers a lot of laptops and generic USB dongles.
Symptom
- Headset pairs and plays stereo audio fine
- No microphone in mmsys.cpl > Recording, not even greyed out
- Handsfree Telephony is present and ticked under Properties > Services
- BTAGService, bthserv and the Bluetooth User Support Service are all running
- Works correctly on Android, iOS and macOS, so the headset does support HFP
Why the usual advice does not stick
The standard answer is: unpair, uninstall the Bluetooth audio devices in Device Manager, restart, re-pair. That does often work, and it worked for me too.
It works because it forces re-enumeration. It does not stick, because the package that caused the problem is still sitting in the driver store and wins the ranking again the next time the node is created. That is why these threads keep coming back.
Diagnosis
Three checks. Run all of these in an elevated PowerShell.
1. Is a third-party driver holding the Handsfree node?
Get-PnpDevice | Where-Object { $_.InstanceId -match 'BTHENUM\\{0000111E-' } | ForEach-Object {
Get-PnpDeviceProperty -InstanceId $_.InstanceId -KeyName `
DEVPKEY_Device_DriverProvider,DEVPKEY_Device_DriverVersion,DEVPKEY_Device_DriverInfPath |
Select-Object KeyName,Data
}
{0000111E} is the Handsfree profile UUID. Healthy output says Microsoft and microsoft_bluetooth_hfp_ag.inf. Mine said:
DEVPKEY_Device_DriverProvider Realtek Semiconductor Corp
DEVPKEY_Device_DriverVersion 1.1.84.3
DEVPKEY_Device_DriverInfPath oem11.inf <- rtkhfp.inf, dated 03/24/2017
A 2017 driver with the Legacy attribute servicing HFP on Windows 11 build 26200.
2. Which HFP service is actually running?
Get-Service BthHFEnum,BthA2dp,BthAudioHF,RtkA2dp -EA SilentlyContinue |
Select-Object Name,Status,StartType
Before:
BthA2dp Stopped <- Microsoft inbox A2DP
BthAudioHF Running <- Realtek 2017 HFP
BthHFEnum Stopped <- Microsoft inbox HFP
RtkA2dp Running <- Realtek 2020 A2DP
Both inbox services stopped while the Realtek equivalents run. That is the tell.
3. Does the mic endpoint exist but sit inert?
Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\MMDevices\Audio\Capture' | ForEach-Object {
$s = (Get-ItemProperty $_.PSPath -Name DeviceState -EA 0).DeviceState
$n = (Get-ItemProperty "$($_.PSPath)\Properties" -EA 0).'{a45c254e-df1c-4efd-8020-67d146a850e0},2'
$d = (Get-ItemProperty "$($_.PSPath)\Properties" -EA 0).'{b3f8fa53-0004-438e-9003-51a46e139bfc},6'
"State=$s $n ($d)"
}
Mine returned State=4, which is DEVICE_STATE_NOTPRESENT. The endpoint was registered the whole time. The old driver creates the registration and never instantiates a capture pin, so it is filtered out of the Recording tab unless you tick "Show Disconnected Devices".
That is the actual bug. Not a missing device, an inert one.
Root cause
Windows binds Bluetooth profiles per service GUID. Inbox bth.inf claims the generic form:
BTHENUM\{0000111e-0000-1000-8000-00805f9b34fb}_GENERIC
The Realtek package claims the more specific hardware ID that includes the device VID and PID. More specific wins driver ranking, so an ancient third-party package outranks the current inbox stack and Microsoft's HFP enumerator never starts.
Fix
Read this before running anything: oemNN.inf numbers are assigned per machine. oem11.inf on my system is a Realtek HFP driver. On yours it is almost certainly something completely unrelated. Do not copy my numbers. Look yours up with step 1 above, or use the script at the end which discovers them.
Elevated PowerShell.
1. Find every third-party package bound to a Bluetooth audio node. Audio profile GUIDs worth checking are 0000111E (Handsfree), 00001108 (Headset), 0000110B / 0000110A (A2DP), 0000110C / 0000110E (AVRCP).
2. Confirm what each one is before deleting it.
Get-WindowsDriver -Online | Where-Object Driver -eq 'oemNN.inf' |
Select-Object Driver,OriginalFileName,ProviderName,Version,Date
In my case: rtkhfp.inf (2017), rtka2dp.inf (2020), rtkavrcp.inf (2018), bthvirtual.inf (2013).
Do not remove the radio driver. On a TP-Link UB500 that is rtkfilter.inf, which loads the RTL8761B firmware patch. It is required and unrelated. Only remove profile drivers.
3. Back up, then remove.
pnputil /export-driver oemNN.inf C:\btdriver-backup\oemNN
pnputil /delete-driver oemNN.inf /uninstall
4. Unpair the headset, remove leftover nodes, reboot, re-pair. Wait 30 seconds after pairing before checking.
Worth doing in the same pass: check for phantom device nodes. I had a complete duplicate enumeration branch, 13 dead nodes including a second copy of the Realtek HFP device, which is what produced duplicate endpoint entries.
Verification
BthA2dp Running <- was Stopped
BthHFEnum Running <- was Stopped
BthAudioHF and RtkA2dp no longer exist as services. The Handsfree node now reports:
Provider Microsoft
InfPath microsoft_bluetooth_hfp_ag.inf
And the capture endpoint moved from State=4 to State=1 (DEVICE_STATE_ACTIVE). The device even renamed itself, from Realtek's Buds( Mono ) to Microsoft's Buds Hands-Free. The mic works in the Recording tab with a live level meter.
Stereo A2DP output still works and is now served by inbox BthA2dp rather than RtkA2dp.
Rollback
Exports from step 3 restore cleanly:
pnputil /add-driver C:\btdriver-backup\oemNN\<name>.inf /install
Then unpair and re-pair.
Hardware this was found on
TP-Link UB500 (USB\VID_2357&PID_0604, Realtek RTL8761B), TP-Link driver 1.9.1051.3016, Windows 11 build 26200, CMF Buds 2 Plus. The UB500 driver was correct and installed the whole time and was not the problem. Same fix should apply to any adapter and any headset, because the conflict is between driver packages, not with the radio.
