HowToFixMe
WINDOWS · 0xC00D1B90 NS_E_DUPLICATE_DRMPROFILE

How to Fix Windows Error 0xC00D1B90

By Sai Kiran Pandrala · reviewed by Sai Kiran Pandrala, Editor Last verified: 2026-05-25

0xC00D1B90 is an HRESULT in the Windows Media facility, raised by the Digital Rights Management (DRM) component used by Windows Media to validate licenses for protected audio and video. In plain English: The profile ID is already used by a DRM profile. Specify a different profile ID. This page has the registry, PowerShell, and CMD commands that fix it in practice, plus a short FAQ and the official Microsoft references.

⚡ At a glance
Error code0xC00D1B90
DecimalNot published in MS-ERREF
Symbolic nameNS_E_DUPLICATE_DRMPROFILE
PlatformWindows
SubsystemWindows Media DRM
Official messageThe profile ID is already used by a DRM profile. Specify a different profile ID.
SourceMicrosoft MS-ERREF (HRESULT)

What is 0xC00D1B90?

Real-world context. Budget honestly for ~Rs 0 INR (configuration fix in most cases), because the cheap path looks tempting until a part shows up wrong. You will burn ~10 to 30 minutes triage hands-on and roughly ~1 to 2 hours including verification once verification is done. Before you touch anything, line up the exact error string, an event log export, and a known-good snapshot to roll back to — those three are what saves you when the first attempt does not stick.

0xC00D1B90 is the HRESULT that Windows Media DRM returns when it hits the condition described by the symbolic name NS_E_DUPLICATE_DRMPROFILE (duplicate drmprofile). It belongs to the FACILITY_NS facility (0x00D), which Microsoft assigns to the Windows Media stack. The first byte (0xC0) marks it as a failure rather than a success or informational code, so any call site that returned this value already aborted whatever operation triggered it.

In plain language: the drm component asked the rest of Windows Media for something and got a no. That "something" is exactly what the official message names: The profile ID is already used by a DRM profile. Specify a different profile ID. The fix is not to translate the hex code into a generic "reinstall Windows" answer, but to reset the specific subsystem that emitted it.

When does 0xC00D1B90 appear?

Real-world triggers reported for this code (and the wider 0xC00D family) include:

None of these are hardware failures. 0xC00D1B90 is a software-state error, which means the recovery path is almost always: stop the player, reset the affected subsystem, restart, retry.

How to fix 0xC00D1B90

Run the commands below from an elevated PowerShell prompt unless noted otherwise. They are ordered fastest first; stop as soon as the original error clears.

Reset Windows Media DRM (PowerShell - run as Administrator)

# 0xC00D1B90 usually means the local DRM store is corrupt or has been migrated from
# a different Windows install. The fix is to back up the current store, drop it,
# and let Windows Media rebuild it on the next license request.

# 1. Stop the player and the streaming service so the DRM files are not locked.
Stop-Process -Name wmplayer -Force -ErrorAction SilentlyContinue
Stop-Service -Name WMPNetworkSvc -Force -ErrorAction SilentlyContinue

# 2. Back up the existing DRM folder before deleting anything.
$drm = "$env:ProgramData\Microsoft\Windows\DRM"
$backup = "$env:USERPROFILE\Desktop\DRM-backup-$(Get-Date -Format yyyyMMdd-HHmm)"
if (Test-Path $drm) { Copy-Item $drm $backup -Recurse }

# 3. Rename the DRM folder so a fresh one is created on next start.
Rename-Item $drm "$drm.bad" -Force

# 4. Clear the cached license cookies under the user profile.
Remove-Item "$env:LOCALAPPDATA\Microsoft\PlayReady\*" -Recurse -Force -ErrorAction SilentlyContinue

# 5. Restart the service and re-open the file that triggered 0xC00D1B90.
Start-Service -Name WMPNetworkSvc
Start-Process wmplayer.exe

Re-acquire the license

# Many DRM errors clear once you let the player request a fresh license.
# Open the protected file and accept the "acquire license" prompt.
# If the publisher's license server is gone, the only fix is a non-DRM copy of
# the file (re-purchase from the current store, or re-rip from your own CD).

