BUG: CmdExec May Cause Exception Violation on Scheduled Tasks

• Microsoft SQL Server, version 6.5

SYMPTOMS

Scheduled tasks of type CmdExec may cause an exception violation. A message similar to the following will appear in the Event Viewer:

   EventID: 212
   Source: SQLExecutive
   User: N/A
   Type: Error
   Category: Task Engine

   Task <task no>, '<task name>' has caused an exception violation in the
   CmdExec subsystem, and has been terminated.

CAUSE

This behavior is a result of a problem with the CmdExec utility. While running, Cmdexec.dll creates a temporary file that holds the redirected stdio and stderr output for the task. If the number of bytes within this file happens to be within certain ranges, an exception violation is generated.

WORKAROUND

To work around this problem, adjust the size of the output written to stdio and stderr by the CmdExec task being scheduled. If you are unsure about what output is being generated, try running the task at a command prompt and observing the results written to the screen. Increase or reduce the number of bytes written by at least two bytes to avoid exposure to this problem.

STATUS

Microsoft has confirmed this to be a problem in Microsoft SQL Server version 6.5. We are researching this problem and will post new information here in the Microsoft Knowledge Base as it becomes available.

MORE INFORMATION

The nature of this problem is such that there is only a small chance that a given CmdExec task will be affected.

An example would be if you scheduled SQLMaint to perform routine database maintenance and noticed that the database maintenance report shows successful completion but the task reports failure in the Task Manager screen in SQL Enterprise Manager.

Because the output produced is saved to the report (.rpt) file, there is no need to run this from the command prompt to view the stdio and stderr listings. An example of a SQLMaint report file is shown below.

By reviewing this output, you can decide on the most appropriate means of causing the byte-count to be increased or reduced by at least two (for example, by changing the dump file name in paragraph 7 or by ensuring that the database is in single user mode so that the WARNING in paragraph 2 is suppressed).

The following is a sample SQLMaint report:

Microsoft (R) SQLMaint Utility, Version 6.50.240 Copyright (C) Microsoft Corporation, 1995 - 1996

Logged on to SQL Server 'MYSERVER' as 'sa' (trusted) Starting maintenance of database 'pubs' on Wed Jul 09 13:28:32 1997

[1] Check Data and Index Linkage...

    ** Execution Time: 0 hrs, 0 mins, 3 secs **

    WARNING: Database pubs is currently being used by 4 user(s).
             This may cause spurious problems to be reported.

    ** Execution Time: 0 hrs, 0 mins, 2 secs **

    ** Execution Time: 0 hrs, 0 mins, 1 secs **

    ** Execution Time: 0 hrs, 0 mins, 1 secs **

    ** Execution Time: 0 hrs, 0 mins, 27 secs **

    Rebuilding indexes for table 'authors'
    Rebuilding indexes for table 'discounts'
    Rebuilding indexes for table 'employee'
    Rebuilding indexes for table 'pub_info'
    Rebuilding indexes for table 'publishers'
    Rebuilding indexes for table 'roysched'
    Rebuilding indexes for table 'sales'
    Rebuilding indexes for table 'stores'
    Rebuilding indexes for table 'testing'
    Rebuilding indexes for table 'titleauthor'
    Rebuilding indexes for table 'titles'

    ** Execution Time: 0 hrs, 0 mins, 7 secs **

    Destination: 'D:\MSSQL\BACKUP\pubs_db_dump.199707091329'

    ** Execution Time: 0 hrs, 0 mins, 4 secs **

    0 file(s) deleted.

SQLMAINT.EXE Process Exit Code: 0 (Success)