WaasMedic Agent Exe stopping me from working

I don't see evidence of it running on an older Surface with Windows 10 Home edition. So it may not be in / similarly implemented in the "Enterprise" edition, just us suckers on the "Pro" edition.

I'm wondering businesses have identified and resolved these issues. I can't imagine any business not resolving a 45 minute login process for their team members. There have to be answers, but I agree, MicroSoft should lead the analysis and provide recommended solutions transparently to all it's users.

Marchoppe and Tooney2

My WaasMedic run just finished on an HP z840 workstation with a 2TB Seagate "hybrid" HD system drive. (Supposedly the "hybrid" part is a NOV-RAM portion that caches the most frequently accessed files to speed disk I/O, but with the way WaasMedic and other MS spyware is implemented, I think this caching actually works against me.)

My "Sunday Fun Run" of WaasMedic lasted about 90 minutes with useable system response to mouse clicks appearing at about the 50 minute mark. Shortly after boot, initiating (and waiting for the long delays to get to) Task and Resource Managers it showed WaasMedic accessing the update file and system file directories, but by the 45 minute mark it was walking through C:Users<MyUserName>... all its directories, sub dirs and files, finishing at about the 90 minutes-after-boot mark.

On an older MS Surface (circa 2016) with SSD that I had not fired up since early March until last evening when I let WU push updates, then manually ran and re-ran WU until no more updates were available, this Sunday morning boot took about 5-10 sec from power up to logon screen, instantaneous desktop at logon and no indication that WaasMedic was running by the time I got TM and RM running. Both of the managers, BTW popped up instantly, no hesitation at all.

Two things:

I discovered (unbeknownst at the time of purchase) that the Surface has Windows 10 "Home" edition on it so there is no "Task Scheduler" app available, and I haven't tracked down where in the registry scheduled tasks are stored. So I do not know if WaasMedic is even part of the "Home" edition.

Second, talking to a over-clocker friend who runs SATA SSDs as system drive, a RAID 10 and a RAID 5 in the same system and has done since the early days of Win 10, has never seen these boot issues. Add to that the few files y'all caught Waas accessing on an SSD system and I'd say you found the key and only solution: migrate the bootable SYS volume to an SSD.

As for the reason for the "discrimination" against HD users, it could either be an MS attempt to force all users to SSDs or MS's clumsy (failed) attempt to mitigate some of the excess startup-overhead on HDs by trying to figure out the files / apps you use most often and preloading them at boot time to make you think your system is running faster than it ordinarily would given the increase in spyware and market-ware MS is cramming into every update.

BTW, though I haven't actually been able to get my act together to do it, it might be possible to get a detailed "catch" of Waas activity by running SysInternals ProcMon 64 with the "Enable Boot Logging" option set. NOTE: If you set this option it will only last until the next boot. If you forget to then open ProcMon and save the boot log you may lose it.

MarcHoppe:

Thanks for your post.

I was wondering how you determined which files were accessed by a process. I see you used MS resource monitor... disk activity and filtered on the waasmedic agent process. I will use that in future.

Interesting the difference in files read by waasmedic on SSD system from those on HDD system. In the past have your SSD system(s) experienced performance degradation from waasmedic, or have you seen the problem only on HDD system(s)?

According to my testing here there is a direct relation between SSD and HDD WaaS run times. The WaaS issue occurs on all five of my Win 10 computers and they are all different in terms of what software is loaded on them. Some have third party AV software some just run Windows Defender etc. There does not appear to be any correlation to what software is loaded on the system and the WaaS run times. So far the only major difference has been between the systems with a HDD and the system with an SSD. The exact same files that get read during the weekly WaaS run such as the files in Windows>Servicing>LCU>Package for Rollup Fix and Windows>WinSxS are present on all systems. They get scanned every Sunday on the systems with HDDs and they do not get scanned on the system with an SSD. Whether that's a bug or designed behavior I can't say and M$ isn't saying a thing.

I've only seen system degradation on my systems with a HDD. My older laptop being the most affected with WaaS run times of up to 20 minutes. That's one of the systems I've done the reg hack on to turn off WaaS and disabled the services "SysMain" and "Connected User Experiences and Telemetry Properties" and it's running so much better now. Whether those actions are going to have some negative impact going forward I can't say yet but so far so good.