-
Notifications
You must be signed in to change notification settings - Fork 0
List of niche cases
This is purely to keep track of them all..
If a system's time is wrong by enough of a margin, certain internet requests can and often will fail, and we will also have a situation where the drivers may not install because the certificate signature doesn't make sense.
Initially AutoDDU verified the system's clock was correct with contacting NTP servers, however ironically this encountered issues on these systems because the connection would fail, which is likely the reason why their system time was incorrect in the first place. This is handled somewhat in download_helper() by it being able to handle bad certificate situations, but the driver installation issue is still present. The reality is that these issues are incredibly hard to properly automate fixes for without a system that has the problem reproduably
Specific details yet unknown.
Cannot provide specific information because I frankly have yet to track this down properly, only way we can handle this is in TestMultiprocessing() where it makes sure a given system can handle multiprocessing.
Essentially the title, more info here: https://answers.microsoft.com/en-us/windows/forum/all/win32useraccount-doesnt-function-if-norwegian/d9a6dfb8-985c-4ef6-9fbc-7a70bc34f63d
Seems to have been fixed in Windows sometime after 22H2's release. No idea where specifically, but there's still code in AutoDDU to be able to detect whether we've created the necessary user account, so if a user encounters this AutoDDU should still fail gracefully.
Discovered in the initial stages of development and was actually extremely difficult to track down, but in short, Windows's command prompt hangs the process in the console if a user highlights text (even just a single character), which can often happen by accident, causing AutoDDU where it can even stop running in the background when the buffer fills up.
Use the ctypes API to disable the ability for a user to select any text. This is done near the beginning of mainpain(). This issue can be properly fixed when Windows 10 loses support, since Windows Terminal doesn't suffer from this problem.
This was initially a major problem because in my naivity I used the requests python library, which due to what I could describe as a momentary lapse of judgement, they do not verify that the connection actually fucking finished: https://github.com/psf/requests/issues/4956
There were multiple different approaches to workaround this over the months, at a point there were three different downloaders in AutoDDU each used in its own cirucmstance, but as of v0.2.0 now it uses httpx, which fixes all known problems.
Most affected is NVIDIA, but this affects AMD too, is that sometimes when they release a new GPU they do not include support for said GPU in the current driver branches which supports the rest of the drivers. The chika bot in CommonSoftware cannot realistically deal with these GPUs.
For NVIDIA AutoDDU can now use the Geforce Experience lookup API and with the given GPU's PCI ID give the proper driver download URL to download_helper(), after confirming the GPU is not in a known list of EOL architectures.
For AMD there is no known solution for this, one has to handle these cases manually in CommonSoftware repo.
Sometimes when falling into the DNS niche case, we end up doing IP address connections due to the very nature of the problem, however some domains such as Github's raw directories and some AMD's driver directories need the HTTP host header to specify the host and port, or else we're served garbage, which in the worst case can result in AutoDDU thinking we successfully downloaded a given file while in reality we downloaded an empty bin.
As of v0.2.0 this is properly handled in download_helper() by using python's built in urllib.parse function to split the url and get the needed host header, and pass it to the HTTP request for all URLs.
Multiple times people would willy nilly clone this Github repo and think they're being the smartest person in the world by running it with their own Python install instead of the one included in the prebuilt executable. This is a very bad idea, there are countless assumptions in the code made with the notion that it runs in a frozen executable.
The function TestForStupidityPart43() protects against this by making sure AutoDDU is running as a frozen executable.
TLDR: If you don't use Edge at least once, Windows never installs the intermediate certificates used for websites, which affects apps like AutoDDU which didn't have the foresight to handle certificates themselves (instead I assumed I could let Windows handle it)
Very interesting issue CommandMC reported to me with AutoDDU, which is def a niche case.
You know how when you clean install Windows, usually the first thing you do is google something to download your browser (or just use Edge)? Well, it turns out this is actually important.
Windows doesn't download all the certificates you would ordinarily use if you don't do something like this, which affects AutoDDU.
CommandMC instead of doing that instead had the firefox installer on a USB stick and transferred it over, avoiding ever using Edge, which meant that Windows didn't download all the needed certificates used for websites (in specific the intermediate certificates).
So, AutoDDU doesn't have the functionality to do this, nor does Python, because usually people always use Edge/IE at least once.
AutoDDU as of v0.2.0 downloads Firefox's prebuilt certificates if it encounters a certificate problem, the likelihood of this happening was also reduced by re-implementing the downloading function with httpx, which uses certifi.
When a user configures their user profile to use OneDrive on creation (this does not happen if setup after creation) then folders will be located in OneDrive, while also existing in the normal location, but those "normal" locations do not have the proper and intended effect, and when trying to copy or access these OneDrive locations it fails in Safe mode.
We do not store anything important in user dependent files, instead 99% of what we use is stored in ProgramData which is provided by the CSIDL API. And when we need to do something user specific we create a user for it, such as having AutoDDU on the desktop, we ourselves create a local user account with OneDrive disabled.
If a user were to restart multiple times and has a live account instead of a local one, upon trying to login they won't be able to login as we disable the internet.
Create a local user account so the cache is not used until DDU is over, and check for pending restarts prior to turning off the internet using the RestartPending() function.
The Windows in German (does not apply if the ISO used is not in german) localizes the administrator group, meaning traditional add user to admin group used to add our user to the administrator group would not work.
We check all the possible user groups in the system and compare them and see which one has the rights we need, and return that name to the function that runs the command to add the user to the intended group. More details in the AdminGroupName() function.
If there is pending Windows updates we can have a situation that when we restart we won't be landed in safe mode.
This is handled in two different ways. First we check to see if there's pending Windows updates to be installed in the PendingUpdatesCount() function, and if there are some then the user will be prompted to install them. Then we check to see if there's installed updates that have a pending restart with RestartPending() .
Both of these functions are run multiple times, as I saw a case in the NVIDIA server where someone did not have pending updates in the start, but when driver download took some time and by the time it was over there were pending updates, causing headaches.
Users can set higher security settings via GPO to enforce higher password standards, which will mean our user will not be created.
We have a complicated password that is reasonably complex that fulfills most rules, while also making sure our user we plan to use was created correctly in VerifyDDUAccountCreated()
I experienced a situation with a user in Belarus where his keyboard appeared to be producing ASCII characters, but they were characters that looked like ASCII, which meant the "Do it" and "I understand" prompts seemed to not be being answered, so AutoDDU kept asking them.
We only ask for the above prompts if a user's Windows install is in English, this is checked in BadLanguage() , and if it is not in english instead of the above mentioned prompt there is a simple prompt to do enter in HandleOtherLanguages()
While common sense would indicate a GPU being supported would be easy to find out, that is anything but true. In my testing I found the following GPUs that are misleading:
GT730: Has a GF108 (Fermi) and a GK208 (Kepler) variant.
GT625: Has a GF108 (Fermi) and a GK107/GK208 (Kepler) variant.
GT640: Has a GF116 (Fermi) and a GK107/GK208 (Kepler) variant.
GT645/620 is a Fermi card, even though all other 600 series are Kepler variants (with the exception of the above)
GT705 has a GF119 (Fermi) and a GK208 (Kepler) variant.
GTX745, GTX750 and GTX750 Ti are Maxwell, even though all other 700 series are Kepler variant (with the exception of the above)
GT1030: Has a GK107 (Kepler) and a GP108 (Pascal) variant.
All-in-one desktops are known to feature Mobile GPUs, which would make them fall under a different (and often shorter) support cycle.
GT810M/GT820M are Fermi cards.
GT825M/GT870M/GT880M are Kepler cards.
GT920M is a Kepler card.
Most cards in the 800M series have multiple variant with varying architectures (A card in this series can be Fermi, Kepler or Maxwell).
Initially AutoDDU kept a database of these known problematic GPUs, but this became unfeasable to maintain, now we instead store a database of drivers and their supported GPU PCI IDs in CommonSoftware, and then load the JSONS and look for a driver that works for the GPU in question. If one is not found then PCI-IDS is checked for the architecture and we use the GFE API in FindOutOfBranchDriver(vendorid_deviceid) to get a driver if it is not considered end of life.
If there is no GPU Driver installed then Windows provides useless information, only telling us it is a "Microsoft Basic Display Adapter"
AutoDDU uses the WMI API to manually get the PCI IDs and compare them against the above mentioned PCI-IDS Database to get the info we need to get some useful info on what we need to do.
If a user's battery dies inbetween an important step, all kinds of stupid crap can occur.
Check checkBatteryLevel() and only continue if above 40%, have to be careful, UPS creates false positives sometimes unfortunately.
If a user has Bitlocker setup where the encryption keys are on Microsoft's servers, upon restart and there being no internet Windows will ask the user to input their encryption key manually, and 9/10 the user doesn't even know Bitlocker is enabled, let alone knows their key.
Disable Bitlocker before we disconnect the internet for three reboots in suspendbitlocker()
If a user launches AutoDDU with little space remaining there's issues that are actually very hard to catch.
Check for free space being literally the first thing in get_free_space()
If we try to create a user profile that already exists this causes issues that can remain uncatched.
By default we just use the DDU name for our profile, but we check with findnottaken() to be sure it's not taken, and if it is we add a "U" to the name unless it is above the name limit established in BackupProfile().
This is why we have the "ProfileUsed" key in obtainsetting, because the name we use is not always certain.
A person can launch AutoDDU multiple times, causing all sorts of madness and permission issues which were SO MUCH FUCKING FUN TO TROUBLESHOOT BECAUSE THE LOG FILE WAS FOR SOME REASON HALF EMPTY LINES
This is handles in the singleinstance class stolen from stackoverflow, I don't know how it works, all I know is it works.
A person can have a bad DNS which cannot access github (most often the raw domain)
Implement own dns in download_helper which will force the use of 8.8.8.8 if an internet connection sales some times or user manually chooses it. This doesn't work with some VPNs that block other DNS, but those cases are easy to catch. Done by RandoNando
If a person has a dead network card in the system, when we try to disable it in WMI, WMI will keep us hanging waiting for a response for all eternity.
Launch WMI disabling a network card in its own individual thread with multiprocessing, and kill it if it exists for more than 10 seconds.
Kaspersky REALLY does not like the multiprocessing Python module.
Alert user about Kaspersky with IsKasperskyInstalled() is all I've done. Contributors welcome.
People can mess up Windows's default environment variables with powershell, causing us to fail when trying to run something in powershell.
Manually direct to powershell instead of depending on a user's environment variables to give it to us.
If a person does not have Edge or Internet Explorer, AutoDDU will fail to access some network requests
Move all of the requests needed to Github Actions and store it in CommonSoftware.