Resolve crashing on startup "Looking for Control Surface""

Over the last two days Resolve has started crashing on startup "Looking for control surface" even though I had not changed any hardware or software recently. I searched the forums and came across an obscure reference to USB hubs and startup crashes. I guess the Control Surfaces that Resolve looks for on startup were hanging up on the USB devices I had plugged into my USB 3.0 hub. I started unplugging wireless Mice, keyboard and headset dongles until Resolve started up fine and wanted to send you this feedback. Over the course of trying to solve the problem I had updated my nVidia drivers, downloaded and installed the latest Beta version of Resolve (none of which worked), uninstalled the Beta version and went back to the non Beta, uninstalled that and back to the Beta and finally the USB dongle elimination experiment. This seems to have been the successful solution so I wanted to share this with the forum. I hope this may help others with the same problem.
Christoff Epp

thanks for sharing. had and have the same problem. here unplugging all usb devices did not do the trick.
I m still looking for a solution...

[Dwaine Maggart]

Which USB device was causing the issue?

Almost certainly a powersaving bug related to the USB hub device or potentially the root hub itself. Could also happen as a result of a bad cable, bad cable routing or unshielded device/hub admitting noise. Even in cases of a noisy line, I've found disabling powersaving seems to help. It certainly can't hurt.

A potential workaround would be to add a UI prompt on install to disable powersaving for ports and hubs up the tree (LocationInformation) and maintain that reg key on connect/disconnect with the aid of a persistent background service that listens for such events of relevant VPRs. It's a big kludgy because any other process or service that attempts to maintain the powersaving state of an intermediate hub port might get its settings stepped on if the user moves the device to a different USB port, but you might poll the key again periodically (like on any device disconnect/reconnect) and re-set/assert ResetOnResume=0x0001 and DeviceIdleEnabled=0x0000 (the former being necessary in case the non-standard driver of an upstream hub or port irritatingly ignores downstream device settings (looking at you, Lenovo!)