When your scheduled task fails with error code 0xc000013a on Windows Server 2003, it indicates the script received a CTRL+C signal despite no physical interaction. This typically occurs due to:

• Third-party applications intercepting console events
• System-level process monitoring tools
• Unhandled exceptions in .NET applications (if your script launches any)

In your case where the .cmd script works manually but fails via Task Scheduler, we're likely dealing with environment differences. The Task Scheduler environment often lacks:

@echo off
REM This works interactively but may fail as scheduled task
sqlcmd -S YOURSERVER -Q "EXEC sp_YourStoredProcedure"
if %ERRORLEVEL% neq 0 (
    echo SQL Command failed >> C:\logs\error.log
    exit /b 1
)
ftp -s:upload_script.txt ftp.yourserver.com

Here's an enhanced version that handles the silent termination:

@echo off
SETLOCAL ENABLEEXTENSIONS
SET LOGFILE=C:\logs\proc_%DATE:~-4,4%%DATE:~-10,2%%DATE:~-7,2%.log

REM Trap CTRL+C
if "%1"=="SUBROUTINE" goto %2

:MAIN
start "" /MIN /B cmd /c "%~f0" SUBROUTINE RUNSCRIPT
exit /b

:RUNSCRIPT
(
    echo [%TIME%] Starting database export
    sqlcmd -S YOURSERVER -Q "EXEC sp_YourStoredProcedure" -o "%LOGFILE%"
    if %ERRORLEVEL% neq 0 (
        echo [%TIME%] SQL Error occurred >> "%LOGFILE%"
        exit /b 1
    )
    
    echo [%TIME%] Starting FTP transfer
    ftp -v -n -s:"C:\scripts\upload_script.txt" ftp.yourserver.com >> "%LOGFILE%" 2>&1
) >> "%LOGFILE%" 2>&1

if %ERRORLEVEL% equ 0 (
    echo [%TIME%] Process completed successfully >> "%LOGFILE%"
) else (
    echo [%TIME%] Process failed with error %ERRORLEVEL% >> "%LOGFILE%"
)

Configure your scheduled task with these critical settings:

• Run with highest privileges (even for simple scripts)
• Set "Start in" directory to your script location
• Select "Run whether user is logged on or not"
• Configure for Windows Server 2003 compatibility if available

For more reliable execution, consider this PowerShell wrapper:

try {
    $process = Start-Process -FilePath "cmd.exe" 
                -ArgumentList "/c C:\scripts\yourscript.cmd" 
                -NoNewWindow -Wait 
                -PassThru -ErrorAction Stop
    
    if ($process.ExitCode -ne 0) {
        throw "Script failed with exit code $($process.ExitCode)"
    }
    
    Write-Output "Execution completed successfully at $(Get-Date)"
} catch {
    Write-Error $_.Exception.Message
    exit 1
}

When troubleshooting:

1. First capture environment variables from both contexts:

REM In scheduled task
set > C:\env_scheduled.txt

REM In interactive session
set > C:\env_interactive.txt

2. Compare PATH variables and critical dependencies
3. Check for missing network drives or UNC paths
4. Verify service account permissions

When your Windows scheduled task fails with error 0xC000013A while running perfectly fine manually, you're likely encountering a .NET runtime initialization issue masquerading as a manual termination. The Microsoft documentation mentioning CTRL+C is misleading in this context - we're actually dealing with a CLR (Common Language Runtime) loading failure.

The error occurs when:

1. The task executes under SYSTEM/LocalService accounts
2. Required .NET Framework components are missing/corrupt
3. Environment variables aren't properly inherited
4. DLL loading fails silently

First, modify your script to capture the actual error:

@echo off
set LOG=C:\TaskLogs\sql_ftp_%DATE:~-4%%DATE:~-7,2%%DATE:~-10,2%.log

:: Redirect all output
call :main >> "%LOG%" 2>&1
goto :eof

:main
echo [%TIME%] Starting SQL extraction
"C:\Program Files\YourApp\DataExtractor.exe" config.xml

if %ERRORLEVEL% NEQ 0 (
    echo ERROR: Extraction failed with code %ERRORLEVEL%
    exit /b %ERRORLEVEL%
)

echo [%TIME%] Starting FTP upload
"C:\Utils\psftp.exe" -bc -batch ftp.example.com -l user -pw pass -m commands.scp

Try these solutions in order:

1. Set "Start in" directory in task properties to your script's location
2. Add .NET framework directory to PATH in the task's environment:
   PATH=%PATH%;C:\Windows\Microsoft.NET\Framework\v2.0.50727
3. Explicitly load CLR in your script:
   SET DEVPATH=C:\YourApp\Dependencies
4. Configure task to run whether user is logged on or not

When basic logging isn't enough, use ProcMon to catch DLL loading failures:

1. Download Process Monitor from Microsoft
2. Set filter: Process Name is "cmd.exe" OR "YourApp.exe"
3. Run the scheduled task
4. Look for "NAME NOT FOUND" in DLL searches

Sometimes wrapping the operation in PowerShell helps surface the real error:

try {
    $process = Start-Process "C:\Program Files\YourApp\DataExtractor.exe" 
        -ArgumentList "config.xml" 
        -NoNewWindow 
        -Wait 
        -PassThru
    
    if ($process.ExitCode -ne 0) {
        throw "Process failed with code $($process.ExitCode)"
    }
    
    & "C:\Utils\psftp.exe" -bc -batch ftp.example.com -l user -pw pass -m commands.scp
}
catch {
    $errMsg = $_.Exception.Message
    "[$(Get-Date)] ERROR: $errMsg" | Out-File "C:\TaskLogs\errors.log" -Append
    exit 1
}

After implementing fixes, test with:

schtasks /run /tn "YourTaskName"
waitfor /t 300 SignalName
type C:\TaskLogs\sql_ftp_*.log