Home Dashboard Directory Help
Search

SQL Server 2008 R2 Cumulative Updates won't install with DotNet Framework 4.0.30319 by Joseph Leathlean


Status: 

Active


13
0
Sign in
to vote
Type: Bug
ID: 573043
Opened: 7/3/2010 8:24:11 PM
Access Restriction: Public
4
Workaround(s)
view
8
User(s) can reproduce this bug

Description

When trying to install either CU1 or CU2 on a 2008R2 x64 server where DotNet Framework 4 has been installed I get a error message that the "Managed SQL Server Installer" has stopped working.

I had one server that would install the update - and I realized that it hadn't been updated with V4 of DotNet.

I proceeded to test my theory by renaming the v4.0.30319 directories in both C:\Windows\Microsoft.NET\Framework and FrameWork64 to 'Bad'. Once I did that - the installer proceeded to work as it reverted to an earlier version of DotNet since it couldn't find 4.0...
Details
Sign in to post a comment.
Posted by Steve Beaumont on 2/6/2012 at 8:48 AM
Over a year later and this problem still exists.

Is there a solution ever planned to resolve this?

Advising uninstall of .Net 4.0 or running the install from local media is not acceptable, especially when trying to automate builds.

As per the comment below, reproducing this is easy, build a new server, fully patch it, including .Net 4.0 and then try installing SQL from a file share = landingpage.exe error
Posted by PrakashHeda on 12/1/2011 at 5:14 PM
I hit this issue and after 1 week figured it could be the bug which is delaying whole implementation effort for our future products golive date

I have SQL 2008 R2 + SP1 + CU3 sliptreamed build and if you install dot net 4 than automated install does not work (I believe manual will not work as well, but thats not the point so why worry)

Automated install is only trying to install bids component (nothing else), still fails and it happenes on windows 2008 SP2 (Non R2) VM image


On top of that there are so many threads talking about ACL error why it failed nothing brings me to this page until I figured it was dot net compatibility issue and search for "dot net 4.0 and sql 2008 r2 issue"

What I fail to understand is issue is open for over a year and product team has not yet acknowledge it as bug, its a piece if cake to reproduce this issue than whats taking so long?? Why product team is asking others to reproduce this issue when they can reproduce it themselves? if its not getting reproduced than let me know and I can help provide video steps to create a plain vm with w2k8R2 VM and automated install to see issue)
Posted by JakeLD on 11/2/2011 at 3:02 PM
The problem persists even with SP1 slipstreamed. Any news on this issue ?

I will try adding CU3

http://support.microsoft.com/kb/2591748
Posted by Randy in Marin on 6/20/2011 at 5:24 PM
Seems like a catch-22. Setup can't run enough to display an error that it can run?
Posted by Randy in Marin on 6/20/2011 at 5:19 PM
It appears it might be tighter permissions with .Net 4 and network installs. I added a work arround for granting full trust to the share.
Posted by Joseph Leathlean on 2/26/2011 at 8:58 PM
I just noticed the comment around the network.

I tested by copying the files locally - and you are correct - it will install then.

Posted by Joseph Leathlean on 2/26/2011 at 8:54 PM
Just tried SQL 2008 R2 CU 4 on a Windows 7 Laptop with .NET 4 installed. Still fails unless I rename the directory.

And again - THERE ARE NO LOG FILES GENERATED. The setup doesn't even get that far. It crashes before that point...
Posted by Geoff Boulden on 12/30/2010 at 8:02 AM
This also occurs on X86 servers
Posted by Microsoft on 12/27/2010 at 4:49 PM
Hi Joseph,
We looked into this issue and it looks like this problem can occur when running the extracted CU package from a network share. Can you try to copy the CU package or the extracted files locally and then run setup?

Thank you,
Mohamed El Hassouni [SQL Server]
Posted by Joseph Leathlean on 11/24/2010 at 7:48 PM
This is still not fixed as of SQL 2008 R2 Cumulative Update 4...

Very annoying...
Posted by Randy in Marin on 7/30/2010 at 4:13 PM
I had the same issue running a discovery report on a fresh OS build. There was no log file. There was also no SQL Server folder to contain the log file. This was in the event log.

Application: setup100.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.Security.SecurityException
Stack:
at Microsoft.SqlServer.Chainer.Setup.Setup.DebugBreak()
at Microsoft.SqlServer.Chainer.Setup.Setup.Main()

After I uninstalled "Microsoft .NET Framework 4 Extended" and "Microsoft .NET Framework 4 Client Profile", the discovery report was fine.

I'm using a slipstream 10.0.2789 STD.

Machine Properties:
Machine name:                 BUSTEST-SQL
Machine processor count:     1
OS version:                    Windows Server 2008
OS service pack:             Service Pack 2
OS region:                     United States
OS language:                 English (United States)
OS architecture:             x64
Process architecture:         64 Bit
OS clustered:                 No

Posted by Joseph Leathlean on 7/30/2010 at 2:25 AM
I now have this same issue with SQL Server 2008 SP1 when trying to apply CU 9.

I was able to confirm that no log files are created...
Posted by Joseph Leathlean on 7/22/2010 at 6:51 AM
There are no log files generated.

The error message occurs as the setup file is starting up and before any dialog boxes are presented.
Posted by Microsoft on 7/21/2010 at 12:08 AM
Thank you for reporting this issue. Could you attach the setup log files located at %programfiles%\Microsoft SQL Server\100\Setup Bootstrap\LOG?

Thank you,
Mohamed El Hassouni [SQL Server]
Sign in to post a workaround.
Posted by Allan Gandelman on 5/2/2012 at 12:11 PM
It works if you run the files locally, instead of a network share
Posted by Randy in Marin on 6/20/2011 at 5:17 PM
For a network install, try adding full trust to the share containing the install.

C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\caspol.exe -m -ag 1 -url "file:\\share\sqlinstall\*" FullTrust -exclusive on
Posted by Joseph Leathlean on 8/25/2010 at 6:50 AM
Easier Workaround. Rename the v4.0.30319 directories in C:\Windows\Microsoft.NET\Framework and C:\Windows\Microsoft.NET\Framework64 to v4.0.30319_bad. You may have to shut down any services that utilize .Net to do so.

Once the install is complete - rename the directories back.
Posted by Randy in Marin on 7/30/2010 at 4:25 PM
Uninstall the following:

Microsoft .NET Framework 4 Extended
Microsoft .NET Framework 4 Client Profile

Avoid the optional windows update http://support.microsoft.com/kb/982671.