We are in exactly the same situation.

Evaluating System Recovery 8 (desktop edition + manager).

Only 4 systems in use. One of them is reporting this same problem.

I think the following elements may be a factor :

- version : the problematic system uses 8.0.3.28325 (live update to the latest) the others 8.0.2.26324 (trial version originally downloaded)

- presence of "Dell Utility partitions" : the system in question is a Dell system with 2 so-called utility partitions and when I manually create a recovery point on only the data partition, this works without an error. When I try to do the whole system (including these partitions), I too get this failure.

Since we are (not yet) a customer, the knowledge base and the support forums seem bo be the only way to go.

I'm not sure it is the utility partition. One of the users having the error does not have the utility partition on their system. I haven't been able to figure out any relation between the people that are receiving the error so far.

Can you confirm the versions you are using on your clients ?

On my test systems the DellUtility partitions (or 'unlinked' partitions) was a difference between systems.

The next one on my 'guess' list is differences in dotnet runtime versions.

The two systems that I know are getting that error are 8.0.3.28325. It seems all of the clients are using that 8.0.3.28325. Some of the systems run the backup while the user is using the system and others do it when nobody is using the system. I just checked the logs in event viewer from one of the systems that run when nobody is using it and I didn't seen anything in the logs about the com surrogate error. This one is also running 8.0.3.28325.

It is very possible about the  .net version differences. I'll have to double check the versions.

Thanks!

I have also checked the event log of my failing system. I found a couple of messages that seem to be relevant :

First I get

Event ID:1000 Category : (100)        Source : Application Error

Faulting application dllhost.exe, version 5.1.2600.2180, faulting module kernel32.dll, version 5.1.2600.3119, fault address 0x00012a5b.

Followed by

Event ID:4786 Category : Unknown    Source : COM+

The system has called a custom component and that component has failed and generated an exception. This indicates a problem with the custom component. Notify the developer of this component that a failure has occurred and provide them with the information below.
Component Prog ID:
Server Application ID: {67DFF6D9-E3BC-45B7-94C2-78C8A4D154AF}
Server Application Instance ID:
{91050BDB-B1D5-4756-BA23-209B388FFCFF}
Server Application Name: Symantec SymSnap VSS Provider
The serious nature of this error has caused the process to terminate.
Exception: E06D7363
Address: 0x7C812A5B
Call Stack:
kernel32!RaiseException + 0x52
SymSnapProviderXP! + 0x96788
SymSnapProviderXP! + 0xA8A0

Did you get anywhere with resolving this?

I tried to do the fixinstall.bat but that didn't seem to fix the problem. I can't find any similarities between the systems that error out and the ones that don't.

That error almost sounds like something didn't install correctly. 

Not yet.

The issue is that I (and the posters with a similar problem) are EVALUATING. So technical support is a ?

If someone who actually has this problem AND can get in touch with technical support would report the solution in this forum, then that would solve our problem.

In any case, I have recently learned that 8.5 is arriving. I still have about 45 days left on the evaluation. My management server is 8.2, I have 3 clients on 8.2 (no issues on them) and one client on 8.3 (COM Surrogate Error).

I am thinking about delaying until 8.5 is actually available and re-doing the tests with that release. Ok, granted, it will delay us making the final purchase with about 6 months but I am not going to approve on buying a backup solution that has this unresolved issue.

But per your suggestion, I will attempt a reinstall/repair installation and report my findings.

Hi, I am having the same problem. I do have a full registered version that used to work fine since yesterday. LiveUpdate made an update on my programs and ever since I do get this error message about the COM Surrogate having a problem at every backup. The backups are made nevertheless (hope they are fine... )

Version is 8.0.3.28325

Installation date says Sept. 30th 2008 (day of the LiveUpdate, original installation has been some months ago)

Problem details:

szAppName : dllhost.exe szAppVer : 5.1.2600.5512

