If you want to see what's going on when Drupal's cron.php script runs, one thing you can do is to set a breakpoint in a module's implementation of the hook_cron() function, and call cron.php directly from your debugger. There you can step through your breakpoints, examine variables, and hopefully zero in on your problem.

The particular problem I was having involved nodes losing some of their taxonomy information when getting published by the scheduler module as handled by the scheduler_cron() function. (Taxonomy access control was to blame; it was disallowing anonymous list access to the affected taxonomy terms, and since cron.php typically runs as an anonymous Drupal user those terms were getting ignored.) Because I didn't want to have to keep adding new test nodes, I stopped execution of the cron script as soon as I saw the problem happening.

The only problem is that this interferes with the normal behavior of cron.php, which sets a system variable called cron_semphore while running, which it then deletes it when finished. It does this to prevent more than one instance of cron.php from running concurrently; if you call cron.php and it finds the cron_semaphore variable, you'll see a watchdog entry that reads "Attempting to re-run cron whilte it is already running," and cron.php stops dead.

If you've meddled with the normal flow of cron.php and it stops before removing the cron_semaphore variable, you'll probably have to remove it yourself. You can do this by installing the devel module and using it 'Variable editor' tool. After you delete cron_semaphore, you should also use the devel module's 'Empty cache' tool to remove all traces of it from the cache. Having done this, you should be able to run cron.php again normally.