Crime
An application which builds a DirectShow graph unexpectedly started failing with VFW_E_NOT_CONNECTED (0x80040209) error code.
Scene
The problem takes place during DirectShow graph building, yet in stopped state. Specific call which appeared to be giving out the error in first place appears to be EVR input pin’s IPin::ConnectionMediaType, and the problem is also specific to Enhanced video Renderer (Windows 7, but not necessarily only this version).
Investigation
The problem does not appear to be persistent. On the contrary, it is taking place for just a few milliseconds after pin connection. After the problem is gone, it does not seem to ever come up again unless the filter graph is built again from the beginning.
EVR pin connection is always reporting success, so the following error code stating VFW_E_NOT_CONNECTED “The operation cannot be performed because the pins are not connected.” goes against documented behavior, and is thus a bug.
Depending on time between pin connection and media type polling, the call can reach EVR:
- before it starts showing the problem – stage A
- at the time the call fails – stage B
- after the failure time interval, when the call is successful from then on – stage C
Thus, the problem is limited to specific use cases:
- the application should care about media type on EVR input
- unexpected failure takes place when the call reaches in stage B
- also found: the clipping window for the EVR has to belong to a non-primary monitor
If an application keep polling for media type in a loop, the result may be about the following:
UINT nStageA = 0, nStageB = 0, nStageC = 0;
// [...]
for(; ; )
{
AM_MEDIA_TYPE MediaType;
ZeroMemory(&MediaType, sizeof MediaType);
const HRESULT nConnectionMediaTypeResult = pInputPin->ConnectionMediaType(&MediaType);
if(SUCCEEDED(nConnectionMediaTypeResult))
{
if(nStageB)
{
nStageC++;
break;
} else
nStageA++;
} else
{
ATLASSERT(nConnectionMediaTypeResult == VFW_E_NOT_CONNECTED);
nStageB++;
}
CoTaskMemFree(MediaType.pbFormat);
}
// [...]
CString sMessage;
sMessage.Format(_T("Bingo!\r\n\r\n") _T("nStageA %d, nStageB %d - 0x%08x, nStageC %d\n"), nStageA, nStageB, nResult, nStageC);
AtlMessageBox(m_hWnd, (LPCTSTR) sMessage, _T("Result"), MB_ICONERROR);
Workaround
An obvious straightforward workaround is to follow EVR connection with a wait for Stage B to pass, or timeout – whichever takes place first.
Also, vote for the bug on Microsoft Connect.
More Details
Video renderer filter are notorious for re-agreeing media type and being fretful as for memory allocators and media types (for a good reason though!). So it makes sense to suggest that the problem takes place when the filter is doing something related, such as it starts background activity immediately after connection in order to discover upstream peer capabilities.
In order to possibly get details on this, it is possible to raise an exception as soon as Stage B is detected and take a look at thread states using a debugger. Indeed, on of the background threads is engaged in EVR reconnection activity:
Yes it does the reconnection, but nevertheless it is expected to do the things undercover and transparently, it still allows a failure on the outer API.
   evr.dll!GetSourceRectFromMediaType() + 0x37 bytes   Â
    evr.dll!CEVRInputPin::CheckMediaType() + 0x81 bytes   Â
    evr.dll!CBasePin::ReceiveConnection() + 0x61 bytes   Â
    evr.dll!CEVRInputPin::ReceiveConnection() + 0x1fc2d bytes   Â
    quartz.dll!CBasePin::AttemptConnection() - 0x21 bytes   Â
    quartz.dll!CBasePin::TryMediaTypes() + 0x60 bytes   Â
    quartz.dll!CBasePin::AgreeMediaType() + 0x54 bytes   Â
    quartz.dll!CBasePin::Connect() + 0x46 bytes   Â
    quartz.dll!CFilterGraph::ConnectDirectInternal() + 0x83 bytes   Â
    quartz.dll!CFilterGraph::ConnectRecursively() + 0x2c bytes   Â
    quartz.dll!CFilterGraph::ConnectInternal() + 0xde bytes   Â
    quartz.dll!CFilterGraph::Connect() + 0x17 bytes   Â
    quartz.dll!CFGControl::WorkerDisplayChanged() + 0xf1 bytes   Â
    quartz.dll!CFGControl::CGraphWindow::OnReceiveMessage() + 0x2e2a bytes   Â
>    quartz.dll!WndProc() + 0x3e bytes   Â
    user32.dll!_InternalCallWinProc@20() + 0x23 bytes   Â
    user32.dll!_UserCallWinProcCheckWow@32() + 0xb7 bytes   Â
    user32.dll!_DispatchMessageWorker@8() + 0xed bytes   Â
    user32.dll!_DispatchMessageW@4() + 0xf bytes   Â
    quartz.dll!ObjectThread() + 0x65 bytes
A test Visual C++ .NET 2010 application is available from SVN. The code requires a media file, and refers to 352×288 I420.avi, which is included into ZIP file attached to MS Connect Feedback.
