Windows 10 over time starts to suffer frequent 10-30 sec UI lock-ups with 100% active disk time

I have been using Parallel's for a couple of years now with Windows 10.

Initially everything was great and I was quite impressed. However 6 months or so in, it started suffering from UI lock-ups more and more frequently as time went by when trying to do simple things like drag a window, access files, click menus - pretty much a whole stack of random things would cause 10-30 second lock-ups before the UI would start responding again (often with Not Responding displayed in the title bar of which ever window I was in).

I contacted support with no joy, even after a support person called me and connected to my machine, it seemed like they had no tools to debug anything or really offer any suggestions other than reinstalling Parallels and Tools which I'd already tried many times. I have not had any luck searching for a solution either.

Other Parallels VM's on my machine still seemed to perform fine. The Windows 10 install would be what I'd also consider a fairly clean install, basically a software development IDE I installed at the start which I use to write and compile code along with a GIT client. I hadn't really installed anything else much. The only real difference I can see from the initial install is there's a lot more data stored on the disk, such as large log files my software has generated etc.

I suspect it might be some kind of disk IO issue. If I bring task manager up, whenever it locks up, the "Active Time" goes to 100%, the disk transfer rate however stays low. It's all running on a late 2018 MacBook Pro with 32GB RAM, 4TB SSD (of which more than half is empty). It had all the highest specs available at the time. Running macOS Catalina 10.15.7. This too is what I'd call clean, barely any apps installed other than what it came with. Parallels 16.0.1 (48919) currently. The issues happen even after a reboot of both macOS and Windows 10 with no apps running (other than things like explorer).

I basically gave up trying to fix this, copied a backup of the Windows 10 VM I made after I had installed it and applied updates, reinstalled the code IDE, copied over my source code and everything was great again.

Months later this VM started showing signs of the original one and is now at a point where it is almost unusable, the same frequent lock ups, the same 100% disk active time while the transfer rate stays low. I've also just done a disk scan in Windows and reported no errors (Ironically it locked up for 10 seconds clicking on the Close button though..). I also ran a scan over the mac drive with no issues found.

I boot up other VM's and they run fast with no noticeable issues. I'm about to yet again take a clean backup of the original VM and reinstall everything and copy across my code and start again but this is a pain to have to do every few months, I would like to try and track down what is causing this and it's making the whole Parallels experience frustrating.

Any constructive suggestions very welcome.
Thanks

 

So I waited a year or so before giving up and finally posting a question about this issue here. Then while my post was pending approval I thought of something else to try. The space allocated to c: in Windows 10 was 256GB and I only had around 25GB space free which I felt was a little low and was wondering if that was affecting performance. I made a clone of the VM, renamed the original and increased the drive size to 512Gb to see if it made a difference.

I booted into Windows and everything was running like it was brand new again, no lock-ups. I checked the drive and saw it was still 256GB showing in Windows Explorer but quickly realised in Disk Management the drive size had been increased to 512GB but the partition hadn't be increased. Then I thought, if I shutdown Windows and go back into the Parallel configuration and change the drive size back to 256GB, will it be slow again?

I changed the drive back to its original 256GB size again, booted Windows 10 and again it seems like new, snappy and no lock-ups, no 100% Active Disk time in Task Manager..

I did all this on a copy of the VM as I didn't want to risk destroying it in the process, so have just tried again (but there is a twist to the story..).

1) Made a fresh copy of the slow VM
2) Change the size of the drive to 512GB, apply. Immediately change it back to 256GB and apply.
3) Boot Windows 10
4) Windows 10 running fast again, no lock-ups

Amazing I thought!

Then I thought, I better clone the original VM and boot that unchanged to confirm it was in fact slow and it wasn't just that the VM had been copied to a fresh file.

1) Copied VM
2) Booted unchanged, it runs fast, no lock-ups

Hmm ok, so the duplicate is fast with no changes.

I then deleted the clone and renamed and booted the original, now this one seems to be operating like new again as well fast with no lock-ups, I had not made any changes to this one at all. This has been suffering the lock-up issue for months prior to this with nothing else helping..

Are some of the configurations for the VM stored outside of the .pvm file, so when I made a clone of it and changed settings, would something have been saved that would have affected the original file when I renamed it back and ran it? If there are other setting files, I had backed up everything to Time Machine just this morning so can retrieve any original files to compare what has changed.

I have not run Windows 10 long enough to confirm 100% that this has solved the issue but I can't remember the last time I booted into Windows 10 and then been able to bring up File Explorer and click on a folder or file within seconds of booting without everything being unusable for quite some time.

 

UPDATE: I just upgraded from Parallels 16.0.1-48919 to 17.0.0-51461 and the issue I had in this thread has resurfaced, my Windows 10 VM is now almost unusable, continually locks up and the Disk Active time in Task Manager goes to 100% whenever everything locks up.

Given what I learnt previously and posted here, I started experimenting. I tried more things than I am listing here but I've boiled it down to this repeatable situation:

1) While Parallels is closed, make a copy in Finder of my Windows 10 VM to a temp folder.
2) Start Parallels, confirmed in the Control Center that the entry for my VM points to the original still by going "Show in Finder".
3) Boot the original VM, it now runs perfect again, fast, responsive - great.
4) Shutdown the VM and close Parallels.
5) Delete the temporary copy of the VM from my temp folder (I never even booted this copy).
6) Boot the original VM again - it now runs rubbish again, locks up - unusable.

I can repeat the above and it behaves the same each time.

This is somewhat perplexing to me, it almost seems like something at the file system level in MacOS to do with how it handles copying files - why does this seemingly unrelated copy of the file in a temp folder that is not even booted or touched seem to affect the performance of the original? While it exists, the original is great, once deleted it reverts to locking up etc. The file system might do a copy on write under the hood but it is still weird that once the copy is deleted the original goes back to its old ways..

