Q:

sp_MSforeachdb Continue on failure when running DBCC CHECKDB

I have the following maintenance script
DECLARE @sql NVARCHAR(30) = 'DBCC CHECKDB(?)'
EXEC sp_MSforeachdb @sql

This checks every database for corruption. I have run this on my test server where I deliberately corrupted a database and as expected, the DBCC CHECKDB errors for that database, however, this then ends the script, so all the other databases that haven't yet been checked go unchecked.
Is there a way I can make the script continue on error so that the remaining databases get checked?
I have also tried Aaron Bertrand's sp_foreachdb and found the behaviour to be the same
1: https://www.mssqltips.com/sqlservertip/2201/making-a-more-reliable-and-flexible-spmsforeachdb/ as well as Ola.Hallengren's SQL Server Integrity Check using the command DatabaseIntegrityCheck @Databases =  'ALL_DATABASES' which again gives the same behaviour
I have noticed management studio shows "Disconnected" at the bottom also

A:

Since I can't in good conscious provide a solution that is undocumented, unsupported, and likely to skip databases, using my replacement, try adding TRY/CATCH:
EXEC master.dbo.sp_foreachdb 
  @command = N'
    BEGIN TRY
      DBCC CHECKDB(?) WITH NO_INFOMSGS, ALL_ERRORMSGS;
    END TRY
    BEGIN CATCH
      PRINT ''? failed.'';
    END CATCH';

Depending on the severity of the error, though, it's possible that it will sever the connection. The above works if you set two databases offline and then add the parameter @state_desc (required since naturally the procedure skips offline databases):
ALTER DATABASE db1 SET OFFLINE WITH ROLLBACK IMMEDIATE;
ALTER DATABASE db2 SET OFFLINE WITH ROLLBACK IMMEDIATE;
GO

EXEC master.dbo.sp_foreachdb 
  @command = N'
    BEGIN TRY
      DBCC CHECKDB(?) WITH NO_INFOMSGS, ALL_ERRORMSGS;
    END TRY
    BEGIN CATCH
      PRINT ''? failed.'';
    END CATCH',
  @state_desc = N'OFFLINE';

Output:
db1 failed.
db2 failed.

If TRY/CATCH still fails in your scenario, you might either want to stop what you're doing and deal with that issue directly before proceeding with "all's ok" checks on the other databases or, at least once you've identified a database with an issue, bypass it altogether using the @exclude_list parameter added in the First Responders Kit:

SQL-Server-First-Responder-Kit/sp_foreachdb.sql

A:

I know this is an old post, but I'm adding this answer in case someone comes across it. The most likely cause is that the error is so severe (it has a severity of 20 or higher, most likely 22, 23 or 24) that the actual connection has been terminated and the application disconnected. This occurs with any of the For Each DB options mentioned in the question and other answers, and in Ola's script. 
One solution is to use PowerShell to run the integrity checks for you. Create a script that fetches the list of databases (using Invoke-SqlCmd for example) then use a foreach loop to iterate over the DBs and run the integrity check.
As each iteration will establish a new connection, any failure shouldn't affect the remaining DBs. You will need to output the SQL errors from Invoke-SqlCmd and within the foreach loop use a try-catch block to gracefully handle the terminating error from SQL Server before continuing to the next database.
I've tested the below PowerShell script against a deliberately corrupted DB causing error sev 23 and it works fine. You can also use Ola's script against individual databases for increased flexibility by replacing the value in the second Invoke-SqlCmd's Query parameter.
$Databases = Invoke-SqlCmd -ServerInstance SERVERNAME -Database master -Query "SELECT [name] AS [Database] FROM sys.databases ORDER BY 1 DESC;"

foreach ($DB in $Databases)
{
    Write-Output "Processing $($DB.Database)..."
    try
    {
        Invoke-SqlCmd -ServerInstance SERVERNAME -Database master -Query "DBCC CHECKDB ([$($DB.Database)]);" -OutputSqlErrors:$true -Verbose
    }
    catch
    {
        Write-Output "Error encountered: $($_.Exception.Message)"
    }
}

Write-Output "Complete."

