The error was while running the store procedure runs xp_cmdshell to run a batch file

Error code 5 from CreateProcess means the Windows account under which xp_cmdshell is running does not have sufficient permissions for what it is trying to do (starting cmd.exe, accessing the batch file, or accessing some folder/file used by the batch file).

Key points from the context:

• xp_cmdshell runs under the security context of the SQL Server service account, unless a proxy account is configured.
• The Windows process spawned by xp_cmdshell has exactly the same rights as the SQL Server service account.

Given that even EXEC xp_cmdshell 'whoami' fails with CreateProcess error 5, the failure occurs before the command itself runs, so focus on the account that xp_cmdshell is using and its ability to start cmd.exe.

Use the following steps:

1. Confirm which account xp_cmdshell is using
   • If the caller is a member of sysadmin, xp_cmdshell runs as the SQL Server service account for that instance.
   • If the caller is not sysadmin, xp_cmdshell uses the credential ##xp_cmdshell_proxy_account## (if configured). If this credential is missing, xp_cmdshell fails.
   • Run a test as a sysadmin login to eliminate proxy issues:

          EXEC xp_cmdshell 'whoami';
     

     If this still fails with error 5, the SQL Server service account itself cannot start cmd.exe.
2. Verify xp_cmdshell is enabled
   • Ensure xp_cmdshell is enabled via sp_configure or Policy-Based Management. If it is disabled, enabling it is required before any command can run.
3. Check the SQL Server service account permissions
   • Identify the exact service account for the instance where xp_cmdshell is being executed (for example, NT SERVICE\MSSQL$ECOM_SQLEXPRESS or NT SERVICE\MSSQLSERVER).
   • Ensure this account has:
     • Read and execute permission on C:\Windows\System32\cmd.exe (and the system directory where cmd.exe resides).
     • Read/execute/list permissions on the folder path and file F:\ECLOUD_DB_Script\CreateDB.bat.
     • Any additional file/folder permissions required by commands inside CreateDB.bat (for example, database file locations, log folders, or network shares).
4. Test with a minimal command
   • After verifying permissions, test again as sysadmin:

          EXEC xp_cmdshell 'whoami';
     

   • If this succeeds, then test:

          EXEC xp_cmdshell 'dir F:\ECLOUD_DB_Script';
          EXEC xp_cmdshell 'F:\ECLOUD_DB_Script\CreateDB.bat';
     

   • If whoami works but the batch file fails, the issue is with permissions required by the batch file contents or its target locations.
5. Consider using an xp_cmdshell proxy account
   • If the SQL Server service account is intentionally restricted, configure a proxy credential with the required rights:

          EXEC sp_xp_cmdshell_proxy_account 'DOMAIN\\UserWithRights', '<StrongPassword>';
     

   • Then run xp_cmdshell from a non-sysadmin login that uses this proxy. The Windows process will run under the proxy account, which must have the necessary file, folder, and cmd.exe permissions.
6. Re-test after any change
   • After adjusting permissions or configuring a proxy, restart the SQL Server service if service account or local security policy changes were made, then re-run the minimal whoami test and proceed to the batch file.

If error 5 persists even when running xp_cmdshell 'whoami' as sysadmin and after confirming cmd.exe and folder permissions, the next step is to inspect OS-level security policies (for example, Software Restriction Policies or additional endpoint security) that may be blocking process creation for the SQL Server service account.

References:

• xp_cmdshell (Transact-SQL)
• KB2671318 - FIX: The first execution of the xp_cmdshell stored procedure is not completed until the last execution is complete in SQL Server 2012