Updated VS2019 - why exaclty do I need to reboot?
-
Yeah, yeah. I get it. Wondering why Windows needs to reboot if I fart in it's general direction is an exercise in futility. I get the technical comments. I just think back to that time when Bill was demonstrating USB device discovery and his machine blue screened... It shows that if you put enough lipstick on a pig, you still have bacon eventually.
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Windows locks executables (including DLLs) while they are in use. Because of this, in order to update shared components, the locks must be freed. While it's possible, there's no "clean" way to even determine who holds a lock that I know of (unless it was added to a more recent windows in which case I am wrong) so the safest thing to do is reboot. VS uses a lot of shared components. A lot of windows applications do, and generally, the larger/more complicated the application, the bigger your odds of having to reboot on update, because they typically use a lot of shared components increasing the odds that one of them is locked and the app needs to update it. This also applies to the various OS features and shell widgets and doodads, not just applications. I hope that clears it up.
Real programmers use butterflies
-
So I have an a$$ton of work going on. Multiple VMs zooming along, editors all over, yada yada. Converted a project from ancient VS to VS2019. I was prompted to update VS2019. Now I have this Installer prompt that says: "Success! One more step to go. Please restart your computer..." Why? Seriously, why do I need to reboot? It's just a holdover from the "reboot Windows" it might fix it history. Or is VS really doing things to the OS that requires me to reboot? I'm not being sarcastic here. Help me understand.
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Interesting question. I found the following. It suggests that windows locks the dlls because it is using the dll itself as a memory mapped file. So of course having that replaced while running would be bad thing. Sounds like a reasonable cause although I could not find other sources that back that up. c# - Why does the .NET framework lock dlls? - Stack Overflow[^]
-
So I have an a$$ton of work going on. Multiple VMs zooming along, editors all over, yada yada. Converted a project from ancient VS to VS2019. I was prompted to update VS2019. Now I have this Installer prompt that says: "Success! One more step to go. Please restart your computer..." Why? Seriously, why do I need to reboot? It's just a holdover from the "reboot Windows" it might fix it history. Or is VS really doing things to the OS that requires me to reboot? I'm not being sarcastic here. Help me understand.
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
So I have an a$$ton of work going on. Multiple VMs zooming along, editors all over, yada yada. Converted a project from ancient VS to VS2019. I was prompted to update VS2019. Now I have this Installer prompt that says: "Success! One more step to go. Please restart your computer..." Why? Seriously, why do I need to reboot? It's just a holdover from the "reboot Windows" it might fix it history. Or is VS really doing things to the OS that requires me to reboot? I'm not being sarcastic here. Help me understand.
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
All excellent points. I had not considered that VS2019 might have updated core OS components. I was tired :) That said, if VS2019 is updating core OS stuff, it should be in the standard patch rollout. Segmentation please. As someone else mentioned, it's probably a default in the install s/w. 1 point to MS: although they did not give me a "reboot later" button, I could X off the prompt and keep going. I guess my perspective was flavored on my most recent video card driver update from NVidea. Their install process messes with my screens (expected) but I did not have to reboot. I consider *any* driver pretty core to the OS. Thank you all
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
charlieg wrote:
Multiple VMs zooming along, editors all over, yada yada.
[...]
charlieg wrote:
Please restart your computer
The solution is to go all-in with VMs. If you run VS itself within its own VM, and it insists on rebooting, then you won't have to reboot the host OS, and drag along and interrupt whatever work the other VMs are doing. For years, I've had *nothing* on my host OS but the motherboard drivers, and the virtualization software (Hyper-V in my case). All my work is done inside separate VMs - one dedicated to SQL, another for VS2019, older ones with older versions of VS, another for "everything else" (Office, email, browsers, etc). That way reboots cause the minimal amount of disruptions. My host, at most, reboots once a month, on Patch Tuesday. I've had instances where I let the host wait for a reboot for a few months on end--right now it's still waiting to complete the setup for the February patches. Since I do nothing on the host, including no browsing, it's really at minimal risk and I don't worry as much about hurrying to patch that one as I might with any of the guest VMs. Could be Linux if I was so inclined. Bonus: Backing up is just a matter of copying .VHD files. Since there's nothing on the host, I don't even bother backing *that* one up--reinstalling the OS is pretty quick nowadays. My entire backup set is just a bunch of VHD files that can be managed like any other file with Explorer. Some of these have even been migrated to different physical machines over time. Extra bonus: Since the heavy work is all done in VMs, the host is warming up another room and I don't even have to hear its loud fans. On my desk in *this* room is a tiny, completely quiet Intel NUC, with 3 monitors, and it RDPs to the individual VMs.
It's been on my list to do for 2 years. I guess I should stop $itching and start doing.
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
Simplified garbage collecting.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
:laugh: truth
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
Windows locks executables (including DLLs) while they are in use. Because of this, in order to update shared components, the locks must be freed. While it's possible, there's no "clean" way to even determine who holds a lock that I know of (unless it was added to a more recent windows in which case I am wrong) so the safest thing to do is reboot. VS uses a lot of shared components. A lot of windows applications do, and generally, the larger/more complicated the application, the bigger your odds of having to reboot on update, because they typically use a lot of shared components increasing the odds that one of them is locked and the app needs to update it. This also applies to the various OS features and shell widgets and doodads, not just applications. I hope that clears it up.
Real programmers use butterflies
Didn't you just thank dave for saving you to type the same answer? :rolleyes: ;P :laugh:
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
charlieg wrote:
Multiple VMs zooming along, editors all over, yada yada.
[...]
charlieg wrote:
Please restart your computer
The solution is to go all-in with VMs. If you run VS itself within its own VM, and it insists on rebooting, then you won't have to reboot the host OS, and drag along and interrupt whatever work the other VMs are doing. For years, I've had *nothing* on my host OS but the motherboard drivers, and the virtualization software (Hyper-V in my case). All my work is done inside separate VMs - one dedicated to SQL, another for VS2019, older ones with older versions of VS, another for "everything else" (Office, email, browsers, etc). That way reboots cause the minimal amount of disruptions. My host, at most, reboots once a month, on Patch Tuesday. I've had instances where I let the host wait for a reboot for a few months on end--right now it's still waiting to complete the setup for the February patches. Since I do nothing on the host, including no browsing, it's really at minimal risk and I don't worry as much about hurrying to patch that one as I might with any of the guest VMs. Could be Linux if I was so inclined. Bonus: Backing up is just a matter of copying .VHD files. Since there's nothing on the host, I don't even bother backing *that* one up--reinstalling the OS is pretty quick nowadays. My entire backup set is just a bunch of VHD files that can be managed like any other file with Explorer. Some of these have even been migrated to different physical machines over time. Extra bonus: Since the heavy work is all done in VMs, the host is warming up another room and I don't even have to hear its loud fans. On my desk in *this* room is a tiny, completely quiet Intel NUC, with 3 monitors, and it RDPs to the individual VMs.
I do more or less the same, but not in a dedicated maschine... One VM for serious staff Another one for surfing / searching non whitelisted places Another one for... VS Community (for private pet projects) is in the main OS though. But as I don't use it so much last time... Additionally, I am someone that switches the PC off almost every day, so I don't really care about the reboots.
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
All excellent points. I had not considered that VS2019 might have updated core OS components. I was tired :) That said, if VS2019 is updating core OS stuff, it should be in the standard patch rollout. Segmentation please. As someone else mentioned, it's probably a default in the install s/w. 1 point to MS: although they did not give me a "reboot later" button, I could X off the prompt and keep going. I guess my perspective was flavored on my most recent video card driver update from NVidea. Their install process messes with my screens (expected) but I did not have to reboot. I consider *any* driver pretty core to the OS. Thank you all
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
charlieg wrote:
1 point to MS: although they did not give me a "reboot later" button, I could X off the prompt and keep going.
That's probably an error, not a feature :rolleyes: :-D
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
All excellent points. I had not considered that VS2019 might have updated core OS components. I was tired :) That said, if VS2019 is updating core OS stuff, it should be in the standard patch rollout. Segmentation please. As someone else mentioned, it's probably a default in the install s/w. 1 point to MS: although they did not give me a "reboot later" button, I could X off the prompt and keep going. I guess my perspective was flavored on my most recent video card driver update from NVidea. Their install process messes with my screens (expected) but I did not have to reboot. I consider *any* driver pretty core to the OS. Thank you all
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
"Reboot later" - yes, thank goodness for that option. Far too many apps still ask you to "Reboot to complete the installation" but I find it's rarely actually necessary. Only today I installed WireShark (not used it before) and it asked to reboot. Not convenient right now, so "reboot later" and just use the thing. Seems to work 100% OK; certainly did what I needed it to do today. I'll reboot in a couple of weeks or so, probably.
-
Didn't you just thank dave for saving you to type the same answer? :rolleyes: ;P :laugh:
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
Indeed! :laugh:
Real programmers use butterflies
-
All excellent points. I had not considered that VS2019 might have updated core OS components. I was tired :) That said, if VS2019 is updating core OS stuff, it should be in the standard patch rollout. Segmentation please. As someone else mentioned, it's probably a default in the install s/w. 1 point to MS: although they did not give me a "reboot later" button, I could X off the prompt and keep going. I guess my perspective was flavored on my most recent video card driver update from NVidea. Their install process messes with my screens (expected) but I did not have to reboot. I consider *any* driver pretty core to the OS. Thank you all
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Replace an exe while it is running, then we talk :) Or better yet, mail MS on how they should replace running executables. Same goes for libraries in use by several exe's. Try replacing those, while they execute :D
charlieg wrote:
I guess my perspective was flavored on my most recent video card driver update from NVidea. Their install process messes with my screens (expected) but I did not have to reboot. I consider *any* driver pretty core to the OS.
You wanna pay NVIDIA pricing for every component on your PC? I can do the same; just TCP/IP communication on the localhost, instead of coupling. That'd be the technical option, instead of downloading crap and claiming it to be an update, just to show some ads and the line that "umpteen devices use Java.", without any real changes. I hate the Java Updater a lot more than Windows Updates that can be explained.
Bastard Programmer from Hell :suss: "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
charlieg wrote:
Visual Studio is an application. It has no business needing to reboot.
It does if you're using C++ or other shared components or runtimes that are in use by other applications. Those files cannot be replaced until they are released by the other applications using them. At the time of installation, the files are locked, so during the run of the installer, they are queued up to be replaced on the next O/S start since that's the only time the O/S can guarantee they will not be in use by other applications.
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave KreskowiakDave Kreskowiak wrote:
or other shared components or runtimes that are in use by other applications. Those files cannot be replaced until they are released by the other applications using them.
The only question I have is: Have they ever looked into UNIX/Linux/Minix code (it is open source)? Not that I state that *nix OSes are better in all possible ways, but still there is room for learning...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
-
Replace an exe while it is running, then we talk :) Or better yet, mail MS on how they should replace running executables. Same goes for libraries in use by several exe's. Try replacing those, while they execute :D
charlieg wrote:
I guess my perspective was flavored on my most recent video card driver update from NVidea. Their install process messes with my screens (expected) but I did not have to reboot. I consider *any* driver pretty core to the OS.
You wanna pay NVIDIA pricing for every component on your PC? I can do the same; just TCP/IP communication on the localhost, instead of coupling. That'd be the technical option, instead of downloading crap and claiming it to be an update, just to show some ads and the line that "umpteen devices use Java.", without any real changes. I hate the Java Updater a lot more than Windows Updates that can be explained.
Bastard Programmer from Hell :suss: "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
Point taken. I've noticed I have to login to get the update now. I'm not even sure why I bother. It's not like I need the latest update for my 1070 chip in my laptop - 4 years old - and it's not changing. Biggest issue for me is sometimes VMWare Workstation gets wonky at times with driver updates. And VMWare never addresses them. My point is that when MS wants to roll out updates, we all know a reboot is coming, so we plan for it. If I install VS2019 (which I just did) last week, it did not ask me to reboot my machine. If I update, I do? For that matter, if a VS2019 update includes all sorts of other components, then it should *say* so as a common courtesy. I'm agreeing with the other poster, I think they just say it to say it.
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
So I have an a$$ton of work going on. Multiple VMs zooming along, editors all over, yada yada. Converted a project from ancient VS to VS2019. I was prompted to update VS2019. Now I have this Installer prompt that says: "Success! One more step to go. Please restart your computer..." Why? Seriously, why do I need to reboot? It's just a holdover from the "reboot Windows" it might fix it history. Or is VS really doing things to the OS that requires me to reboot? I'm not being sarcastic here. Help me understand.
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Taking a guess a kernel driver that supports the debugger has been updated, therefore mandating the restart.
Software Zen:
delete this; -
Replace an exe while it is running, then we talk :) Or better yet, mail MS on how they should replace running executables. Same goes for libraries in use by several exe's. Try replacing those, while they execute :D
charlieg wrote:
I guess my perspective was flavored on my most recent video card driver update from NVidea. Their install process messes with my screens (expected) but I did not have to reboot. I consider *any* driver pretty core to the OS.
You wanna pay NVIDIA pricing for every component on your PC? I can do the same; just TCP/IP communication on the localhost, instead of coupling. That'd be the technical option, instead of downloading crap and claiming it to be an update, just to show some ads and the line that "umpteen devices use Java.", without any real changes. I hate the Java Updater a lot more than Windows Updates that can be explained.
Bastard Programmer from Hell :suss: "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
Eddy Vluggen wrote:
Replace an exe while it is running, then we talk
Well, it's possible to rename an executable while it is running. This is how our desktop apps get updated...also makes rolling back simple if required. :)
"Go forth into the source" - Neal Morse "Hope is contagious"
-
Dave Kreskowiak wrote:
or other shared components or runtimes that are in use by other applications. Those files cannot be replaced until they are released by the other applications using them.
The only question I have is: Have they ever looked into UNIX/Linux/Minix code (it is open source)? Not that I state that *nix OSes are better in all possible ways, but still there is room for learning...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
Kornfeld Eliyahu Peter wrote:
Have they ever looked into ... there is room for learning...
BWAHAHAHAA! "Learning" and "Microsoft" in the same sentence! You must be new here. :laugh:
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave Kreskowiak -
When I start an OS update, I think it's reasonable that I might have to reboot. It's the OS. Visual Studio is an application. It has no business needing to reboot. Or maybe MS developers suck (sarcasm). Still wondering why.
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
The last time I looked into it, it was because Visual Studio likes to run background services - you know, those notifiers that let you know "there's an update waiting". I got stuck in a loop once where the service actually got stuck, and was preventing the rest of an update from running and I got into a reboot-find-directory-delete-race, to try to erase the service before it auto-started. Took a couple of tries as I recall...
-
Replace an exe while it is running, then we talk :) Or better yet, mail MS on how they should replace running executables. Same goes for libraries in use by several exe's. Try replacing those, while they execute :D
charlieg wrote:
I guess my perspective was flavored on my most recent video card driver update from NVidea. Their install process messes with my screens (expected) but I did not have to reboot. I consider *any* driver pretty core to the OS.
You wanna pay NVIDIA pricing for every component on your PC? I can do the same; just TCP/IP communication on the localhost, instead of coupling. That'd be the technical option, instead of downloading crap and claiming it to be an update, just to show some ads and the line that "umpteen devices use Java.", without any real changes. I hate the Java Updater a lot more than Windows Updates that can be explained.
Bastard Programmer from Hell :suss: "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
Eddy Vluggen wrote:
Replace an exe while it is running, then we talk :)
How about the same way everything else does - Close the program, launch another one that re-names the original, then re-launch it. Imagine you had to reboot your PC any time Steam (Or any of its included games), or Windows Defender definitions or etc. updated. You'd be rebooting half a dozen times a day!
-= Reelix =-
-
So I have an a$$ton of work going on. Multiple VMs zooming along, editors all over, yada yada. Converted a project from ancient VS to VS2019. I was prompted to update VS2019. Now I have this Installer prompt that says: "Success! One more step to go. Please restart your computer..." Why? Seriously, why do I need to reboot? It's just a holdover from the "reboot Windows" it might fix it history. Or is VS really doing things to the OS that requires me to reboot? I'm not being sarcastic here. Help me understand.
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