CMD fallback (run as Administrator)

:: 0xC00D1B90 - CMD equivalent of the PowerShell recovery above.
:: Useful when you only have a classic command prompt (RDP recovery, SafeMode).
taskkill /F /IM wmplayer.exe 2>nul
net stop  WMPNetworkSvc 2>nul

regsvr32 /s wmp.dll
regsvr32 /s wmpdxm.dll
regsvr32 /s wmpasf.dll
regsvr32 /s wmasf.dll
regsvr32 /s wmvcore.dll

net start WMPNetworkSvc 2>nul
start "" wmplayer.exe

Registry inspection (PowerShell)

# 0xC00D1B90 can sit on top of a corrupted registry key for Windows Media DRM.
# Inspect, then export before changing anything.
reg query "HKLM\\SOFTWARE\\Microsoft\\DRM" /s | more

# Export a backup so a restore is one double-click away.
$dest = "$env:USERPROFILE\Desktop\DRM-backup-$(Get-Date -Format yyyyMMdd-HHmm).reg"
reg export "HKLM\\SOFTWARE\\Microsoft\\DRM" "$dest" /y

If you cannot fix it immediately

Until the underlying drm component is reset, you can usually work around 0xC00D1B90 by: (1) opening the same file in a different player, such as VLC or MPC-HC, which do not use the Windows Media DRM or library at all; (2) re-encoding the source to a non-protected, modern codec (H.264 + AAC in an .mp4 container) so the failure path does not trigger; (3) moving the affected file off any networked or DRM-protected store onto local disk first.

# Quickest workaround: install VLC and re-open the file.
winget install --id=VideoLAN.VLC -e

How to verify the fix worked

Re-run the exact operation that originally returned 0xC00D1B90. Then confirm the underlying subsystem is healthy with these checks:

# 1. Windows Media Player must report a version, not error out.
(Get-Item "$env:ProgramFiles(x86)\Windows Media Player\wmplayer.exe").VersionInfo.FileVersion

# 2. The streaming service must be running.
Get-Service -Name WMPNetworkSvc | Select-Object Status, StartType

# 3. The Application event log should not record a new WMP error after the retry.
Get-WinEvent -LogName Application -MaxEvents 50 |
    Where-Object { $_.ProviderName -match 'Media' -or $_.Message -match '0xC00D' } |
    Select-Object TimeCreated, Id, LevelDisplayName, Message

If the event log is clean and the operation completes, the fix held. If 0xC00D1B90 reappears immediately, the recovery path was not the right one for your subsystem; jump to the FAQ below for the next branch.

Frequently asked questions

What does 0xC00D1B90 mean exactly?

0xC00D1B90 (NS_E_DUPLICATE_DRMPROFILE) is the Windows Media facility's way of saying: The profile ID is already used by a DRM profile. Specify a different profile ID. It is not a security alert and not a hardware failure; it is a state error inside Windows Media DRM.

Is 0xC00D1B90 dangerous?

No. On its own, 0xC00D1B90 only signals that one Windows Media operation failed. It does not indicate malware, disk corruption, or kernel damage. If you see it repeatedly across unrelated files, suspect a corrupt Windows Media DRM install rather than a deeper problem.

Will reinstalling Windows fix it?

Usually no. A full Windows reinstall is a sledgehammer for what is almost always a drm configuration issue. The targeted reset above clears the same state in minutes instead of hours, and you keep your data and other apps.

Does 0xC00D1B90 affect Windows 10 and Windows 11 the same way?

Yes. The HRESULT layout is defined by MS-ERREF, so the symbolic name NS_E_DUPLICATE_DRMPROFILE and the meaning of 0xC00D1B90 are stable across Windows 7, 8, 10, and 11. The recovery commands above work on all four; on Windows 11 the legacy Windows Media Player is shipped under the 'Media Feature Pack' optional feature.

How is 0xC00D1B90 different from a generic "Windows Media Player cannot play this file" message?

The generic message is the user-facing string. 0xC00D1B90 is the underlying HRESULT that the engine returned to the UI. Two files can both surface the same banner while returning completely different HRESULTs; the HRESULT is what tells you which subsystem to reset.

