How to avoid OS reboot prompt when installing the .NET Framework 3.5 on Windows Vista


Description of the issue


When installing the .NET Framework 3.5 or Visual Studio 2008 on Windows Vista RTM, some people have noticed that a Windows Update dialog box pops up to indicate that the system must be restarted in order to complete installation of OS updates.  The dialog box looks something like the following:



What is happening behind the scenes


Windows Vista includes the .NET Framework 2.0 and 3.0 as OS components.  The .NET Framework 3.5 includes Windows Vista OS hotfix packages for the .NET Framework 2.0 SP1 and 3.0 SP1, and both of these hotfixes require reboots in order to complete installation.  The .NET Framework 3.5 setup wrapper contains logic to handle these reboot requests and notify the user, but the Windows Update service in Windows Vista also runs in the background and listens for this type of reboot request and pops up dialog boxes like this to notify the user that a reboot is needed as the result of installing an OS update.


Unfortunately, if this dialog appears during the .NET Framework 3.5 setup or during installation of a product that installs the .NET Framework 3.5 as a prerequisite (such as Visual Studio 2008), and the user chooses to restart using the Restart Now button on this dialog, it can cause the system to reboot even if the .NET Framework 3.5 or Visual Studio 2008 setup is still running.  This can leave the system in an unknown state if these setups are installing something at the time of the reboot.


How to work around this issue


The Visual Studio 2008 readme will include an item suggesting that the user dismiss or ignore this Windows Update dialog if it is seen during .NET Framework 3.5 or Visual Studio 2008 setup.  However, the readme is not always easily found by end users, and this issue can potentially happen for any application that includes the .NET Framework 3.5 setup as a prerequisite on Windows Vista or during unattended deployment of the .NET Framework 3.5.


You can programatically prevent this dialog from appearing when deploying the .NET Framework 3.5.  This logic can be included in the script used for unattended deployment or within a setup process that includes the .NET Framework 3.5 as a prerequisite.


Use Windows Update Agent (WUA) APIs to pause the Windows Update service


To implement this solution, whatever script or process you are using to launch the .NET Framework 3.5 setup will use the Pause and Resume APIs on the IAutomaticUpdates interface in the Windows Update Agent (WUA) API set to temporarily pause and resume Windows Update functionality on the system.


You can use steps like the following to accomplish this:



  1. Call the Pause API to pause the Windows Update service
  2. Install the .NET Framework 3.5
  3. Reboot the system if the .NET Framework 3.5 setup returns exit code 3010
  4. Call the Resume API to resume the Windows Update service if the .NET Framework 3.5 setup does not return 3010

If you call Pause without calling Resume, the operation will eventually time out (the default time out value is 8 hours).  Rebooting the system will also cause the Windows Update service to resume without needing to call the Resume method.


<update date=”12/13/2007″> Removing option suggesting that users disable the wuauserv service to workaround this issue.  Doing this can cause failures during .NET Framework 2.0 SP1 or 3.0 SP1 installation on Windows Vista and should not be used.  The valid workarounds are to ignore the reboot prompt or use the WUA Pause and Resume APIs </update>


 

