Backup Exec 2012 End Marker Unreadable VIRTUAL Tapes

There may be a hotfix now, as of last month. Not sure if it applies to VTL

http://www.symantec.com/connect/forums/end-marker-unreadable-error-and-compression-tape-backup-exec-2012-fixed

http://www.symantec.com/business/support/index?page=content&id=tech189571

I previously installed the hotfixes, service packs, live updates, etc.

Check the logs and see if the job engine stops during the time when the backup is running. Also, did this problem start right after you upgraded?

Also make sure that the iSCSI path is optimal. Disabling RSS and TOE on Windows 2003 may help if not done already. The "end marker unreadable" can happen when communication between Backup Exec and the library is suddenly interrupted. Job engine or Device and Media service crashes can be a problem as rbarnhardt mentioned, but also network communication could be a problem.
I know it worked in BE12, but you're not saying if this BE2012 is running on the same server with the same OS instance as BE12.

How do I disable RSS and TOE?  BE2012 is running on the same server with the same OS and the same iSCSI connection to my VTL.

http://support.microsoft.com/kb/948496 describes how to prevent problems with RSS and TOE. Method 3 indicates how to disable RSS and TOE from the registry.

I disabled both RSS and TOE.  That did not solve the issue.  I am still getting "end marker unreadable" indicated on my virtual tape slots.  
Any other suggestions?
I'm willing to try anything at this point.
Thanks again.

Have you checked the event logs for "Application Crash" events as rbarnhardt suggested?
Do the Backup Exec jobs that use these virtual tapes fail? Any indication of something going wrong in the Job Logs?

Come on this is Symantec, of course there are errors!  
Here are the three most common:

Backup Exec Alert: Job Failed
(Server: "Servername") (Job: "servername.domain.comBackup -Full") Backup -Full -- The job failed with the following error: Unable to attach to a resource.  Make sure that all selected resources exist and are online, and then try again.  If the server or resource no longer exists, remove it from the selection list. Edit the selection list properties, click the View Selection Details tab, and then remove the resource.
 
Backup Exec Alert: Job Failed
(Server: "Servername") (Job: "Servername.comain.com Backup -Full") servername.domain.com Backup -Full -- The job failed with the following error: The Backup Exec job engine system service is not responding.
 
This error is the most perplexing.

Update to catalog index (Catalog index database) failed.
Reason:  C:\Program Files\Symantec\Backup Exec\Catalogs\server\ PerformBulkInsert()
r:\honshu\1798r.i386\becat\catindex\dll\..\catdbupdatethread.cpp(499)
 
Not sure about r:\honshu\1798r.i386\becat\catindex\dll\..\catdbupdatethread.cpp(499)

There are no drive mappings to r:\ on the media server.

The second one - the Job engine problem - is probably causing the end marker problem, as rbarnhardt pointed out earlier.
No "application error" event 1000 in the event logs at the same time. They may give a clue.

Symantec have some open issues with bengine.exe
http://www.symantec.com/docs/TECH192301 
http://www.symantec.com/docs/TECH189932 

Make sure to run liveupdate to get all the latest updates.

The root cause could be loads of things. Backup Exec, the network between server and VTL or the library.
If really nothing changed apart from the version of Backup Exec, I would tell the Symantec 1st-line support guys to escalate to their 2nd level and then their backline engineers. Ask for a duty manager if you're not getting anywhere.

In the meantime make sure your network drivers are fully up to date, make sure the Overland firmware is fully up to date, check that there's no speed/duplex mismatches between NICs and network switch ports, etc.

I would also exclude bengine.exe from antivirus scanning.


You'll probably also have to enable Backup Exec debug logs - this will show you exactly what the last thing is the Job Engine service does before becoming unresponsive.


The r: drive thing is not that perplexing. The r: drive refers to the drive on a symantec system, where they probably keep their cpp (c++) source code.

And yes - I have seen Backup Exec systems that are completely free of errors :-)

None of the answers provided solved my issue.