I would check the following:

1. Check the %SYS.Task class with SQL but also do an Integrity check, to see if there are any errors on those globals that hold that task manager data.

2. if the "corrupted"/"copied" task (with $h=0) is the one that consume 100% of CPU, I would try to "re-schedule" it to see if the new "next date" is set to something else. If not, to delete (you don't need to re-create it, looks like 1001 is a copy of 1000)

3. Monitor the 100% CPU task (SMP or JOBEXAM) to try to understand at what commands it's "stuck" 

Ephraim,

When you say "corrupted" to better understand...
- Did you try to mount the DB (from the SMP of with ^MOUNT)? Sometimes if IRIS/Cache was "forced" than a *.lck file on the DB folder need to be deleted in order to allow a successful mount. 
- If the DB is mounted, did you got a <DATABASE> (or other) error? if so, then what was said using ^Integrity and ^Repair could help - but only if you fully understand how to use those tools (!) Most of the time, a corrupted DB is fixable using those tools, or at least data can be 99% recovered. Depending on the number of errors: if its huge than sometimes it is faster to recover the DB from a valid backup + journal files. 

BTW - if this is a mirrored DB than there are other considerations as well. 

Happy new year!