Hello audiophiles,
I want to point people to another possible solution, because I have not seen this mentioned yet - at least not in connection to the UR22 explicitly or any other usb audio interface that is.
TL;DR: either stop your HDDs from spinning down at all OR (preferably) find whatever software interrupts your hdds’ sleep which in turn might cause “blockade” of the transmission of your audio stream.
Looong explanation:
The first step I did was of course to run LatencyMon - as we all do 
First thing I noticed: extremely high latency of the NVIDIA driver. But this was easily solved by switching to “Prefer Max Performance” in the driver control panel. Latency spike gone - but dropouts remained. Damn.
So I went about the usual stuff we all love: putting drivers into MSI mode, giving the UR22’s USB controller hub a high priority in MSI (just like you would do for a NVME or fast LAN card - usually not needed for usb2 audio, but hey, I was desperate^^), stopping USB Selective Suspend, disabling PCI-E Energy Savings etc.
It all seemed(!) to help a little - but did not solve the problem after all. And in retrospect it does not even seem necessary, I should honestly admit that!
All this became obvious to me when LatencyMon gave me the final hint that I needed to find the actual culprit: it told me about ACPI.sys ruining my day(s, months, years)…which again pointed me towards energy savings…which at first puzzled me - but then it hit me hard.
All my problems were related to the path that the data takes on the motherboard! Both the SATA (plus one m.2 NVME in slot 3 actually, which would also get disconnected during the dropouts) and the UR22’s USB controller are connected to the PCH (formerly known as Southbridge) which in turn is connected to the CPU and RAM (formerly known as Northbridge) over the mainboard’s DMI (formerly known as Front-Side-Bus).
Whenever my hdds were accessed by some stupid M$ background or whatever service that forces itself upon you, the bus would be blocked for the time it took to spin the hdds back up. This had escaped my detection b4 - because it only occurs when multiple hdds spin up at the same time. During those moments nothing could communicate smoothly over that bus (which the driver seems to detect in the new Yamaha version 2.1.1, and this might lead to resetting of the driver now).
Now the search began. I traced any access to my hdds with perfmon/resmon/processexplorer, and shut it down! That is I went about deleting preinstalled UWP apps and packages, shutting down services for telemetry etc. and also stopping scheduled tasks like the MS-Defender scanning for “no” reason.
After all that is now done, I do have not only a silent and “energy conscious” PC, but also audio without dropouts.
So check the route that the data takes on your mainboard, and do not just settle for disabling all energy savings! It does work, and it is not a problem that Steinberg created. Yet, they could invest more time into supporting people online when such problems arise…I guess.
Good luck.