I have now resolved this problem on my own and am going to detail what I did to solve it in case anyone else has similar problems.
1) I did find a different error_log that I had overlooked, in the wp-admin subdirectory (which had grown to about 12 megs). This had entries like:
WordPress database error Table 'username_wp123.wp_wfHoover' doesn't exist for query SHOW FULL COLUMNS FROMwp_wfHoovermade by do_action('wp_ajax_nopriv_wordfence_doScan'), WP_Hook->do_action, WP_Hook->apply_filters, wordfence::ajax_doScan_callback, wfScan::wfScanMain, wfScanEngine->go, wfScanEngine->doScan, wfScanEngine->scan_fileContents_main, wordfenceScanner->scan, wordfenceURLHoover->hoover, wordfenceURLHoover->writeHosts, wfDB->queryWrite
I decided to try a clean reinstall.
2) In Wordefence options, I exported my wordfence settings to created a token.
3) In Wordfence options, I checked the box to delete wordfence tables and data on deactivation.
4) I deactivated and deleted Wordfence.
5) I reinstalled Wordfence from the wordpress plugin repository.
6) I imported my previously set options using the token I had created.
7) I ran a scan — this time it was successful.
So I can only guess that somewhere along the line some entry had been corrupted and that Wordfence was not correctly identifying the database, and that with a clean install I forced Wordfence to recreate all tables and solved the problem.
From revising the wp-admin/error_log, it looks like this problem might have originated in February with an error: “The table ‘wp_wfFileMods’ is full for query insert” — which occurred right before the wfHoover doesn’t exist errors started appearing. So perhaps the problem originated when Wordfence was unable to write important data to to wfFileMods.