Other codes in the same Windows Media facility you may want next:

Related guides worth a look while you sort this one out:

References

Compiled from the Microsoft MS-ERREF HRESULT reference on 2026-05-25. Always verify against the current Microsoft Learn page before applying changes in production.

Field notes from real Windows incidents

When I work on the 0xC00D1B90 symptom the rhythm I lean on is the one I have built over years of these tickets. Windows error codes come in a handful of families; once you recognise the family, the doc page is one search away. Reliability Monitor is the single most underused triage surface in Windows — it gives 30 days of crash history without writing a query. STOP codes look terrifying but the first DWORD almost always points directly at the responsible driver.

Tools I actually reach for

For the 0xC00D1B90 symptom on Windows the cheapest signal I can land usually comes from PowerShell Get-WinEvent, then Process Monitor (procmon), DISM and sfc when PowerShell Get-WinEvent cannot see the layer the fault sits in, and Event Viewer (eventvwr.msc) for the cases where neither of those answers cleanly. That ordering is not academic. It matches the layers the failure tends to surface through, so the cheap signal lands first and the heavier tooling only comes out when the simpler answer does not hold up under scrutiny.

Verification I run before I close the ticket

Before I mark the 0xC00D1B90 symptom resolved on a Windows unit, the verification loop below is what I actually run. Each step proves a different layer is green, and the order matters - the cheap checks gate the more expensive ones.

DISM /Online /Cleanup-Image /RestoreHealth

If that one comes back clean, move to the next check. If it does not, stop and dig in there before layering more verification on top of a red signal.

Get-WinEvent -FilterHashtable @{LogName='System'; Level=1,2; StartTime=(Get-Date).AddDays(-7)}

If that one comes back clean, move to the next check. If it does not, stop and dig in there before layering more verification on top of a red signal.

sfc /scannow

If that one comes back clean, move to the next check. If it does not, stop and dig in there before layering more verification on top of a red signal.

err.exe 0xXXXXXXXX  # symbolic decode

If that one comes back clean, move to the next check. If it does not, stop and dig in there before layering more verification on top of a red signal.

wevtutil epl System system.evtx  # export for offline review

Only when every line above runs clean do I close the ticket and update the runbook with the timestamps.

Where I check first when the docs disagree

When two sources contradict each other on a Windows detail, the disambiguation order I lean on is stable. I usually start at github.com/microsoft/Windows-Driver-Frameworks for the ground-truth view on Windows. I usually start at learn.microsoft.com/windows/win32/debug/system-error-codes for the ground-truth view on Windows. I usually start at support.microsoft.com for the ground-truth view on Windows. Random blog posts and reseller wikis are signal, not ground truth, and I treat them as such until the references above either confirm or contradict the claim.

Pitfalls I have walked into on this exact path

The shortcuts that look smart on the 0xC00D1B90 symptom have a habit of biting back. The pitfalls below are the ones I have personally walked into on a Windows unit, not things I read about. Windows error codes come in a handful of families; once you recognise the family, the doc page is one search away. STOP codes look terrifying but the first DWORD almost always points directly at the responsible driver. DISM RestoreHealth needs network or a known-good source image; the most common cause of a failed RestoreHealth is a blocked Windows Update endpoint. When in doubt I revert to the slower path that the manual prescribes - the time I save by skipping it is always smaller than the time I spend cleaning up afterwards.

What I tell the next on-call

When I hand the 0xC00D1B90 symptom off to the next person on rotation, the three lines I leave in the runbook are these. First, the symptom signature for Windows on the Windows family - not a paraphrase, the exact string that surfaces. Second, the diagnostic that gave the highest signal in the least time. Third, the exact verification command whose green output justified closing the ticket. That trio is what turns a one-off fix into a runbook entry the next engineer can use without paging me at three in the morning.

I also add a one-line note on the cost of getting this wrong. For the 0xC00D1B90 symptom on a Windows unit, the cost is rarely the replacement part. It is the downtime, the second site visit, and the trust deficit you spend with whoever owns the asset when the fix does not hold. That framing keeps the next on-call from choosing the cheap-looking shortcut that ends up costing the most in elapsed hours and goodwill.