Are you able to get it faster on the same clients when you deinstall the upgrade?
The most direct reason for a slower file dialog is a HDD that's broken, or its controller. With SSDs you could try to get performaceup with TRIM. Before you do that just as a guess, I'd check the HDD health status with an S.M.A.R.T. tool
A simple test whether it is the drive would be adding an external USB drive that can be addressed faster. If a new drive also reacts slow to the common dialog you have some confirmation, but now you might just have coincidence, which I often get from customers that can only think of Windows Updates as the last thing that changed their system and just don't know about other changes pushed to their clients by adminstration or forgot that they actually introduced something else themselves.
In my experience slow hard drive actions usually are pointing out a degrading hdd, no more, no less. It's also the most natural reason.
What on earth should make a dialog slow, that is a Window, the thing that is the root of the OS name, just because there was any upgrade? It's such a common and central thing, not only creating windows/forms, but also addressing the file system, that I'm eager to say that would not havve passed Microsoft testing. Even though common dialogs are an old technology, it's still a common part of Windows.
Are you using the core Windows API, or are you perhaps using a third part OCX that makes using Common Dialogs easier? You could easiy convince me that an OCX became slower since a Windows Upgrade, as I have seen OCXes degrade (though they did not become broken) when they get old and use something that depracates. Especially when they are programmed to switching to a fallback after a timeout. That could even be something as funny as a dependency with a specific font that got removed. So one other thing you should try in that case is more direct usage of the common dialogs.
Chriss