NS_S_WMR_PINTYPEFULLMATCH (0X000D1061) — What It Means & Fix

What Actually Triggers This Error

You're building a DirectShow filter graph — maybe in a custom C++ app, maybe using GraphEdit or GraphStudioNext. You try to connect an output pin (say, from a source filter like a file reader) to an input pin (like the WM ASF Writer or the Windows Media Video encoder). The connection fails, and you get back NS_S_WMR_PINTYPEFULLMATCH (0x000D1061), which the header wmsdkidl.h defines as "The specified type fully matches this pin type."

This error is a warning, not a hard failure — it's telling you the pin types already match exactly. But because DirectShow treats it as a success-with-warning, your app might stop building the graph prematurely, or the filter refuses to connect because it thinks there's nothing to do.

Root Cause in Plain English

What's actually happening here is that the filter you're trying to connect to has already been configured to accept a specific media type. The WM ASF Writer, for example, internally sets its input pin's media type as soon as you give it a profile or a bitrate setting. When you then try to call IGraphBuilder::Connect with a different pin, the source pin's type matches exactly what the filter already expects — so the filter returns NS_S_WMR_PINTYPEFULLMATCH to say "I already have this type, no need to renegotiate."

The real problem isn't the match — it's that the filter graph builder might abort the connection attempt or skip subsequent pins because it interprets the return code as an error. Some older DirectShow implementations also fail to propagate the success code correctly, leaving your graph in a half-built state.

I've seen this most often in two scenarios:

• You're trying to connect the WM ASF Writer's input pin after you've already called SetProfile or SetOutputSetting on it.
• You're reconnecting a pin that was already connected to the same filter earlier in the session.

How to Fix It

The fix depends on whether you're writing code or using a GUI tool like GraphStudioNext. I'll cover both.

If You're Writing Code (C++ / .NET)

The key insight: connect the pins before you set any filter-specific configuration. The WM ASF Writer (and similar Windows Media Format SDK filters) lock their pin types once you apply a profile or output settings. Don't fight that — work with it.

1. Create the filter graph in the correct order: Add the source filter (e.g., File Source (Async) or a custom source), then add the WM ASF Writer. Do not call SetProfile on the writer yet.

2. Connect the output pin of the source to the input pin of the writer: Use IGraphBuilder::Connect directly. This triggers media type negotiation before the writer locks its types.

   hr = pGraph->Connect(pSourceOut, pWriterIn, NULL);
   if (SUCCEEDED(hr)) {
       // Connection succeeded — now configure the writer
       CComQIPtr<IWMProfileManager> pWMProfileMgr;
       // ... set profile here
   }

3. Then configure the writer: Call SetProfile, SetOutputSetting, etc. At this point, the pin types are already established, so the writer won't choke.

4. If you must reconnect later: Disconnect both pins explicitly using IFilterGraph::Disconnect on each pin (not just one), then remove the writer filter from the graph and re-add it. The internal state is sticky otherwise.

If You're Using GraphStudioNext (or GraphEdit)

1. Don't set the output file or profile on the WM ASF Writer before connecting pins. Drag the writer into the graph, then connect the source pin to its input pin first. Only after the connection line appears should you right-click the writer and set the output file name or profile.

2. If the error still shows up: Delete the writer filter entirely, add a fresh one, and connect again — but this time, use "Connect Direct" (Ctrl+D) instead of "Connect" (Ctrl+F). The direct connection skips the intelligent graph builder's pin-matching logic, which sometimes misinterprets the warning.

3. Alternative filter chain: If the WM ASF Writer keeps fighting you, try inserting an intermediate filter like the "Infinite Pin Tee" or "Smart Tee" between the source and the writer. It breaks the direct pin-to-pin type matching that triggers the warning. Not elegant, but works.

What to Check If It Still Fails

If you've reordered the connections and the error persists, here's what's usually hiding:

• Stale filter state: The writer filter might still hold a reference to an old profile from a previous graph. Kill the process completely and start fresh.
• Wrong media subtype: Your source pin might be outputting a format the writer doesn't expect — like RGB video instead of YUV, or PCM audio instead of WMA. Check the actual media type with IPin::QueryPinInfo or GraphStudioNext's pin info dialog.
• 32-bit vs 64-bit mismatch: If your app is 32-bit but the DirectShow filters are 64-bit (or vice versa), you'll get weird HRESULTs. This one triggers a different error usually, but I've seen it surface as NS_S_WMR_PINTYPEFULLMATCH when the media format type structures don't align.
• Windows version quirks: On Windows 10 and 11, the WM ASF Writer filter (part of Windows Media Format SDK) has been deprecated. Microsoft recommends using Media Foundation instead. If you're building new software, skip DirectShow entirely and use IMFSourceReader or Sink Writer. It'll save you days of pin-matching headaches.

Finally, if you're stuck in legacy code and can't change frameworks, you can suppress the warning by checking for NS_S_WMR_PINTYPEFULLMATCH specifically in your HRESULT handler and treating it as S_OK — but that's a band-aid, not a cure. The real fix is fixing the connection order.