Does not run under Wine

This is not an actual issue, just here for curiosity and book keeping purposes.
AutoDDU_CLI.zip
https://pastebin.com/VEhzaq3J

Make sure someone's system time is correct.

I have a working implementation of this that uses NTP servers. This is to catch connection issues that prevent from downloading drivers, it can happen when a PC has not been turned on for a long time.

Restarting more than once results in no Autologin

If a user restarts his PC more than once when going into safe mode then Windows will not log him in, this is due to the current implementation of this setting the AutoAdminLogon registry key to one to prevent possible loops of auto logging in.

Turn off custom CRU resolutions, should be a simple download then run reset all command

Check for drivers when GPU is not in database

Sometimes NVIDIA releases a new GPU like a 3080 Ti or RTX 2050 but the drivers that support these only support the specific GPUs, this has happened a few times.

When this happens, AutoDDU will incorrectly grab the driver used for all GPUs, instead of the one that supports those new releases.

There are two ways I see about going about this:

Parse NVIDIA lookup value

NVIDIA stores this xml file used for lookup in the website, we can grab their GPU name, look this up and then return the correct driver with the gfwsl.geforce.com service as demonstrated here

This won't work for all cases as it goes off name, so duplicate GPU entries like GT 730 would produce bad results, so this would only be used in the case that a GPU is not in the PCI-IDS database and not in the SupportedGPU list in the CommonSoftware Jsons.

Figure out how GeForce Experience deals with this

GFE somehow uses some API that automatically knows this, but I have yet to figure it out.

Windows Update Assistant sometimes forces clean install

For some goddamn reason I've seen in VMs that if there's pending Windows updates sometimes the update assistant forces you to do a "clean install".

Doing updates has always solved this in my testing, AutoDDU should check if there's pending updates before launching Update Assistant.

Note that despite AutoDDU lauching the Update Assistant with the /auto flag, the user still has to manually agree to delete everything, so this isn't a critical issue.

Sys.executable sometimes gives wrong directory

Saw an instance in the NVIDIA server ( https://discord.com/channels/185647255028629505/185808757115191296/952815438675468288 ) where somehow copying the sys.executable failed, having to fall back to the except method of downloading executable from github.

UTC 13/03/2022 19:01:03 Falled back to downloading from github method for going to Appdata directory due to error: Traceback (most recent call last):
  File "AutoDDU_CLI.py", line 366, in makepersist
  File "shutil.py", line 254, in copyfile
FileNotFoundError: [Errno 2] No such file or directory: 'C:\\Users\\jason\\Downloads\\AutoDDU_CLI.exe'

Same issue for user folder.

Interestingly the user did AutoDDU a day later and it finished fine:

UTC 14/03/2022 05:58:40 Successfully copied executable to new user
UTC 14/03/2022 05:58:40 Successfully copied executable to Appdata directory

There were no executable changes between these two runs, which has resulted in me being dumbfounded.

Handle cases where people overwrite the install location of applications in Windows outside of the C: drive.

This causes permissions issues. I have been looking into this, haven't found where in registry it's stored yet.

Networking adapter problem

Some people's configuration are not so simple that you can just disable and reenable the network adapters on a whim, for example in the NVIDIA discord server I found here https://discord.com/channels/185647255028629505/1054058750736072735/1054174224501182614 that their network adapter wouldn't turn on until the system restarted a second time.

And then an earlier case (which is already worked around in AutoDDU but imperfectly) of people having dead network adapters in their PC. This edge case is handled by opening a different thread and killing the thread if it takes too long, but this can result in not disabling or enabling the internet if the order of the WMI library places the problematic adapter before the working one, it can also result in us never enabling back as we never stored its state in the log.

This entire process needs to be redone from scratch, probably still using multiprocessing but opening a thread per adapter instead of for the entire network operation, and having tests for if the internet was disabled or not, and acting accordingly if it wasn't.

Turn off Link State Power Management for non-laptop setups.

Mainly because this can cause annoying as hell stability issues. There is no real problem with disabling this on desktops, barely increases power usage.

Handle LTSC/LTSB installs and update them.

I have a working implementation of this already. Just a matter of willingness to test.

To do list

Areas that need the most testing:

I have only tested this with one AMD GPU, more AMD GPU tests pls
If someone has an AutoLogin setup before they run this, it may not work until they set it up again, but I am not sure.
While gaming laptops are stupid, still would be nice if this works for them, in which case I need more people with them to report results.

Missing features/limitations:

~~- [ ] After running DDU and installing drivers Auto-DDU should select highest resolution/refresh rate for all monitors and enable GSync if applicable~~ Edit: I don't believe enabling GSync/Freesync via command line is possible on Windows.