Mobsync Issues

After today’s encounter with Mobsync and COM+, I am left scratching my head and looking about in disarray. This doesn’t happen often, but I am sure glad when it does because it beats sitting in a lecture hall ‘attempting’ to learn about the intricacies of Windows communication subsystems.

It all started when I received a call yesterday from one of my clients. She couldn’t access her network drives. Of course, the client doesn’t actually say this; more commonly I hear much more detailed descriptions like, “Micah, the Internet is broken” or “my icon disappeared.” So I set up an appointment for this morning.

From the way she described the issue, she couldn’t access some network resources. She could still get her email from the Exchange server as well as access the Internet. Her mapped drives wouldn’t open, however. She received this error message when trying to open them:

O:\ is not accessible. The parameter is incorrect.

When navigating in Windows Explorer through Entire Network -> Microsoft Windows Network -> Domain, I received the following message: (replace ‘Network’ with the domain name)

Network is not accessible. You might not have permission to use this network resource. Contact the administrator of this server to find out if you have access permissions. The parameter is incorrect.

Stranger yet, when trying to open the UNC path from the Run dialog box, the classic “The network path was not found” message appears.

This was the only user/PC on this subnet who experienced this issue. Just to rule out the network as a possible cause, I cleared the DNS cache (ipconfig/flushdns) and the ARP table (arp -d *). I pinged the file server by name and the server responded without issue. I checked the ARP and DNS tables and saw that the IP address and name resolved correctly. There aren’t any extra entries in the hosts file and the DNS server is dynamically set via DHCP to the server–the same as every workstation in the network.

These are the errors seen in the Application event log:

Source: Userenv; Type: Error; Event ID: 1030; Description: Windows cannot query for the list of Group Policy objects. A message that describes the reason for this was previously logged by the policy engine.

Source: EventSystem; Type: Warning; Event ID: 4356; Description: The COM+ Event System failed to create an instance of the subscriber partition: {…}. CoGetObject returned HRESULT 8000401A.

Event ID 4356 seems to give the most details. The GUID {41E90F3E-56C1-4633-81C3-6E8BAC8BDD70} belongs to COM Event Subsystem. The second GUID {6295DF2D-35EE-11D1-8707-00C04FD93327} belongs to Mobsync, the Microsoft Synchronization Manager, a component of Internet Explorer used for offline file synchronization. HRESULT 8000401A means that there is not a domain controller to which a connection may be made.

I spent several hours exhausting many options in resolving this issue. I upgraded from XP SP2 to SP3, IE6 to IE8, and ran all the latest updates, thinking that mobsync would be updated along the way and the issue resolved. This wasn’t the case, however. I even installed Hotfix KB885887, to no avail.

Recent Note: Nowadays I would take a more targeted approach to troubleshooting issues. I wasted a lot of time in this scenario “blindly guessing.” But, this was five years ago and I was still new to IT.

In Component Services within Administrative Tools in the Control Panel, I drilled down to the Mobsync component and set the security settings in the properties dialog box to their defaults as well, but like all the rest of my attempts at saving the day, it failed.

After this, I thought that perhaps the COM+ catalog became corrupt. Per this article, I logged into safe mode and backed up the clbcatq.dll file in the System32 folder and removed the contents of the %windir%\Registration folder. Then I deleted the registry key HKLM\Software\Microsoft\COM3 and restarted the computer. After restarting, I removed the Registration folder altogether and opened the Add/Remove Windows Components setup program. Simply click Next caused COM+ to be reinstalled. While the network drives were accessible at this time, the problem came back as soon as I restarted the computer again.

Since I had already made it to four and a half hours at this point, I decided to follow the advice of this page and unregister mobsync.dll from the COM+ Event System by running regsvr32 "%systemroot%\system32\mobsync.dll" /u. While the network drives were accessible once again at this point, the issue wasn’t truly resolved. After all, I heard that if this component is not available, data corruption may occur if the PC belongs to a domain (like this one.) Luckily, there are Shadow Copies and tape backups, just in case something does go awry.

If I am wrong in thinking that there is an issue with mobsync, then I may need to re-evaluate the network and check for any issues that may exist between the server and the PC by using a sniffer utility.

Update 4 June 2010

Despite mobsync being deregistered, the issue reoccurred. The only error messages found in the event log on the PC were related to Group Policy not being applied. I used the network sniffer application that comes with Windows Server 2003 and recorded all traffic going to and from the PC from the time the PC was turned on until the user had logged in and reached the desktop. Everything seemed to be just fine except for several error messages seen in the SMB frames from the server to the PC regarding invalid arguments.

All in all, the final solution was to blow away the user’s profile and start fresh. The issue hasn’t reoccurred since. Additionally, another recording of the network traffic going to and from that PC showed no SMB errors any longer. The root cause is profile-specific and likely resulted from a corrupt user registry hive.