Troubleshooting Sync Framework
This topic lists solutions to the following common problems that can occur when you are using Sync Framework:
Installing Sync Framework 2.0 Does Not Upgrade a Previously Installed Version
Managed Application Throws System.Runtime.InteropServices.COMException (0x80040154)
Managed Application Throws System.Runtime.InteropServices.COMException (0x80004002)
Stack Information Is Incorrect When You Are Debugging on the 64-bit Version of the Windows Operating System
Sync Framework Repeatedly Calls GetChangeBatch in an Infinite Loop
For more troubleshooting help for problems that are not listed here, see the Sync Framework developer center. For information about Sync Framework support for the Event Tracing for Windows (ETW) infrastructure, see Tracing Sync Framework Components.
Installing Sync Framework 2.0 Does Not Upgrade a Previously Installed Version
When Sync Framework 2.0 is installed, it does not remove or upgrade any previously installed CTP versions of Sync Framework.
Solution
Uninstall all CTP versions of Sync Framework 2.0 before you install the final release version. Sync Framework 2.0 can be installed side-by-side with Sync Framework 1.0.
Managed Application Throws System.Runtime.InteropServices.COMException (0x80040154)
A managed synchronization application throws System.Runtime.InteropServices.COMException with the following error message: "Retrieving the COM class factory for component with CLSID {565AEDBF-3108-4405-AF1F-9C2C25925DAE} failed due to the following error: 80040154."
This exception occurs when an unmanaged synchronization component, such as Synchronization.dll, is missing from the installation. This can occur when Sync Framework has been uninstalled or when installation was not completed successfully.
Solution
Reinstall Sync Framework. Sync Framework can be downloaded from this Microsoft Web site.
Managed Application Throws System.Runtime.InteropServices.COMException (0x80004002)
A managed synchronization application throws System.Runtime.InteropServices.COMException with the following error message: "Unable to cast COM object of type 'Sync Framework Managed Class' to interface type 'Sync Framework COM Interop Class'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{73EA794F-1251-4466-A19C-DAEAF5BDBD04}' failed due to the following error: No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE))."
This exception occurs when a Sync Framework object is created in one single-threaded apartment and a method of the object is called from a different single-threaded apartment. In this case, the .NET Framework tries to marshal the Sync Framework object from one apartment to the other by querying the Sync Framework object for the IMarshal interface. Sync Framework objects do not implement IMarshal and so the call fails with this exception.
Solution
Use multithreaded apartment (MTA) threads. Marshaling is not required for MTA threads.
Stack Information Is Incorrect When You Are Debugging on the 64-bit Version of the Windows Operating System
On the 64-bit version of the Windows operating system, stack information is lost and shows incorrectly in the debugger.
This problem occurs when a managed component throws an exception that transitions to an unmanaged component, and then this unmanaged component throws the exception back to a managed component. In this case, the .NET Framework does not correctly preserve stack information on the 64-bit version of the Windows operating system. Because the managed components of Sync Framework wrap unmanaged components by using the COM interop feature of the .NET Framework, when certain managed components throw exceptions, this scenario occurs.
A specific example of this problem is a managed synchronization application that is producing a FeedSync feed. The managed application implements a FeedIdConverter method that throws an exception. The exception is thrown to the underlying unmanaged component of Sync Framework and then back to the managed application code. At this point, the stack trace in the debugger will not correctly show the origin of the exception.
Solution
Because stack information cannot be correctly preserved in this case, you have to use another debugging strategy, such as throwing a custom exception so that the origin of the exception can be determined by the kind of the exception alone.
Sync Framework Repeatedly Calls GetChangeBatch in an Infinite Loop
During synchronization, Sync Framework repeatedly calls GetChangeBatch (for managed code) or IKnowledgeSyncProvider::GetChangeBatch (for unmanaged code) until it receives a change batch that returns true from IsLastBatch (for managed code) or TRUE from ISyncChangeBatchBase::GetIsLastBatch (for unmanaged code).
Solution
Before the provider returns the last change batch, it must use SetLastBatch (for managed code) or ISyncChangeBatchBase::SetLastBatch (for unmanaged code) to mark the batch as the last batch.