the issue is with an eventID 1, Source=SQLVDI. it appears that the scheduled backups 'may' be the root cause of the SQL error "Limit on 'Max worker threads' reached" which prevents further client connections.
there are approx 129 databases on a 32bit win2003R2 SP2.

we are trying to determine if SQLVDI is used solely by the native SQL server backup, ntbackup or even any 3rd party backup that does not used a SQL agent ans is image based.

we also have received feedback with the following as possible solutions:

1. stagger the backups by splitting them up into multiple jobs. though this approach is not feasible as we ontinue to add databases to the Sql Server and the maintnance of the staggering process will be difficult to keep track of.
2. move to 64-bit Sql Server where we'l' have upwards of 500 worker threads depending on the configuration
3. increase max worker threads setting for the current configuration. each worker thread will need 0.5 MB for its thread stack and by increasing this number we will be reducing memory from the buffer pool.

ultimately the objective is to prevent further SQLVDI event IDs and prevent "Limit on 'Max worker threads' reached" errors.

unless there is a major draw back, we will also consider switching from native SQL backups to an image based only backup.

I know this is obscure but I once had problems with worker threads which came down to having exactly 613 jobs on the server. We cured this by adding a job so there were 614. It is probably not this but just in case.

that problem with staggering. You can set up a maintenance plan for a database. At the end of the maintenenance plan you can then say "kick off another sql job" It's a componenet on the maintenance plan gui.

JSON is being used more and more, besides XML, and you surely wanted to parse the data out into SQL instead of doing it in some Javascript. The below function in SQL Server can do the job for you, returning a quick table with the parsed data.