I'm having the same problem!

Faulting application beremote.exe, version 13.0.2896.0, time stamp 0x4b184ba1, faulting module vixDiskLib.dll, version 3.1.0.396, time stamp 0x4af097b5, exception code 0xc0000005

My issue was with access to the san.  I had forgotten to disable automount with diskpart, then tell MS iSCSI to connect to the san for each LUN.  After getting the access to the SAN fixed, no more error.  Hope this helps!

NorDoc,

FYI, don't know if its related, but I had to break my selection list up and was running them concurrently and got a similar problem (beremote crashes).  I get the same communications error.  Here is the application log entry:

Log Name:      Application
Source:        Application Error
Date:          3/8/2010 4:52:31 PM
Event ID:      1000
Task Category: (100)
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      MediaServer
Description:
Faulting application beremote.exe, version 13.0.2896.0, time stamp 0x4b184ba1, faulting module ntdll.dll, version 6.0.6002.18005, time stamp 0x49e0421d, exception code 0xc0000374, fault offset 0x00000000000aef37, process id 0xf98, application start time 0x01cabef07ad7eb52.

Another item I ran across in my research indicated that Symantec was aware of an issue with Beremote.exe crashing when backing up file data from a 2008 R2 server with Exchange 2010 installed.  Here is the url: 

http://seer.entsupport.symantec.com/docs/337862.htm 

I'm about to break down and call in for support, I upgraded my small production environment and this is an issue for me.

RW

I have the same issue here. Testing BUE 2010 on 5 VMs before putting into production. This is the only issue that's keeping me from moving forward. I have a case open with support, waiting for the "technician" to contact me.

I'll update this thread with any progress I may have.

 Any update on this issue?

No update yet. I spent my hour on the initial support call on Friday... my case was escalated and now I wait for advanced support to contact me.

Nothing new to tell today. Had my call with Adv Support this morning. They stated that they have seen this issue reported by others and are "researching". My case has been escalated to Backline support. I'm currently waiting for the RAWS to crash again so I can send some logs to support and contact them again.

@Dongxian... thanks for the input, but that is not in my equation. I don't have any VMs with independent disks.

Adv. Support did give me a registry modification yesterday and I'm running some more backups to test it out. Since the issue is so sporadic, I'll be running tests for the whole week to see how it does before I am satisfied that it has resolved the problem.

Well, my RAWS service just crashed on my media server again, so the mod did not help. I'd rather wait until my issue is fixed before posting anything here.

I have the same issue. Exact same error in the event log :)

I have a support contract so I might ring up and log a job just to get it some extra support. And the more they know about it the more likely we are to get it fixed.

I'll update this thread with any details I get.

I have this issue also, we're running Server 2003/Exchange 2003

I performed a test run prior to upgrading the agent from 12.5 and all seemed fine.

Also the other backups ran ok yesterday, (file backups) but they all failed today reporting communication errors with the agents (though they are still running). It seems the problem is more deep rooted.

I went through the pain of registering an account here just to share my findings with you guys..

I just installed BE 2010 on a new backup server running Windows 2008 R2 Standard and started configuring it.
I ran some test jobs which all worked fine (one on a Linux VM and one on a Windows 2000 VM). So I configured the primary backup job and set it to run. It immediately failed! So i searched around a bit and ended up here. Not much help, though.. Although it got me thinking in what I think might be the correct direction.

The test VMs that I did a dry run on had only one vdisk each, and none of them was in independent mode..
So i checked how the first VM in the primary job was configured, and sure enough, it has an independent disk attached.
So i tried moving two other VMs up to the top of the resource order and rescheduled the job again. Sure enough, it happily backed up the two machines before it again failed on the same one that had the independent disk...

So, my suggestion is that it might be some incorrect handling of independent disks in BE that causes it to crash (of course, they should't be affected by a snapshot, but then again, BE shouldn't crash just because of it either ) . Just switch of the independent disks and the backup should come through ok..

Hope this helps..

Thanks for the info, magnus... but, my jobs fail sporadically with just one VM in each of the selection lists being backed up and none of my VMs have independent disks.

I'm patiently waiting for Adv. Support to get back to me. My case has been passed to another engineer.

I just noticed the two posts mentioning that, sorry :-/

it was too easy to be true. Well, in that case I also eagerly await the answer from the symantec support... :-)

My Ticket has been escalated to Adv Tech support and I am currently waiting for them to get back to me.

There is now a tech note for this issue:
http://seer.entsupport.symantec.com/docs/347150.htm

I've been told that engineering is now involved in working on this issue.

Has anyone tried "Backup Exec 2010 for Windows Servers revision 2896 Hotfix 344584" to see if this helps.  I just skimmed it and it looks like it addresses quite a few issues.

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

I installed this, side note: download the hotfix, I was getting an error using LiveUpdate, during the install of the downloaded hotfix it will ask for the installation CD.

This may not be the same issue with your live update, but I've noticed that if I try to run live update from a RDP session it fails/breaks live update.  Then if I go to the actual server console it will also fail there.  The only way I've found (so far) to fix it was to run a repair install of BE.  There is probably an easier way to fix it; I've just been preoccupied with the access rights issues as well see below.  Our hosts are vmware vsphere 4 esxi hosts.

V-79-57344-38277 - Unable to open a disk of the virtual machine.

VixDiskLib_Open() reported the error: You do not have access rights to this file
V-79-57344-38277 - Unable to open a disk of the virtual machine.

OK found an easier way to fix my issue with live update:  run BEUpdateOps.exe then rerun live update.

Live update fails with error - LU1805: LiveUpdate was unable to find any products to Update
Solution URL:  http://seer.entsupport.symantec.com/docs/316846.htm

Another Hotfix release for anyone monitoring this thread.  Hotfix 348284

http://seer.entsupport.symantec.com/docs/348284.htm

Im having the same problem to when backing up vmdk's

I getting this randomly Job ended: 10 June 2010 at 20:19:50 Completed status: Failed Final error: 0xe0009578 - Unable to copy the virtual machine disk using the VMware VixDiskLib. Final error category: Resource Errors

Does any body know a fix I have all the latest updated on backup exec 2010 ?

I think backup 12.5 was alot better to be honest 2010 shoudnt of been released its way to buggy !

Any help would be great

cheers

I've given up on BUexec 2010 for VM backups. I went with Veeam Backup and I am 100% satisfied with it.

Here's how I fixed mine

V-79-57344-38277 - Unable to open a disk of the virtual machine.

How does that help? I went down this path and found that pushing RAWS to the remote machine uninstalls the VMware VSS provider anyway.

I know this thread is old and this isn't the answer, but:

Like nbernhart, I gave up on BE for our VM backup solution and went with Veeam.  We still use BE though but now we just use it for Enterprise Vault and to transfer the Veeam backup to Tape.

RW

The issue is still happening, seemingly randomly to me... 

Some nights our backups run perfectly, but then others, they almost all fail.  Strange, as I am not making any settings changes from one day to the next...