I had exactly the same thing happen to my portal (4.8.4, SQL 2005 as well) the other day. I only have 3 custom scheduled processes but each of them is optimized to work without an HttpContext (I followed the instructions of Joe Brinkman's blog from quite some time ago).
My thoughts are that it still *probably* has something to do with that -- something needs an HttpContext and fails miserably, but I really have no way of confirming because no errors are logged to the EventLog in DNN -or- on the server.
I disabled all of my custom scheduled processes and tried it and it still failed, so I'm certain it either has to do with the timer mode in general or one of the core scheduled processes. Since it was our intranet, I didn't really feel like going through and enabling/disabling processes one by one until identifying the culprit. My three processes run every 5 minutes, but they are more than fast enough to get their job done in the five minutes and not overlap a subsequent request.
Processes we have enabled:
DotNetNuke.Entities.Users.PurgeUsersOnline, DOTNETNUKE (every 1 hour, retry 5 minutes
DotNetNuke.Services.Scheduling.PurgeScheduleHistory, DOTNETNUKE (every 1 day
DotNetNuke.Services.Search.SearchEngineScheduler, DOTNETNUKE (every 1 day)
DotNetNuke.Services.FileSystem.SynchronizeFileSystem, DOTNETNUKE (every 1 day)
DotNetNuke.Services.Cache.PurgeCache, DOTNETNUKE (every 4 hours, retry 30 minutes)