SQBCoreService.exe v 6.4.0.56 Crashes

dcrawforddcrawford Posts: 8
edited March 24, 2011 9:57AM in SQL Backup Previous Versions
The Backup Agent Service is crashing for me consistently on a new install of version 6.4.0.56. I have gotten backups and restores to work a few times but it fails more than succeeds. The error from the event log is below -- this running on Windows Server 2008 R2 Enterprise, SQL Server 2008 R2. Any help with troubleshooting this is appreciated.



Faulting application name: SQBCoreService.exe, version: 6.4.0.56, time stamp: 0x2a425e19
Faulting module name: inetmib1.dll_unloaded, version: 0.0.0.0, time stamp: 0x4a5bda0b
Exception code: 0xc0000005
Fault offset: 0x61407cd6
Faulting process id: 0x2634
Faulting application start time: 0x01cbe58104c47c8e
Faulting application path: E:\Program Files (x86)\Red Gate\SQL Backup 6\(LOCAL)\SQBCoreService.exe
Faulting module path: inetmib1.dll
Report Id: 4f3c660d-5174-11e0-8a23-e41f13c55f50

Comments

  • Brian DonahueBrian Donahue Posts: 6,590 Bronze 1
    We have had a few problems with inetmib1 in the SQBCoreService process and there is a patch that should prevent that:

    ftp://support.red-gate.com/Patches/sql_ ... 0_1014.zip

    That archive contains the SQL Backup Agent executable file (SQBCoreService.exe) and command line interface executable file (SQLBackupC.exe). To replace the existing SQL Backup Agent, do the following:

    - ensure that no SQL Backup processes are running
    - stop the SQL Backup Agent service, or cluster resource if on a cluster
    - rename the existing executable file
    - extract and place the patched SQL Backup Agent executable file into the same folder
    - restart the SQL Backup Agent service/cluster resource

    Let me know if the crashing error still occurs.
  • Thanks Brian.

    That appears to have corrected the service from crashing however I have a restore process running that is just spinning now without any progress.

    It appears that the db files were created on the server so the SQB is definitely being read, but it doesn't appear to actually be processing any of the data in the file. The restore has been running for over two hours, I am not seeing any disk activity and the GUI is showing 0B processed. Any additional help you can provide is appreciated.
  • Brian DonahueBrian Donahue Posts: 6,590 Bronze 1
    No idea. You could try turning on SQL Server backup/restore event tracing - that may reveal that the SQL Server is stuck writing a checkpoint or something.

    http://www.red-gate.com/supportcenter/C ... L%20Backup

    I doubt it's SQL Backup as problems with the service tend to time out and/or throw errors at you like crazy.
  • I have attempted to trace the backup but it is not providing any additional info. Once it logs that it is transferring data it stops completely (see below). I ended up stopping the service in order to stop the ghost restore process. There are a few additional symptoms that I am able to report now as well.

    1.) I have been able to restore a native backup to and from the same locations.
    2.) I am able to restore a Redgate backup that is local on the server. The problem appears to be somehow network related but is not manifested in native restores.
    3.) I am not sure if this item is related or not but we did have problems with the initial installation of Redgate's server components (and have duplicated the install issue on another server we are standing up). We ended up installing via the command line install.

    03/21/2011 15:55:33,spid64,Unknown,Restore: Transferring data to TestDB
    03/21/2011 15:55:33,spid64,Unknown,Restore: Restoring backup set
    03/21/2011 15:55:33,spid64,Unknown,Restore: Containers are ready
    03/21/2011 15:55:33,spid64,Unknown,Zeroing completed on I:\mssql\data\TestDB.mdf
    03/21/2011 15:45:59,spid64,Unknown,Zeroing completed on Y:\mssql\log\TestDB_log.ldf
    03/21/2011 15:41:42,spid64,Unknown,Zeroing Y:\mssql\log\TestDB_log.ldf from page 1 to 5361577 (0x2000 to 0xa39f52000)
    03/21/2011 15:41:42,spid64,Unknown,Zeroing I:\mssql\data\TestDB.mdf from page 1 to 16864384 (0x2000 to 0x202a900000)
    03/21/2011 15:41:42,spid64,Unknown,Restore: PreparingContainers
    03/21/2011 15:41:42,spid64,Unknown,Restore: Attached database TestDB as DBID=5
    03/21/2011 15:41:42,spid64,Unknown,Restore: BeginRestore (offline) on TestDB
    03/21/2011 15:41:42,spid64,Unknown,Restore: Planning complete
    03/21/2011 15:41:42,spid64,Unknown,Restore: Planning begins
    03/21/2011 15:41:42,spid64,Unknown,Restore: Backup set is open
    03/21/2011 15:41:42,spid64,Unknown,Restore: Configuration section loaded
    03/21/2011 15:41:42,spid64,Unknown,Opening backup set
    03/21/2011 15:41:42,spid64,Unknown,RestoreDatabase: Database TestDB
    03/21/2011 15:40:46,spid64,Unknown,Restore: Configuration section loaded
    03/21/2011 15:39:42,spid54,Unknown,DBCC TRACEON 3605<c/> server process ID (SPID) 54. This is an informational message only; no user action is required.
    03/21/2011 15:39:42,spid54,Unknown,DBCC TRACEON 3004<c/> server process ID (SPID) 54. This is an informational message only; no user action is required.
  • I am trying to troubleshoot the install issue on the other server (maybe it is related to this thread) and am wondering is SQL 2008 R2 Enterprise running on Windows Server 2008 R2 Enterprise supported? I don't see any reference to SQL 2008 R2 in the documentation. Maybe that is why I am having problems with server components?
  • Brian DonahueBrian Donahue Posts: 6,590 Bronze 1
    SQL Backup 6.4 supports SQL Server 2008 R2. Can you locate the SQL Backup log from the activity history in the SQL Backup Console and post that up as well?
  • There is no record of the backup attempt in the activity history.
  • Looks like we are getting there. I was able to restore a very small database successfully however am now attempting a midsized db restore and getting a Preemptive_OS_GetProcAddress wait type on the restore command. After 20 minutes it has processed 0 Bytes. From what I am reading this might be a bug in SQL related to executing extended stored procs. Do you know if there is a fix for this?
  • Brian DonahueBrian Donahue Posts: 6,590 Bronze 1
    Again, no idea. The extended stored procedure only relays commands to the SQL Backup Agent Service and relays the output back to SQL Server. The wait type is some OS resource wait. The only wait type I have ever see is MSSQL_XP. The only system resources it uses are mutexes and memory-mapped files. It must be waiting for one of these resources. Typically there is a timeout associated with all of these objects so it would not sit there waiting forever.
  • Thanks again Brian. I have been working in parallel paths and think I have found the problem -- it was related to our SAN (hence the preemtive mode which didn't appear to ever resolve). I am now able to backup and restore without any problems. I appreciate all of your help, time, and patience.
Sign In or Register to comment.