UPDATE:
The actual problem turned out to be the R-support component(s) slowly downloading in the background locking up the installation GUI
with no notification or warning show to the user as to what is
actually going on.
So it seems this "locked install problem" can be caused by installing several different components, at least by Python or R-support. As mentioned below, please check any available logs or event logs for clues.
In summary, options:
- Maybe try to unselect such components for install if you do not need them.
- If you need the components, leave the setup to complete, and check progress in log files as explained below. Verify Internet access (proxy?).
Stuck Download?
UPDATE: Did you see this blog? Looks like the setup tries to download and install the Python runtime, and this can take forever. Are you behind a proxy btw? No direct connection to the Internet? If so I suppose this could also cause further problems. Probably not the cause, but worth a mention.
Apparently you can check the following log file for progress for the installation:
%ProgramFiles%Microsoft SQL Server140Setup
BootstrapLogDATE_TIMERSetup.log
DATE_TIME in the above path must be converted to your valid values. For example: 20170804_162723 (date part and time part).
See this answer as well: SQL server 2016 installation freeze. You could also try the suggestion to deselect all components you do not need to prevent any background downloads?
General Debugging
Leaving in the general purpose debugging suggestions below.
Generic Advice: From experience I would create a new local admin user and try to install using that account. This is to avoid any "unclean" or special conditions that have occurred in your user profile or registry during regular Windows use. Might not do much, but sometimes it gets the job done with surprising ease. Worth a try I think.
Some Further Things: I wrote up a little check list a while back, I'll add it and see if it inspires some new ideas that can help you. See under "Core Deployment Problems". That first "check list" was condensed from a longer and somewhat excessive first writeup - one of those answers that unintentionally turned into a blog and maybe a hard one to read.
Logging: Did you check log files and / or event logs properly for clues as to what is happening? I find the best approach for deployment to enable logging for all MSI installations. The performance hit it triggers is minuscule compared to the benefit of having a real log-file always available when you suddenly need one. You can enable logging for all MSI files as explained on installsite.org (section: "Globally for all setups on a machine"). MSI log files will then just sit in your %TEMP% folder after installation. They have a random hex name, and you can flush them all regularly if you do not need them. You sort by modify date / time to find the latest one(s) created - obviously.
Jedi trick: You will want to go home and re-think your life if you don't enable logging for all MSI files. Moral of the story: MSI log files are cool. They are very verbose, but they are beautiful. There are some hints on interpreting them here (bottom).
与恶龙缠斗过久,自身亦成为恶龙；凝视深渊过久,深渊将回以凝视…
