What NS_E_NO_ACTIVE_SOURCEGROUP (0XC00D1B72) actually means
You hit 0XC00D1B72 because the publishing point or stream has nothing feeding it. Windows Media Services, Windows Media Encoder, or whatever tool is driving the pipeline is asking "where's the source?" and getting nothing back. The source group — the abstract container for your live or file-based input — isn't active.
I've seen this three ways in the wild: a publishing point where the encoder disconnected and never reconnected, a capture card that Windows dropped after a driver update, and a WMS server where the source group got disabled after a Windows Update reset permissions. Same error code, three different layers.
Before you touch anything, check the obvious: is the encoder process actually running? Open Task Manager, look for wmenc.exe or wmserver.exe. If the encoder crashed, you'll never get a source group. Kill it, restart it, see if the error clears. If it does, stop reading. If it doesn't, keep going.
Cause 1: The source group is disabled or missing in Windows Media Services
This is the one that gets most people. In WMS, a publishing point needs at least one active source group. If someone disabled it during maintenance, or a Windows Update broke the WMS configuration store, the publishing point comes up with no source and throws 0XC00D1B72 the moment a client connects.
Log into the WMS box. Open the Windows Media Services MMC snap-in. Expand the server, expand Publishing Points, and find the one that's failing. Right-click it, hit Properties, and look at the Source tab. If the source group list is empty or all entries show a red X, that's your problem.
The fix:
- Delete the broken publishing point.
- Recreate it with Add Publishing Point (Wizard).
- Choose the correct source type (encoder, playlist, file).
- Point it at your actual encoder or file path.
- Start the publishing point manually.
If you'd rather not click through the wizard, or you're scripting this across a fleet, use the WMS admin command line:
wmsadmin.exe -server localhost -action addpubpoint -name Live -sourceType Encoder
wmsadmin.exe -server localhost -action start -name LiveThen restart the WMS service to clear any cached state:
net stop wmserver
net start wmserverHad a client last month running WMS 2008 R2 on a broadcast appliance. A scheduled task had disabled the source group as part of a "cleanup" script someone wrote two years ago and forgot about. Took 40 minutes to find the task, 2 minutes to fix the error.
Cause 2: The encoder never connected — port or firewall issue
If the WMS side looks fine but you're still seeing 0XC00D1B72, the encoder isn't reaching it. Windows Media Encoder pushes to WMS over HTTP on port 80 (or 8080 if you changed it) or over RTSP on 554. If any of those are blocked, the publishing point sits there with no source, and every status check throws 0XC00D1B72.
Test from the encoder machine:
telnet wms-server 8080If that hangs or refuses, it's a firewall. Check both sides:
- Windows Firewall on the WMS box: inbound TCP 80, 8080, 554 allowed for
wmserver.exe - Windows Firewall on the encoder box: outbound to those ports
- Any hardware firewall between them — this is where most corporate setups fail
One gotcha on Server 2016 and later: the default inbound rule for Windows Media Services may be disabled after a feature update. Open wf.msc, find the rule named Windows Media Services (HTTP-In), and enable it. I've had this bite me twice on 2019 boxes that got patched over a weekend.
Also confirm the encoder is actually pointed at the right server and port. In Windows Media Encoder, go to Properties > Output > Push to server. If that URL is wrong, the encoder happily streams into nothing and WMS throws the error forever.
Cause 3: Capture device dropped out or driver broke
Third most common — and the most annoying because it looks like a software bug. The source group is active, the publishing point is fine, but the actual capture device (USB webcam, Blackmagic card, Osprey, whatever) has disappeared from Device Manager. Windows Media Encoder doesn't get a device, so it opens a source group with no actual media source inside it. Result: 0XC00D1B72.
Check Device Manager. Look under Sound, video and game controllers and Imaging devices. If your capture hardware isn't listed, or it has a yellow bang:
- Unplug the device (physically, USB too).
- Uninstall any entries for it in Device Manager — including hidden ones (View > Show hidden devices).
- Reinstall the vendor driver. Don't trust Windows Update's generic driver for capture cards. Get it from Blackmagic, Osprey, Magewell, whoever makes your hardware.
- Reboot, plug the device back in, confirm it appears without a warning icon.
- Restart the encoder and re-select the source.
USB capture devices on AMD Ryzen systems with certain chipset drivers will vanish under load. If that's you, switch to a PCIe card or move the USB device to a port on a different controller. I've watched an Osprey 260e disappear mid-stream on an X570 board — no amount of driver reinstalling fixes it, but moving to an Intel NIC-style USB controller does.
One more thing: some capture devices lock to a single application. If OBS or Teams has the device open, Windows Media Encoder can't grab it. Close everything else and retry.
Quick reference
| Cause | Symptom | Fix |
|---|---|---|
| Source group disabled or missing in WMS | Publishing point up but no source, error on client connect | Recreate publishing point, restart wmserver |
| Encoder can't reach WMS (firewall/port) | Encoder shows connected, WMS shows no source | Open TCP 80/8080/554 both ways, check push URL |
| Capture device missing or locked | Device Manager blank or warning; encoder opens no source | Reinstall vendor driver, close other apps, swap USB controller |
If none of those work, pull the WMS logs from %SystemRoot%\System32\LogFiles\WMS and look at the last event before the error. Nine times out of ten the log tells you which of the three causes you're actually dealing with. Don't guess — read the log.