szModName : kernel32.dll szModVer : 5.1.2600.5512 offset : 00012aeb

Grateful for any insight in this!

Symantec is still looking into this issue. Currently there is very limited number accounts on this issue. If you have this issue please contact Symantec technical support to begin an investigation. Use the recovery point browser to verify any images completed successfully when this error is generated even if verification is turned on in the backup; mock restores by using the conversion option to *.VMDK or *.VHD is also a good way to test the validity of images created when in doubt. If you have open a case please send me a note giving me the case number so that I can monitor the case. Thanks

David, nice to hear that Symantec Support is aware of this issue and tracking it.

I and other participants in this thread are currently EVALUATING BESR. Logging a support call is not possible for us.

Would you thus mind to share the information support has in this thread ?

Or have support contact us on this issue?

--------------------------------------------------------------------------------

Anyway,

I have been able to download the trial version of 8.5 and the above mentioned problem persists in that release. So upgrading to the latest and greatest version will not resolve this problem.

What I have been able to find out is that the problem is related to the SQL Server VSS Writer service that I have running in combination with an MSDE instance on this system via a service called SQL Server (SQLEXPRESS).

By elimination, I have managed to trigger the error by having the SQL Server VSS Writer service active.

If I stop it (and for good measure the MSDE database service), then I do not get the COM Surrogate failure.

BUT then I get a new error message in my eventlog from the VSS service stating the following :

Volume Shadow Copy Service error: Error calling a routine on the Shadow Copy Provider {262b716e-bb23-41b5-aaef-e2c15e767167}. Routine details IVssSnapshotProvider::IsVolumeSupported() failed with 0x800706ba [hr = 0x800706ba].

And my vssadmin gives problems with all writers :

C:\>vssadmin list writers
vssadmin 1.0 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001 Microsoft Corp.

Writer name: 'Microsoft Writer (Service State)'
Writer Id: {e38c2e3c-d4fb-4f4d-9550-fcafda8aae9a}
Writer Instance Id: {11e068f9-32f1-418e-a992-ac5e2ab5ee1e}
State: [7] Failed

Writer name: 'MSDEWriter'
Writer Id: {f8544ac1-0611-4fa5-b04b-f7ee00b03277}
Writer Instance Id: {ce7d93d1-4b04-45a8-a9e5-aead6c42c36c}
State: [7] Failed

Writer name: 'Microsoft Writer (Bootable State)'
Writer Id: {f2436e37-09f5-41af-9b2a-4ca2435dbfd5}
Writer Instance Id: {9de7903a-8ea1-47da-a4b9-4028be535137}
State: [7] Failed

Writer name: 'WMI Writer'
Writer Id: {a6ad56c2-b509-4e6c-bb19-49d8f43532f0}
Writer Instance Id: {f544b3bf-82b8-4b7f-9956-e1f11eb17af2}
State: [7] Failed

Writer name: 'IIS Metabase Writer'
Writer Id: {59b1f0cf-90ef-465f-9609-6ca8b2938366}
Writer Instance Id: {e059c01e-d280-4acd-ad8a-420c6e29c7bf}
State: [7] Failed

And No, before I stopped the SQL Server VSS Writer service, I had no errors here.

