For me the problem of 100% "Active Time" (Task Manager, Performance tab) has always existed as long as I can remember on Windows 10. My initial investigations seem to indicate it was mostly McAfee I/O and indexing.
What was new starting in January, was that the RATE of disk I/O in Resource Manager also started showing a constant 10 MB/s or higher for long periods of time EVERY DAY. That disk I/O RATE appeared to be due to WaasMedic and was preventing me from getting a usable response to UI input (i.e. greater than 10 - 30 secs for a mouse click or > 10 - 15 sec for a keystroke response) for between 20 minutes to 75 minutes after pressing the power button. This situation was unaffected by turning off indexing, and only mildly improved by turning on fast startup.
It is difficult to say exactly what is going on because when the disk I/O is so heavy that UI inputs are futile, invoking task manager with CTRL-ALT-DEL ('cause it is impossible from the desktop) can take up to 2 mins for the task manager window to appear, another 2 - 3 minuted got the window to fill in with information and allow me to access the performance tab. Clicking "Open Resource Manager" takes another 2 - 3 mins for the Resource Manger UI to appear and sometimes another 2 - 5 mins before the UI fills in with processes and the graphs start filling in. In the disk tab, "Processes with Disk Activity" pane WaasMedic is at the top of the list (sorted by "Total (B/sec)" column) and its IO sometimes clips with the max graph point at 10 MB/sec. Looking down at the "Disk Activity" pane, there are usually multiple instances of WaasMedic running all referencing different files. My guess is that since I am running dual 9-core CPUs I have 16 threads of WaasMedic running, at least that is how it appears.
With the disk activity entries jumping around all over the place and different instances changing position as top IO user, it is hard to bet a read on which files each instance of WaasMedic is accessing but it appears most of them are looking at master boot records and block tables. This got me thinking back to the the fact that this problem seemed to have started shortly after the "optional" Flash removal update auto-installed. Also of note was that this "update" COULD NOT be uninstalled / rolled back. So, just as with SECDRV, I believe all this activity is a willful Microsoft strategy to MAKE SURE no one finds a way to re-install Flash or undo the update to the kernel that prevents Flash from being re-installed / run ever again.
So I believe if MS quit being so dictatorial about what legacy apps it will and won't let you run (usually tied to MS trying to force you to an MS alternative) this problem would be resolved.