Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm trying to install SQL Server 2012 Express on a Windows 7 64-bit PC. It also fails to install SQL Server 2008 R2. The bootstrapper extracts all the files, runs setup.exe (with UAC popup) then (from what I can tell) tries to launch scenarioengine.exe which refuses to run.

The error details from MSSQL 2012 Express are:

Description: Stopped working

Problem signature:
Problem Event Name: CLR20r3
Problem Signature 01: scenarioengine.exe Problem Signature 02: 11.0.2100.60
Problem Signature 03: 4f35e1de
Problem Signature 04: Microsoft.SqlServer.Chainer.Infrastructure
Problem Signature 05: 11.0.0.0
Problem Signature 06: 4f35e1dd
Problem Signature 07: 200
Problem Signature 08: 179
Problem Signature 09: ZAGSF01GRLFWVJMY5S0U0HXSJJE2HDT4
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 1033

I extracted the install files and ran from a command line, and I get the following error:

Unhandled Exception: Microsoft.SqlServer.Chainer.Infrastructure.ChainerInfrastructureException: The environment block used to start a process cannot be longer than 65535 bytes. Your environment block is 162180 bytes long. Remove some environment variables and try again. ---> System.InvalidOperationException: The environment block used to start a process cannot be longer than 65535 bytes. Your environment block is 162180 bytes long. Remove some environment variables and try again.

at System.Diagnostics.EnvironmentBlock.ToByteArray(StringDictionary sd, Boolean unicode) at System.CodeDom.Compiler.Executor.ExecWaitWithCaptureUnimpersonated(SafeUserTokenHandle userToken, String cmd, String currentDir, TempFileCollection tempFiles, String& outputName, String& errorName, String trueCmdLine) at System.CodeDom.Compiler.Executor.ExecWaitWithCapture(SafeUserTokenHandle userToken, String cmd, String currentDir, TempFileCollection tempFiles, String& outputName, String& errorName, String trueCmdLine) at Microsoft.CSharp.CSharpCodeGenerator.Compile(CompilerParameters options, String compilerDirectory, String compilerExe, String arguments, String& outputFile, Int32& nativeReturnValue, String trueArgs)
at Microsoft.CSharp.CSharpCodeGenerator.FromFileBatch(CompilerParameters options, String[] fileNames)
at Microsoft.CSharp.CSharpCodeGenerator.FromSourceBatch(CompilerParameters options, String[] sources)
at Microsoft.CSharp.CSharpCodeGenerator.System.CodeDom.Compiler.ICodeCompiler.CompileAssemblyFromSourceBatch(CompilerParameters options, String[] sources)
at System.CodeDom.Compiler.CodeDomProvider.CompileAssemblyFromSource(CompilerParameters options, String[] sources)
at System.Xml.Serialization.Compiler.Compile(Assembly parent, String ns, XmlSerializerCompilerParameters xmlParameters, Evidence evidence)
at System.Xml.Serialization.TempAssembly.GenerateAssembly(XmlMapping[] xmlMappings, Type[] types, String defaultNamespace, Evidence evidence, XmlSerializerCompilerParameters parameters, Assembly assembly, Hashtable assemblies)
at System.Xml.Serialization.TempAssembly..ctor(XmlMapping[] xmlMappings, Type[] types, String defaultNamespace, String location, Evidence evidence)
at System.Xml.Serialization.XmlSerializer.GenerateTempAssembly(XmlMapping xmlMapping, Type type, String defaultNamespace)
at System.Xml.Serialization.XmlSerializer..ctor(Type type, String defaultNamespace)
at Microsoft.SqlServer.Chainer.Infrastructure.DataStoreService.SerializeObject(String rootPath, Object objectToSerialize, Boolean saveToCache)
--- End of inner exception stack trace ---
at Microsoft.SqlServer.Chainer.Infrastructure.DataStoreService.SerializeObject(String rootPath, Object objectToSerialize, Boolean saveToCache)
at Microsoft.SqlServer.Chainer.Infrastructure.DataStoreService.SetCommonFlag(String key, Boolean value)
at Microsoft.SqlServer.Chainer.Setup.Setup.InitializeLogProviders(ServiceContainer context) at Microsoft.SqlServer.Chainer.Setup.Setup.Run()
at Microsoft.SqlServer.Chainer.Setup.Setup.Start()
at Microsoft.SqlServer.Chainer.Setup.Setup.Main()

The key bit I think is here: The environment block used to start a process cannot be longer than 65535 bytes. Your environment block is 162180 bytes long. Remove some environment variables and try again. I get this specific error in the GUI when trying MSSQL2008 Express, so looks like it's the root cause of both failures.

The error looks like a 32-bit/64-bit incompatibility, but the GUI error code of CLR20r3 implies a .NET framework corruption. Some reports on the Internet claim this could be due to an issue when an embedded OS is cloned, but this isn't an embedded OS. It might be a volume-licensed OS that has been cloned onto the PC, but it's not an embedded OS.

I've tried reinstalling .NET 3.5.1 (through Add/Remote Windows Components & Features, as it's built in to Windows 7), and have installed .NET 4.5 too just in case - both [re]install fine.

Additional PC info: - Windows 7 Pro with SP1; - 64-bit; - 8GB RAM; - Intel Core i5-3550 - Connecting to PC remotely using LogMeIn (as this is a customer's computer).

Any help would be greatly appreciated.

share|improve this question

closed as off-topic by Falcon Momot, mdpc, Ward, Rex, Nathan C Jan 15 at 13:37

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions must be relevant to professional system administration. Server Fault is dedicated to professional system and network administrators. End user and enthusiast questions are off-topic (contact your system administrator or hire a professional to help you out). Please see the Help Center for more information." – Falcon Momot, mdpc, Ward, Rex
If this question can be reworded to fit the rules in the help center, please edit the question.

    
Have you checked the client's environment variables. The command "set" should echo them back to you. –  Katherine Villyard Jan 2 at 21:52
    
Yes, I checked them. Nothing odd there. And they certainly don't look longer than usual. –  Nick Shaw Jan 3 at 8:50

1 Answer 1

up vote 0 down vote accepted

I've resolved this now. For other people's info: I got the customer to run the SQL install directly on the PC (so not via a LogMeIn session), and it worked fine. So looks like LogMeIn was causing all the problems! I knew Remote Desktop shouldn't be used (according to Microsoft's prerequisites), but LogMeIn was not mentioned. They must use the same underlying hooks into the system that cause incompatibility with the install.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.