However that said, this situation seems to have surfaced twice now when I've upgraded Parallels to a newer version, somehow this must be a factor too?? Everything had been perfect for a couple of months until I upgraded and then immediately the problem appeared. I'd also scanned my MacBook Pro SSD and it found no errors and I haven't seen any other issues.

Oh and to be 100% sure I was booting the original and not the copy, I saved a file in Windows and then once I had deleted the copy and booted back in I could confirm the file was there.

Is anyone from Parallels support interested in this issue? I can't be the only one in the world who's had this issue and I've spent hours debugging this to get to this point. I have previously lodged a ticket for this the first time it happened but the support staff seemed out of ideas after checking a few basic settings and doing a reinstall of Parallels and tools in Windows (all of which I'd tried before anyway). I suspect I can make a copy of the VM and delete the original and everything will likely be fine again but it seems like I'd be throwing away some valuable debugging information you could use to find out what is really happening.

 

Hi DavidS113,
Thank you for taking the time to post such a detailed explanation of your problems and trouble shooting steps! Like you, I have had endless problems with my Windows 10 VM running on a MB Pro 16" with 8 Cores and 32GB of RAM running MacOS 10.15.7 after upgrading to Parallels 16 a few months ago. I had the drive utilization issue you mention last year in Parallels 15 but had not seen it for a while. After upgrading to Parallels 16 a few months ago, I started having issues again where my Win10 VM would randomly freeze and become unresponsive but when I checked the Activity Monitor on my Mac it was not showing the drive utilization issue I was having before. In my instance, it was the VM's processor usage that would show 100% during these periods and the only way to get the VM functioning was to Pause or Suspend the VM and then resume it if I did not want to let the VM sit for some indeterminable about of time. Sometimes, during the suspend/pause process, or if I let the VM sit long enough in that state, I would get a Parallels message that a critical error had occurred and it would ask me to submit a log of the issue to Parallels. Then Parallels released the last update to 16 and it seemed better for a little while but has since returned to randomly freezing, only I do not get the critical error has occurred messages anymore. The other issue I had was whenever the VM would enter Travel Mode it would become very latent, sluggish and almost unusable. Support does not seem to have resolutions to these problems and each tech that would access my computer would turn on/off settings the prior tech turned off/on or change the hypervisor mode from Apple to Parallels and visa-versa and then create and gather another technical report. I finally reverted back to Parallels 15 and both of those problems went away. I was thinking of trying an upgrade to Parallels 17 but your post seems to indicate they just slapped a higher version number on the same set of issues that existed in Parallels 16.

 

I can't recall if the monitoring tools on the Mac side were showing drive issues for me or not, but I do know whenever there was a freeze (which was frequently) the Active Time for Disk 0 (C in task manager would always be at 100% but with a small value on the "Disk transfer rate" shown below. I've only really had this particular issue, I haven't noticed high CPU or errors as such.

What I ended up doing was copying my whole VM off to an external drive to rule out any trickery with cloning files on the same disk and copied it back again so I was sure it's a completely new copy with no ties to the old file. I am running this VM now and it works like a dream, like it is brand new again and I did nothing other than copying it.

I was hoping someone (i.e. a dev probably) from Parallels might be interested in investigating so I left the old one that behaves strangely there, just renamed.

Given that copying the VM off and back on again solved my issue, part of me thinks it is some weird issue with the file system or Mac OS - however, the issue has now shown up twice immediately after upgrading Parallel versions, so that somehow has an affect on it as well. I'm pretty sure after the first time I upgraded and ran into this issue I tried downgrading to the exact version that was working fine before and the VM was still freezing up in the old version.

Your issue might be a different one, I am not sure, but it might be worth trying copying yours off and back again and see if it mysteriously fixes itself. I was a little paranoid as it was such a large file so I computed an SHA256 of the internal main drive in the VM package before copying it off and verified it once it was copied back on to ensure nothing got corrupted in the process.

The specs on our machines look pretty similar. I don't have much installed on the Mac side of things, so the install is still pretty clean with lots of drive space available.

I'll be interested in any updates you have.

 

For months, I have been having the same problems with high disk usage making the VM unresponsive for large amounts of time. Start up and shut down were also very long. All kinds of things would cause Windows' Task Manager to report 100% disk usage, while at the same time, only a handful of processes would only report no more than 0.1MB/s or 0.2MB at any given time during the high usage.

I came across the posts above from @DavidS113 about moving the VM to an external drive and then copying it back on.

I did so today. I copied the VM file to an external drive, deleted the in-place VM, then copied the file back from the external drive.

When booting the VM afterward, performance was immediately better. Start up took a small fraction of the time, and I'm not noticing any abnormally high disk usage in the VM. Also, I now see lots of processes actually reporting higher IO rates in MB/s, while the % of Disk usage remains much more reasonable in accordance with actual disk activity.

As there was no change to the VM file during moving/copying it, it makes me thing that something with the macOS file system might be causing the issues, as @DavidS113 suggested.

I started and shut down the VM several times afterward, and there was no drop in performance.

Afterward, I renamed the newly copied VM file, and then restored the one I had deleted from the Trash. So far, after starting and shutting down the original VM file a couple times after restoring it, there has been no decrease in performance.

I am linking to this thread in my open support ticket with Parallels. Hopefully this will draw some attention to it.

Thanks for the idea, @DavidS113.

 

As an update, it looks like Parallels was still using thew newly copied VM file rather than the original file which had be restored from the trash. I just tried opening the original VM file from Finder, and the performance problems are actually far worse for it now.

The newly copied VM file continues to work fine, however.