Lync: VideoWindows of AVModality.VideoChannel are null after successfully calling BeginStart (COMException HRESULT: 0x80029C4A TYPE_E_CANTLOADLIBRARY)

We are currently trying to incorporate Lync communication (Lync SDK 2010) into our application and we have run into an issue with the VideoWindows (CaptureVideoWindow, RenderVideoWindow) of the AVModality's VideoChannel: They are always null, even after successfully calling BeginStart. The connection is definitely established. We can talk. Our own video is shown in a remote Lync client. AVModalityState is Connected. VideoChannelState goes from Connecting to Receive to Send.

It does not matter when and how we try to access them: Directly after BeginStart, in the AsyncCallback of BeginStart, in response to various state changes or in response to an external trigger (user click event); in the main/UI thread or in an event/callback thread. The two video windows are always null.

In the example application "%PROGRAMFILES%\Microsoft Lync\SDK\Samples\AudioVideoConversation", everything works as intended: As soon as BeginStart has finished, we can access the non-null video windows. In our little stand-alone prototype project, it works, too. But in our real application, it does not.

We have double checked everything and we have really run out of ideas of what might cause this problem.

Any ideas, any hints? Anything that we should be aware of?

(Link to corresponding MSDN forum thread)

Update (4th July 2012, 15:46 CET):

When we take a look at the members of the VideoChannel we find that internally a COMException occured in "Microsoft.Office.Uc": Error loading DLL, HRESULT: 0x80029C4A (TYPE_E_CANTLOADLIBRARY). More details in the attached screenshot.

We did some research on this error, but found nothing that worked for us. Any ideas what causes the Exception?

Update (9th July 2012, 16:43 CET):

We did some further testing...

Our software consists of one main application and many plugin-like "apps" loaded via MEF. We created a minimal test app that makes a video call: The video windows did not work (as expected). But when we took the identical code and created a separate solution outside of our architecture, then it did work. So, it was an issue with the environment, not the code.

At first, we suspected MEF might be the problem. So, we hacked the lync code into our main application - circumventing the whole app architecture. Still not working.

Then we sliced off our whole system, bit by bit, until we finally reached a point where it did work. After following wrong tracks several times, we finally found the culprit... Quartz.NET!

For some strange reason the mere presence of an assembly reference to the Quartz.dll v.1.0.3.3, even without a single line of Quartz code, causes the video windows to not work. Unbelievable, but it's 100% reproducible: If we take the previously mentioned test solution and do nothing but add the reference, it stops working.

Any idea how such a thing is possible?

We solved it! Kind of. A reference to a Quartz.NET DLL somehow caused the issue. More details in the updated question.

For now, we have removed the component that used Quartz. We currently do not need it.

But I'm still interested in further input how a mere reference can cause such an issue.