I can get it back to working order using MS KB Article 940184  ( http://support.microsoft.com/kb/940184 )

The backup itself completes with success. And no I have not validated the backup via a conversion to *.VMDK or *.VHD 

Is there anyone out there with this COM Surrogate Error that also has these services running ?

I get this error as well. It happened on v8 but not the previous installation. It was only when I moved to 8 the problems started. I have a fully licensed version on XP Pro (desktop Edition) to a Networked NAS. Just installed v8.5 this morning, same error. I used to use Norton Antivirus as well but there was too much grief between the two applications to persevere. Dropped the Antivirus for another brand and it worked a treat before V8. It still seems to work, the error message is just annoying.

Just thought, I have the Outlook 2007 Business Contact Manager add-on to Outlook 2007. This loaded SQL Server and it runs as a service in the background. Possible connection given Johandv post?

Currently the train of thought by support is that it has something to do with how our VSS provider, after the service makes a request to it, calls upon the writers.

Use the VSSADMIN LIST PROVIDERS command to see if the Symantec Provider is listed, be sure that the Symantec Synsnapservice and Provider services are listd in windows services. If they all are or are not, in a selective startup mode re-register our service: 

vssproviderinstall.exe -register "Symantec SymSnap VSS Provider" SymsnapProvider.dll "Symantec SymSnap VSS Provider" "Symantec SymSnap VSS Provider" If XP 32 then use SymsnapProviderXP.dll and if 64 bit OS then use SymsnapProviderx64.dll Please let me know what your collecive results are on this. Thanks

Hi, and thanks for the info.

I checked the vssadmin and the Symantec Provider is listed. Symantec Synsnapservice and Provider services are listed in Windows Services.

Re-registering in selective startup mode did not change the behavior. There's still the same message about the COM Surrogate.

 Check START | RUN | DCOMCNFG | COMPONENT SERVICES | COMPUTER | MY COMPUTER | COM+ APPLICATIONS

That the Symantec SymSnap VSS Provider is
 - Listed
 - That you can click on it without error.
 - That is contains the following Three main folders: Components, Legacy Components, Roles
 - That Components and Roles has content, can be clicked on without error, and the properites shows under security the "Role' administrators
 - That the Role shows the item Administrators and within it has Users and those are actual domain administrators.

Symantec SymSnap VSS Provider is listed, there are no errors on clicking.

All three main folders show up, Components and Roles do have content (2+1), no errors on clicking. Both components in the folder Components do have "Administrator" ín the Security tab.

"Administrators" is part of "Roles", two users are listed, both are administrators (this is not within a domain - so I don't know if "domain administrator" applies).

Is the account used to login to the system running the agent in the workgroup environment one of these adminnistrators listed? Is the same account used to login to the system the one that installed the product? Does any of these accounts have a local security policy restirctions inplaced; that is compared to the same admin account - I would guess- on a working client under the same account name? What is the state of the Microsoft VSS prodvider in window's services?

To follow-up on this those who are having this error, see if changing the 'log on' settings for our three services:

from the local system account to a specific admin account.

Thanks 

This is a one person workstation with the standard Windows Administrator account and a second administrator account (with standard rights - no changes have been made as fas as I remember) on my name. That account is used for login and also for all installations.

The system is a German one so some of the terms might differ. In the service panel I do not find "Microsoft VSS Provider" what I do find is:

MS Software Shadow Copy Provider  (Manuell) 

Volumeschattenkopie (Manuell)

The Symantec SymSnap VSS Provider shows "Status" as empty (not as "Started")

Moved all three to my administrator account. Restarted the services.

When I try to backup I get an error message:

-Fehler EBAB001A: An unknown exception has occurred at .\SmeCommon.cpp 548.

Will restart the computer and try again.

Do we get this error if you logged in as the standard Windows Administrator account then the 2nd user account on this system? If you changed BESR's three services to use the standard Windows Administrator account instead of SYSTEM, rebooted, does that make a difference? 

Login as standard Windows Admínistrator didn't change anything.

If I change the three services to use the standard Windows Administrator account instead of System I do get the errror

Fehler EBAB001A: An unknown exception has occurred at .\SmeCommon.cpp 548 

If the three services use System I do get the COM Surrogate error.

Going back to the services changing it back to using the Windows Administrator account, login using the Windows admin account again does changing the storage location (local vs. a network share or visa versa) make a difference? Does Windows disk management show any phantom drives that are no longer physically connected to the agent system and/or there drives reporting errors? Are there any iSCSI, SAN, NAS volumes connected to this system and/or are we backing up to such a storage location? Does Partinfo.exe (located in the Utilities sub-folder for the product) ran on this system reporting any errors on any volumes a backup job is scheduled for; does it show correctly when compared to the partitions listed in Windows Disk management?

Changing the storage location did not change anything. When the three services run on "Administrator" I get the same error EBAB001A. when they run on "System" I get the COM Surrogate.

No errors reported on the disks. No phantom drives. No iSCSI, SAN or NAS volumes.

Partinfo.exe does not report any errors, partitions are listed as in WDM.

I do run four local SATA hard drives. Two build a RAID system (mirror) (containing data) using an on board chip, one is for the operation system using a PCI-E SATA controller, one is just for excess data using an onboard SATA connector. All backups are made locally (Raid to OS harddisk and vice versa).

My symantec services were running as NT AUTHORITY\NetworkService. Changing them to local system did not resolve the issue.

Diskpart does not show anything wrong. There are no phantom drives visible. No iSCSI, SAN or NAS volumes.

When reviewing the DCOMCNFG, I can get to everything.

The users listed are only local administrators (no domain accounts).

I have not yet tried to re-register the Symantec SymSnap VSS Provider but this is still on my list of things to try.

On this system, the Symantec SymSnap VSS Provider (set to Automatic), stops after the DCOM error is raised.

Just removed Outlook 2007 business contact manager and the associated SQL installation from my XP Pro desktop. After removing using the uninstall you still need to go to the control panel and remove other SQL components (even though the business contact manager tells you it is uninstalling SQL). The COM surrogate error has gone.

I'm confused. So you can't have SQL installed to use System Recovery? Also, system recovery shouldn't conflict with a program like Business Contact Manager that needs to be installed for some people. I don't like that solution to just remove both.

It would appear that SQL 2005 server/express instance on a system running BESR 8.0x/8.5 is causing this error for a few of our customers. Has anyone had any luck having this error by turning off Data Execution Prevention on dllhost? Just curious? 

I did try that before.

No luck. Changing the DEP options did not resolve the issue.

Today I removed the SQL 2005 server express instance on the system where I have this problem. This also removed the microsoft SQL Server vss writer service.

I do not have the COM error after this action.

David,

Does Symantec have any reference on a conflict between BESR 8.0x/8.5 and SQL 2005 server/express ?

i.e. When does Symantec expect to fix this issue ?

It would seem that the interaction with SQL 2005 with BESR 8.0x/8.5 is the source of the COM Surrogate Error; what has reached dev so far has the following variables:

Windows event tirggers like "When user logs-On" is triggered to cause the backup and then the error.
The drive being backuped or the backup job is stored on a MD1000 drive.
That a external drive is chained to a PERC 6/e controller
That BESR 8.5 is a inplaced upgrade and the previous systems log files like (i.e. BESR log.txt has not removed ahead time).

Could I have those who are getting this error please send me a private note of the case number you have opened up, and/or report if indeed you are getting this error and have SQL 2005 installed or occuring under differnt environmental conditions.

I can tell you for sure that we aren't using when user logs-on triggers to do the backup. At least i'm not aware of that because it backs up while the user is logged on. We aren't using any sort of raid or md1000 drive either. We have ours backed up to a unc location that is a local sata drive on the server. I can confirm that we do have sql server 2005 express installed. I could be wrong but it seems that sql server 2005 developer is not erroring out. I know of one machine that has developer and I haven't seen any errors on that machine.

> Windows event tirggers like "When user logs-On" is triggered to cause the backup and then the error.

I have this error on both scheduled backups and "Run backup now" started from the BESR Manager.

> The drive being backuped or the backup job is stored on a MD1000 drive.

Not a factor. We store to a network share. That share is actually an iSCSI drive linked to a server.

> That a external drive is chained to a PERC 6/e controller

Not a factor. We store to a network share. That share is actually an iSCSI drive linked to a server.

> That BESR 8.5 is a inplaced upgrade and the previous systems log files like (i.e. BESR log.txt has not removed ahead time).

Not a factor. We had this issue on a 8.0.3 (new installation) and then on a 8.5 (inplace upgrade)

None of the variables quoted here seem to apply to my case.

I have 0 or NO support case numbers as I am only EVALUATING this product and thus am unable to create support cases.

I did have SQL Server 2005 (MSDE edition) installed on the system. Removing that database instance (and the associated VSS Writer) cleared the issue with BESR.

I agree with Johanvdv, it is nothing to do with hardware, local disk, NAS issues, what the trigger is for backup etc. It happened to me when you did a scheduled backup or a manual one. It is just an interaction with SQL (express in my case). Removing it (or BESR depending on which you value most) cures the problem.

Backups on my machine are only time-triggered and not event triggered. Error occurs also when I do start a Backup manually.

No MD1000 drive.

No external drive or PERC 6/e controller

I am running 8.03, not BESR 8.5

SQL 2005 is installed (with Outlook 2007)

Haven't filed a support case yet.

Johandv,

Do you have to stop both services (SQL Server VSS Writer & MSDE database service) to get rid of this error?

And is this an English version of Windows? If not, what locale is it?

Chris, see a previous response in this (lengthy) thread.

----------------------

If I stop it (and for good measure the MSDE database service), then I do not get the COM Surrogate failure.

BUT then I get a new error message in my eventlog from the VSS service stating the following :

Volume Shadow Copy Service error: Error calling a routine on the Shadow Copy Provider {262b716e-bb23-41b5-aaef-e2c15e767167}. Routine details IVssSnapshotProvider::IsVolumeSupported() failed with 0x800706ba [hr = 0x800706ba].

And my vssadmin gives problems with all writers :

C:\>vssadmin list writers
vssadmin 1.0 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001 Microsoft Corp.

Writer name: 'Microsoft Writer (Service State)'
Writer Id: {e38c2e3c-d4fb-4f4d-9550-fcafda8aae9a}
Writer Instance Id: {11e068f9-32f1-418e-a992-ac5e2ab5ee1e}
State: [7] Failed

Writer name: 'MSDEWriter'
Writer Id: {f8544ac1-0611-4fa5-b04b-f7ee00b03277}
Writer Instance Id: {ce7d93d1-4b04-45a8-a9e5-aead6c42c36c}
State: [7] Failed

Writer name: 'Microsoft Writer (Bootable State)'
Writer Id: {f2436e37-09f5-41af-9b2a-4ca2435dbfd5}
Writer Instance Id: {9de7903a-8ea1-47da-a4b9-4028be535137}
State: [7] Failed

Writer name: 'WMI Writer'
Writer Id: {a6ad56c2-b509-4e6c-bb19-49d8f43532f0}
Writer Instance Id: {f544b3bf-82b8-4b7f-9956-e1f11eb17af2}
State: [7] Failed

Writer name: 'IIS Metabase Writer'
Writer Id: {59b1f0cf-90ef-465f-9609-6ca8b2938366}
Writer Instance Id: {e059c01e-d280-4acd-ad8a-420c6e29c7bf}
State: [7] Failed

And No, before I stopped the SQL Server VSS Writer service, I had no errors here.

I can get it back to working order using MS KB Article 940184  ( http://support.microsoft.com/kb/940184 )

English - United Kingdom

-------------------------------------

As I have now deinstalled MSDE on that system, I have lost my 'test case'. In order to reproduce it, I will have to restore it (maybe to a VM) and repeat additional tests.

This is an English version of Windows XP - SP2. My locale is set to English-United Kingdom.

BTW : I have support on Backup Exec for Windows but NOT for BESR.  Would it actually be possible for Support to make an exception and open a support case although I am not stricly allowed to have support on this product ? I am just evaluating.

As a side note : This one system is a test system with MSDE on it. I have spotted multiple systems in our organisation with a similar setup ( e.g. a Vista Ult. system with Outlook 2007 and MSDE ). I would like to know how to 'resolve' this issue without having to remove all traces of MSDE and its depending applications from our systems.

I have been able to reproduce this problem here by just installing SQL Express 2005.

Despite the errors I see, the recovery point is successfully created; is this what everyone else is seeing?

I will post back here with any further updates on this issue.

Note; has anyone tried using the 'Perform full VSS backup' option to see if this helps (edit job, click on advanced button)?

I have one confirmed case where re-installing .NET Framework 2.0 package corrected this error those in a position who can do this please see if this corrects your instancee of this error and report back; thanks.

I encountered this error while attempting to use Norton Ghost 14 with latest updates in Windows XPPro SP# +latest updates. SQL Server 2005 Standard Version is installed and running.

In  my case, I attempted to use Norton Ghost v14 Disc Copy to make a copy of a partition onto a brand newly, larger SATAII  HDD.

The error occurred very early on in the process and I backtracked the System and Application Event Logs to find the initial report of an error.

The first error Event was Source: SQLWriter; EventID:8203;Description:"SQL Writer Error: Backup Type 5 not supported"

that was followed 2.5 mins later by:Application Error: Category:(100); EventID:1000; Description:"Faulting Application dllhost.exe, version 5.1.2600.5512, faulting module kernel32.dll, version 5.1.2600.5512, fault address 0x0012aeb.

That was followed quickly by the lengthy COM+ EventID: 4786 naming "Symantec SymSnap VSS Provider".

Then Ghost crashed.

Having read the earlier messages, I stopped the following Services:

    SQL Server VSS Writer 

and

    Volume Shadow Copy

With these two services stopped, Ghost then performed the desired disc copy flawlessly. Thankfully, scheduled incremental backups run overnight without incident.

I have preserved the event log in case anyone wants me to submit it. 

Sorry Folks, I omitted to add this little relevant fact: the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS\Settings has value 0x000000001 indicating that it is SQLServerWriter that is the default metadata enumerator (Microsoft article 919023 "SQL Server 2005 connectivity and Volume Shadow Copy Service" refers)

A further point:

In order to ensure that a Disc Copy using Ghost 14 is successful, it is necessary to stop both the SQL Server VS Writer and the Volume Shadow Copy services.

In addition, unless the Volume Shadow Copy service is then set to Disabled,  it is most likely to restart after any Source Volume Checking has been completed.

Do remember to reset the properties of the  Volume Shadow Copy service back to Automatic before you next reboot.  Otherwise, Norton Internet Security may become disabled because it seems to depend on the Volume Shadow Copy service.

Thanks for that input Ajmore. At this time the work around that we have seen to work is just disabling the writer and not the shadow copy component; do others have a similar event where they have to disable both. In all instances that this error occurs appears to be with Windows XP and SQL, are others having this error on a different OS?

I'm getting this error:

Volume Shadow Copy Service error: Error calling a routine on the Shadow Copy Provider {262b716e-bb23-41b5-aaef-e2c15e767167}. Routine details IVssSnapshotProvider::IsVolumeSupported() failed with 0x800706ba [hr = 0x800706ba].

on two Win2k3 servers running BESR 8.0.3.

Only one of the two servers *also* has BEWS 12.0 running with a SQL 2005 Express database, and BEWS is throwing a lot of errors too.

Therefore -- I have only read the last 2 pages of this thread -- if this VSS error occurs on servers with and without SQL Express 2005, and on a server without SQL Express 2005, only BESR, obviously BESR is the cause.

BESR and BEWS do not work well in that BESR makes a lot of changes to the VSS services, which in turn messes up BEWS.

Hi! Same error here after installing BESR 8.5.0.28843 (over 7.x). Yes, SQL 2005 (MSDE) is also installed. Errors appear after starting backup job (to external USB drive, I'm not sure about alternative).

First appear in log error

(1) "Event Source: SQLWRITER -- Event ID: 8203 -- Description: SQL writer error: Backup type 5 not supported.", then

(2) "Event Source: Application Error -- Event ID: 1000 -- Description: Faulting application dllhost.exe, version 5.1.2600.2180, faulting module kernel32.dll, version 5.1.2600.3119, fault address 0x00012a5b." and then

(3) "Event Source: COM+ -- Event ID: 4786 -- Description: The system has called a custom component and that component has failed and generated an exception. This indicates a problem with the custom component. Notify the developer of this component that a failure has occurred and provide them with the information below. ".

Just before installing BESR I renewed .Net install to 3.5 SP1. I'm not sure this is relevent.

Yes, seems to that backup job is despite this done ... OK!

Any solution? ... please let us know!
Alar.

Hi again!

Just for records -- with (latest) version 8.5.1.29666 same problem.

Alar.

I have the same problem on my test machine, just for clarity can somebody please post the current fix / workaround.   Many suggestions have been made but I would like to know what is the tried and tested recommendation until a hotfix is released. 

Symantec  - Any idea on when this may be?  I to am trialing and looking to roll out to my fleet but really need this issue sorted beforehand.

I too have the same issue with Windows XP/SP2,SQL 2005, and BESR 8.0.3.28325 installed. Identical 3 errors in the Event Logs when the backup is done. An update or workaround fix is needed.

This TechNote documents this issue and the current workaround:

http://support.veritas.com/docs/311809

Is it not the case that this problem applies also to Norton Ghost v14 and Norton Save and Restore v2?

If so, then please adjust the technnical note to include these products.

Thanks

For Norton Ghost v14  and for Norton Save&Restore v2, if the Advanced Option "Perform Full VSS Backup" is selected would that overcome the COM Surrogate Error problem and avoid the need to Stop and Disable the Volume Shadow Copy Service and the SQL Server VSS Writer Serivce?

Please advise thanks.

We have the same problem, i installed BESR and updatet it with Liveupdate to V8.5.3.31483 on a WinXPPro SP3 we are running a Microsoft Sql2005 Server on this maschine, i tryed all of your solutions (exept uninstalling or stoping the sql server because our shop system is running on it...) but none of them fixed the problem...

Are there any other solutions to fix the problem?

We just discovered this problem, too, on 2009.06.10
Will any fix be forthcoming?
Last forum post dated "8 weeks 2 days ago" (mid-April 2009?).
Last update on workaround is over 6 months old:
http://seer.entsupport.symantec.com/docs/311809.htm (no update since December 15 2008 09:30 PM)
Are we stuck?

A new installation of Ghost 14 was reporting the COM Surrogate error shortly after starting a disk backup.  Backup would appear to proceed, but the PC would freeze about a minute after the message appeared, still in the "Calculating time..." phase.

I followed the support instructions for the workaround - 1) disable SQL Server VSS backup and 2) configure COM security permissions.  Now I don't get the "COM Surrogate..." error, and the backup reports getting into the copy data phase, but it still freezes the PC shortly after starting.

Phone support could not help. Anyone have any insight?

thanks,

Next week (Wed or Thurs), BESR will have an update to 8.5.5. There is a COM surrogate bug resolved in this service pack. If you are a BESR user, upgrade to 8.5.5 then via LiveUpdate. If you still experience the error afterwards, you will want to contact technical support and open a case, so it can get escalated appropriately if necessary.

If you are a Ghost user, I am not sure of the timeline when this is resolved in that. I hope to find out and post that information soon. 

Maybe symantec employees could update their knowledgebase articles ?

http://support.veritas.com/docs/311809

This document does not contain any reference to the 8.5.5 fix.

According to another article 8.5.4 already seems to contain this fix.

http://support.veritas.com/docs/326876

I subscribed to this thread some time ago and to the knowledgebase article but I never got an email regarding the last post.

Johanvdv,

I've updated that article. The new version should be available soon.