cancel
Showing results for 
Search instead for 
Did you mean: 

DLO crash C++ Runtime Library error

Ivan_P
Level 4

Many of our DLO clients are crashing with the following errors:

Runtime Error!

Program C:\Program Files\Symantec\Backup Exec\DLO\DLOCLientu.exe

Application log errors:

Faulting application dloclientu.exe, version 3.1.330.1601, faulting module dloclientu.exe, version 3.1.330.1601, fault address 0x0013045f. or Faulting application dloclientu.exe, version 3.1.330.1601, faulting module dloclientu.exe, version 3.1.330.1601, fault address 0x00130bfd.

We are running the latest version of DLO, our BE DLO media server is running SP2, with the latest hotfixes. We've been running DLO for 6 months, this error just started popping up 2 weeks ago. It happens to random DLO users throughout the day. The error also occurs when the computers are locked and idle(there should be no backup running)

I have tried uninstalling/reinstalling DLO, .net framework 2.0 sp1, XP sp2, removed and/or disabled Mcafee Virusscan. Any ideas? Thanks.

12 REPLIES 12

Michel_J
Level 2
I have the same problem. This started a few weeks ago.
Although we are running it on Win 2003 64. Clients keeps constantly crashing at random.

Ivan_P
Level 4
I've opened a ticket with Symantec support and I will post my findings once I hear back from support. They are currently reviewing the DLO crash dump files.

Michel_J
Level 2
Hi there,
 
Could you keep me posted on the result. I would greatly appreciate it :)
 
Thanks,
 
Michel J

Toni_Eini_
Level 3
Anything new yet?
 
We have same problem. Users are confused and we get lot of calls to helpdesk.
 
Toni

Ivan_P
Level 4
I've had a ticket open with Symantec support for almost 30 days and still nothing.
I keep sending them error logs and dump files but they have not been able to fix the problem. Very frustrating for our help desk since we get calls daily about the error.

Ivan_P
Level 4
My ticket was escalated to the top level engineer in the DLO group and they could not offer an explanation to the error. The only solution was to try BE 12d.
We tried it on 2 test computers and the error has not occurred. So we have to upgrade to BE 12 in order to fix this issue.

Ramon_Br_lisaue
Level 3

Hi there

 

We use Symantec Backup Exec 11d with DLO Desktop Agent 3.1.3 latest service packs and hotfixes and we got those Runtime Errors too.

I found out, that the error always occurs just after a file has been copied to the NUDF while the DLO Desktop Agent is grooming the file. It does not matter whether delta-file transfer is enabled or not. And it does not matter whether revisions are enabled or not.

 

The error message is: R6025: Pure virtual function call.

 

If I google for this error, i find evidence that this error is known since Backup Exec 6!

5 major releases and still not fixed...

 

@Ivan Plachuta:

Do you think updating to BE 12 could solve it?

Did Symantec offer you a free upgrade to BE 12?

 

Message Edited by Ramon Brülisauer on 02-25-2009 04:10 AM

Ivan_P
Level 4

Ramon,

We upgraded to from 11d to v12 and the C++ error went away. However, after about 8 months of running v12 with all of the updates, random users started receiving the C++ R6025: Pure virtual function call error message. Some of the users DLO crashes at every startup and some are random. The users who crash at startup have no backup. The users who crash at random time do run backups.

 

I've contacted Symantec support and the ticket has been open for about 2 months. To date, no solution has been found. Here are the troubleshooting steps that we've taken:

A temp fix for the R6025: Pure virtual function call error message is:

1 - Delete the contents of the .Settings folder on the client computer.

The path is C:\documents and Settings\username\Local Settings\Application Data\Symantec\DLO\.settings

2 - Rename the computer name on the network storage location

3 - Restart the DLO client and run a full backup again

This has fixed quite a few users but a few have called back with the same error. The problem with this fix is a full backup needs to run again since the old backup folder is renamed.

 

Here are some DLO server changes that we made and the results:

 