Comments (33)

  1. willdean says:

    If I read this right, this is a catasrophe, isn’t it?  

    No one can safely deploy the 3.5 framework with their applications without adding this custom code to their installer?

    Surely the 3.5 installer is the place to be including the code to inhibit the OS behaviour?

    Framework deployment is still the biggest psychological barrier to shipping .NET applications – why would MS inflict this kind of nightmare on us all, when it could have been dealt with by the framework installer?

  2. Hi WillDean – I think calling this scenario a "nightmare" or a "catastrophe" is too strong of a statement.  The reboot dialog that appears in this scenario does not automatically cause a reboot – it only reboots if the user clicks the Restart Now button.  In many cases, users are not watching the system closely enough to notice that dialog, or they will not choose to restart with that dialog because they realize that another setup is running.

    Ideally, the .NET Framework 3.5 setup would contain this workaround logic, but unfortunately the issue was found too late in the beta process in order to get it fixed in time.

    One important note – this issue will only affect systems that do not already have the .NET Framework 2.0 SP1 and/or 3.0 SP1 installed.  Future hotfix rollups and service packs for Windows Vista  will more than likely include 2.0 SP1 and 3.0 SP1, and therefore will not ever run into this issue.

  3. willdean says:

    But haven’t you just described the nightmare scenario?

    1. Application installer starts 3.5 framework install

    2. 3.5 installer installs 2.0SP1 and 3.0SP1 and then starts to install 3.5

    3. User notices OS reboot message and presses OK

    4. Machine reboots in the middle of 3.5 install

    5. Upon restart, machine has broken 3.5 install – I would imagine that there’s a very high risk that this broken 3.5 install will prevent the 3.5 install running again – or is that not the case?

    If it is, then as a 3rd party developer it’s now my problem to get the appropriate cleanup tools onto the end-user’s machine to allow the 3.5 install to be cleaned-up and retried.

    And all this because the poor user agreed to a suggestion that the OS made to them?

    I dread to think how bad your dreams must be if this *isn’t* a nightmare.   Let’s hope the framework SP’s are pushed as critical updates as quickly as possible.

    Or have I misunderstood the whole thing?

    Will

  4. Hi Willdean – Yeah, I agree that the worst case scenario here is a nightmare, but I don’t think it is a very likely end user scenario overall, which is why I don’t think that I’d call it a "nightmare" overall.  For example, if I initiate a setup on my system, I am not going to respond to a reboot request not displayed by that setup until after the setup finishes.  (or maybe I’ve just been working with setups too long and have gotten less scared of issues like this over time)

    In addition, the Postpone button appears to be the default button on this OS reboot prompt, so users are not too likely to accidentally press Enter and cause a reboot to happen.  Finally, the reboot prompt will happen after installing 2.0 SP1 and 3.0 SP1, but the time that it takes to install the remaining part of the .NET Framework 3.5 is relatively fast (1 minute or less on most of the systems I’ve seen), so the user would have to be actively looking for this dialog and respond to it pretty quickly to fall within the time window required to put the system in a bad state.

    Depending on the exact time when the reboot is initiated out from under the .NET 3.5 setup, it may or may not be recoverable by simply re-running .NET 3.5 setup.  From what I’ve seen in the past, nearly all cases are recoverable without needing to resort to cleanup tools, etc.

    I definitely agree that something like this could have been handled better within .NET 3.5 setup, but unfortunately that isn’t the case, so I wanted to post a warning just in case folks run into this type of issue in their .NET 3.5 deployment scenarios.  I think it is something worth keeping in mind but not necessarily something to panic about.

  5. Kevin Dente says:

    Sorry, Aaron, but I agree with Will. This is a horrible bug that WILL bite people in the butt. How do I know? Well, partly because I encountered this exact bug when installing Beta 2. It hosed my machine (yes, I clicked reboot now – partly because the install was taking so long and with so little feedback). And I’m a professional software developer.

    I really don’t think that taking the optimist approach and counting on people to be smart enough to not click the button is a good move. People will do it, I guarantee. You’re fooling yourself if you think they won’t.

  6. Hi Kevin Dente – I’m definitely not trying to say that it won’t ever happen – I’ve seen repeatedly in the past that as long as the code path is reachable some percentage of people will hit it over time.  I also wasn’t intending to come across as overly optimistic.  I was simply trying to point out some of the mitigations that I think make this problem not likely to affect a large number of people in the grand scheme of things.  The mitigations I point out don’t mean that the issue won’t ever happen, but I think they do mean that calling this scenario a nightmare or a catastrophe in a general sense is a bit too strong.

    That doesn’t imply that it could be a nightmare for a specific machine where a premature reboot does occur.  However, even in cases I’ve seen where that happened so far, re-running .NET 3.5 setup allowed the system to recover.  I also realize that this type of smooth recovery won’t be possible 100% of the time, but that is also true for any number of other possible points of failure during any product installation.

    It would definitely be ideal if .NET Framework 3.5 setup handled this behind the scenes.  Unfortunately, it does not.  As a result, other types of mitigations, including further education about the issue via readmes and blog posts have to be considered.  That was the intent of this blog post – to try to help people who will be deploying the .NET Framework 3.5 more aware of this potential issue.

    One other thing I should add – if you run into the error scenario that is possible as a result of this issue, I strongly encourage you to report it as a bug on the Connect site (http://connect.microsoft.com/visualstudio) to help the .NET Framework setup team get a better understanding of how often this issue happens "in the wild" – this can help lead to improvements in future versions of the .NET Framework installer.

  7. willdean says:

    Kevin, I think you and I live in a different world to Aaron.

    If I auto-updated 100000 copies of this to one of my clients’ retail user-base next week (of course, I won’t), I don’t think that readme.txt ‘education’ or filing bugs on Connect are going to be much comfort.  

    If 1% of those users click ‘reboot’ when they’re asked to (aren’t we trying to train them to obey security instructions?) and 1% of them subsequently have install problems, I shall still lose a week’s-worth of time trying to help people on the other side of the world get their computers going again.

    The sad truth for MS is that, of course, for applications like that one, which absolutely HAVE to install and run without any pain, we use statically-linked MFC/ATL/C++, and we don’t use MSI, either.

    I *love* programming with C#/.NET, but I suspect I’m not alone in thinking that it would be one hell of a risk in the wild for a high-volume end-user deployment.  That there are screw-ups like this being shipped 4 versions of the framework into the whole .NET thing makes me certain that I care more about this kind of stuff than MS do.

    You guys know what the bug is, and know what the fix is *BEFORE* you’ve even shipped the product, but you’d rather make it my problem than deal with it yourselves.

  8. bgreenberg says:

    I’m assuming this problem exists in the beta 2 redistributable.

    Is it slated to be fixed in the official release?

  9. Hi Bgreenberg – This issue exists in the beta version and unfortunately is not slated to be fixed in the final release either.

  10. bgreenberg says:

    I don’t want to pile on, but my team ships a mass marketed consumer package that depends on .NET.  We currently install the .NET 2.0 redist, if required, as the first phase in our installer.  We have some other 3rd party dependencies as well.

    In order to ensure smooth installation, we must trap ALL reboot requests and prompt the user in a way that makes sense in our installer flow.  If there is any possibility for a premature reboot, this becomes a "very serious issue," if not a nightmare, for our support team.  As others have mentioned, I am disappointed that the .NET team allowed this one out the door.

    That said, thank you for thoroughly explaining the issue and providing a workaround.  Does anyone know if there is an easy way to use the WUA API via MSI custom action?

  11. Aaron Stebner reports an issue (some commenters call it a &quot;nightmare&quot;) in the .NET Framework

  12. Si se pot descarca de pe MSDN . MrSmersh adauga un discleimar "handle with care" din cauza unei probleme

  13. mech9t8 says:

    This is clearly a bug that every commenter here would consider a RELEASE BLOCKER.

    At the very least I would expect a sample project with the necessary workaround code.

    Releasing a bug like this with nothing but an entry in the readme and a blog post is nothing sort of shameful.  Who knows what kind of damage or unexpected results can happen from all the service-manipulating workaround code developers are going to have to put into their installers?

    Of course, I don’t know what’s worse, that the .NET Framework doesn’t stop the reboot message or the Windows installer can’t handle a reboot request without borking a user’s system.  Considering how incredibly over-engineered the whole system is and how it runs with SYSTEM-level access I would expect it to be more robust.

    This "it’s not that bad and there are workarounds" seems indicative of the attitude in the recent Windows Update controversies and really among the whole Vista release.  Sloppy and unprofessional, Microsoft.

    (Nothing against you, Aaron, you’re probably as upset about this as we are and are stuck taking the flack since you’re the one with helpful blog.)

  14. Batgar says:

    The nightmare scenario is alive and well. There is no .NET Framework 2.0 SP1 or .NET Framework 3.0 SP1 install package available for Windows Vista.

    As an app dev I will be relying on the .NET Framework 3.5 installation / bootstrapper to do the proper installation.

    Now that I have to code workarounds within my installation for Vista, this is a huge barrier to .NET Framework 3.5 acceptance / installation for my application.

  15. Jon Galloway says:

    Visual Studio 2008 is out! I’ve upgraded three machines (two Vista, one XP) from Beta 2 to RTM, then

  16. You’ve been kicked (a good thing) – Trackback from DotNetKicks.com

  17. JudahGabriel says:

    Wow, this is a very serious bug, Aaron. Please work with the folks there to fix this.

    I’ve opened a bug on MS Connect:

    https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=313381

    Folks, please vote for this an get this serious problem fixed.

  18. peterchen says:

    Aaron,

    with all respect (and kudos for discussing this), I think your assesment is removed from end user reality.

    The typical end user cannot tell apart "Funny Photos Setup" from "Windows Update". He’s installing his new toy, a message pops up to "reboot to finish installing", and if he does, he’s probably screwed.

    The typical support call is "Your software broke my system", and you will be lucky to figure out that it happened during installation.

    It’s a hard job to train end users to actually reboot their system when a setup or Windows Update says "reboot". That impulse might actually a few hapless helpdesk souls, but next time our user will say "some computer guy told me not to reboot when this comes up". Some 3rd party vendors will work around by telling their users to deactivate Windows Update.

    Microsoft expects one billion Windows computers next year. This is a component that will be redistributed by aspiring coders that wanted to "creating fun, cool projects that run on Windows" (quote MS web site), not fix installers.

    This is the setup for a system update getting hairy with a system component that is core to security and stability.

    I know these things aren’t easy to get right. But if Microsoft doesn’t think it’s important, why should "we" – 3rd party developers?

    I understand that your position is no official Microsoft statement, and I assume the bug is not your fault. I just wish you understand that there are more than just the technical issues.

  19. Hi Peterchen – I definitely understand the possible user confusion caused by this issue.  The worst part is that this issue can affect any application that installs the .NET Framework 3.5, not just developer tools like Visual Studio.  I’ve communicated all of the feedback collected on this blog post to the .NET Framework setup team, but there’s not a lot more I can do in the meantime.  I’m going to try to work with them to create some sample code to implement the WU pause/resume APIs described above.

    Also, I’ve experienced this issue on a couple of systems since the time that I posted my original comments about this issue, and it is worse then I initially anticipated because the time it takes to install 2.0 SP1, 3.0 SP1 and 3.5 on Windows Vista RTM can be really long.  That makes it more likely that folks will notice the reboot prompt from Windows Update even if they’re not actively watching their systems during installation of 3.5.  The main piece of good news is that this issue won’t affect systems that have Vista SP1, but of course that won’t be available for a few more months, plus it doesn’t provide a solution for applications that want to only require Vista RTM.

  20. jsn_segal says:

    I’ve been working on a simple application to implement the WUA Update/Resume workaround for my installer. Here’s how it works:

    1. Check for pending reboots. If A reboot is required, alert the user and quit.

    2. Check for WUA installations in progress. If one is in progress, alert the user and quit.

    3. Pause the WUA

    I’m not currently bothering to resume, since this should happen in 8 hours anyway (or the next time the user reboots).

    The problem is that, while the IUpdateInstaller interface’s IsBusy property allows me to make sure no WUA installations are running, I don’t see any way to determine whether or not a "download and immediately install" cycle is currently in its download phase. This means that if an update is being downloaded when my installer starts, the WUA may begin installing it and interrupt my installer despite all the precautions.

    Is there a way to detect WUA downloads in progress (other than the ones you initiate) or prevent them from installing after the download completes? (I hoped that using Pause would do the latter, but it doesn’t seem to.)

  21. Hi Jsn_segal – I had expected that the Pause method would prevent Automatic Updates from proceeding to install an update after it got done downloading in this type of scenario.  I will try to ask around and see if I can find someone who works with the WUA APIs more closely to see if there are any options for handling that scenario.

  22. Hi Jsn_segal – I discussed this scenario with a few folks who work on the WUA APIs and Automatic Updates here at Microsoft.  They indicated that there is not a way to detect that an Automatic Updates download is in progress, but that Automatic Updates will not proceed to the installation phase for an update if Pause was called.

  23. Marshall says:

    My setup application has to pre-install the .NET Framework 3.5 and ran into the same issue that the reboot prompt dialog shows up.

    Using the IAutomaticUpdates::Pause and IAutomaticUpdates::Resume, the dialog disappears but even worse, it will reboot while my setup application is still running without any warning.

    I called the IAutomaticUpdates::Pause at the first beginning of the setup application and called the IAutomaticUpdates::Resume at the end of the setup application. The rebooting happens before calling the IAutomaticUpdates::Resume.

    Can anyone tell me how to work arround this issue? It has been a testing blocker right now.

    Thanks!

  24. test says:

    error when installing vs2008 on vista

  25. Another puzzled tech says:

    Hello all,

    Does anyone know if I may run into this same sort of thing installing .NET 4.0 full?

    Should I presume that this will certainly show up if the 4.0 is installed unto a machine that has not even the 3.5 version?

  26. Hi Another puzzled tech – It is possible that the .NET Framework 4 will require a reboot in the way described in this blog post.  It is not guaranteed to happen 100% of the time, so you shouldn't assume that it will certainly show up.  However, your installation process should include logic to check the return code from the .NET Framework setup process and prompt the user to reboot if the return code is 3010.

  27. Adam_Mys says:

    I went to update my .NET framework 4 today as a part of an update to a program. It detected that it doesn't require an update as it is on the most current version. It did however prompt a restart and now my machine restarts perpetually. It will turn on tell me that .NET framework is up to date and as soon as I close the prompt it will load my desktop and prompt me about the inevitable restart. I am at a loss.

  28. Hi Adam_Mys – I haven't heard of this type of repeated rebooting behavior before.  What version of Windows is on your computer, and are you using Windows Update to update the .NET Framework?

    If you haven't yet, I'd suggest trying to install the .NET Framework 4.5 (from http://www.microsoft.com/…/details.aspx) or the .NET Framework 4.5.1 (from http://www.microsoft.com/…/details.aspx) to see if that helps resolve this issue.  The .NET Framework 4.5 and 4.5.1 are both in-place upgrades for the .NET Framework 4 and they contain the latest updates for the .NET Framework 4.

  29. Bryan Albert says:

    It looks like Windows 10 no longer supports pausing the Windows Update service (msdn.microsoft.com/…/aa385835(v=vs.85).aspx). When running on Windows 10 Pro Insider Preview build 10130, my installer was hung for two minutes while it tried to create the IAutomaticUpdates object, which resulted in an exception. If we use the /norestart switch and check for the 3010 return code from the .NET installer NDP452-KB2901954-Web.exe, for example, and handle the restart ourselves, do we know that Windows 10's Windows Update service will not prompt the user to restart if the .NET 4.5.2 install requires a restart? Or, if in the future, we install a newer .NET version, that it won't?

    For that matter, is the core issue of this blog post, Windows Update offering to reboot after a .NET upgrade during someone's chained install, still an issue? Should our setup bootstrappers still be pausing the Windows Update service when installing .NET updates as a prerequisite on Windows 7, 8, and 8.1?

  30. Hi Bryan Albert – Windows 10 includes the .NET Framework 4.6 as a part of the OS, and the .NET Framework 4.6 is an in-place upgrade for all older versions of the .NET Framework in the .NET Framework 4 family (in other words, the .NET Framework 4, 4.5, 4.5.1 and 4.5.2).  As a result, your installer should not attempt to install the .NET Framework 4.5.2 on Windows 10 because the .NET Framework 4.6 is already present.

    The underlying issue of Windows Update popping up a restart dialog when an application setup program installs a Windows hotfix behind the scenes is still a potential problem.  I've sent your feedback and the MSDN link to the .NET Framework setup team here at Microsoft so they can evaluate options for future releases of the .NET Framework.