Fix 1 - We changed the DLO Maintenance service account from Local System to a Domain Admin account.

Results: The C++ Runtime error went away for all users. However, the following errors were logged for many users in their backup history:

The DLO maintenance server(servername) is unavailable to groom file \\servername\ path….. (a security specific error occurred.)

Fix 2 - We changed the DLO Maintenance service account to a regular user accounts with admin rights to the DLO server.

Results: Same results as Fix 1 above.

Fix 3 - Assign delegate permissions to the server and change the DLO maintenance service back to the Local System account.

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

See Section: Confirm that the Server Process Account is Trusted for Delegation

Results: The clients still receive random C++ errors.

The DLO maintenance server(servername) is unavailable to groom file \\servername\ path….. (a security specific error occurred.) error went away on the server.

I do see the following error on our DLO server: Restorer::GenerateDeltaMergeList - missing baseline. <filepath> - Symantec has no solution for this yet.

 

We are still getting calls to our Help Desk about the C++ R6025: Pure virtual function call. This is very frustrating as users are still complaining, some backups are not running and we've upgraded to v12. I believe that this is a server/security  issue due to the fact that when the DLO maintenance service is change the C++ R6025 erorr goes away, but other errors - maintenance errors are generated.

Symantec support is still working on this issue. I will post a message when a solution is found.

 

Message Edited by Ivan Plachuta on 02-25-2009 06:28 AM
Message Edited by Ivan Plachuta on 02-25-2009 06:30 AM

Ramon_Br_lisaue
Level 3

Dear Ivan

 

Thanks for your reply.

 

It doesn't sound good... I've got exactly the same behavior than you.

 

The errors mostly occur at random, but we also have some machines where it's a permanent error.

We contacted the Symantec Enterprise Support in August 2008... as far as I know the case has been closed without providing a solution (I didn't receive anything since October 2008).

 

The workarounds you described above all work... but the error returns after a few days or weeks (depends on the machine).

 

Fix 1

We first ran the DLO Maintenance Service under a Domain Admin Account. But we received the grooming errors as well as the R6025 runtime error. The Ent-Support told us to run it under LocalSystem. We did as proposed. But no success, no matter under which account the Maintenance Service is running we still got those errors.

 

Fix 2

What do you refer as "regular user account"? Do you mean a local user on the server with administrative permissions? Or do you mean a domain user with adminstrative rights on the server but no Domain Admin? We must use a domain user, our corporate IT policy demands it. But I think it would result in the same behavior than fix 1.

 

Fix 3

We've assigned the delegate permissions to the server and runned the Maintenance Service under LocalSystem. Result: We still have grooming errors as well as R6025 runtime errors. But our Event Log does not show the Restorer::GenerateDeltaMergeList Event.

 

I also tried to fix the MDAC using Tomas Paulas solution, but no success. MDAC 2.81 is installed, but I'm still getting the R6025 runtime error.

(see https://forums.symantec.com/syment/board/message?board.id=be12_dlo&thread.id=45)

 

It is as you said: Very frustrating...

I'll post a message too when a solution is found.

 

Best regards

 

Ramon Brülisauer

 

Message Edited by Ramon Brülisauer on 02-25-2009 08:55 AM
Message Edited by Ramon Brülisauer on 02-25-2009 06:05 PM

Ivan_P
Level 4

Ramon,

 

Fix 2

What do you refer as "regular user account"? Do you mean a local user on the server with administrative permissions? - No

Or do you mean a domain user with adminstrative rights on the server but no Domain Admin? - Yes, a domain user account with admin rights to just the DLO server.

Message Edited by Ivan Plachuta on 02-25-2009 09:01 AM

Ramon_Br_lisaue
Level 3

Hi Ivan

 

Thanks for the clarification. As I expected... a local user won't make sense.

 

Best regards

 

Ramon

Ivan_P
Level 4

Ramon,

How many clients do you have backing up to a single storage group?

Thanks