CS2000: Compiler initialization failed unexpectedly

Question

I have a WPF .NET 3.5 SP1 application that is in use on at least hundreds if not thousands of machines at this point. The application stores a tree structure in XML that is loaded at startup. As soon as I try to load the xml via serialization, boom. It only happens on one end user machine. He has admin rights, plenty of disk space, memory, etc.

Before I disregard it as a machine problem or anti-virus/spyware and get his IT department involved (a painstaking process), I wanted to see if there's a better way to track this down and get more information. Since XmlSerialization is black boxish, I'm not sure that there's much more that I can do as a developer. Or can I?

Any tips are appreciated, complete error below.

Unable to generate a temporary class (result=1). error CS2000: Compiler initialization failed unexpectedly -- 'Not enough storage is available to complete this operation. '

Stack Trace: 

   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 System.Xml.Serialization.XmlSerializer..ctor(Type type)
   at Internal.Objects.TreeSetItemManager.LoadTreeItems(String fileName) in TreeSetItemManager.cs:line 41
   at SPA.Windows.MasterWindow.OnInitialized(EventArgs e)
5/28/2009 10:16:20 Message:
External component has thrown an exception.Details:
   at MS.Win32.UnsafeNativeMethods.ITfThreadMgr.Activate(Int32& clientId)
   at System.Windows.Input.TextServicesContext.RegisterTextStore(DefaultTextStore defaultTextStore)
   at System.Windows.Input.DefaultTextStore.get_Current()
   at System.Windows.Input.TextServicesContext.SetFocusOnDefaultTextStore()
   at System.Windows.Input.InputMethod.EnableOrDisableInputMethod(Boolean bEnabled)
   at System.Windows.Input.TextServicesManager.Focus(DependencyObject focus)
   at System.Windows.Input.KeyboardDevice.ChangeFocus(DependencyObject focus, Int32 timestamp)
   at System.Windows.Input.KeyboardDevice.TryChangeFocus(DependencyObject newFocus, IKeyboardInputProvider keyboardInputProvider, Boolean askOld, Boolean askNew, Boolean forceToNullIfFailed)
   at System.Windows.Input.KeyboardDevice.Focus(DependencyObject focus, Boolean askOld, Boolean askNew)
   at System.Windows.Input.KeyboardDevice.Focus(IInputElement element)
   at System.Windows.Interop.HwndKeyboardInputProvider.FilterMessage(IntPtr hwnd, Int32 message, IntPtr wParam, IntPtr lParam, Boolean& handled)
   at System.Windows.Interop.HwndSource.InputFilterMessage(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
   at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
   at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Boolean isSingleParameter)
   at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Boolean isSingleParameter, Delegate catchHandler)

Answer 1

Even though he has admin rights where is %TEMP% pointing to on that machine? And can you manually create/delete files in there?

Secondly how much memory is in the failing machine as opposed to the succeeding machines?

Answer 2

Tip: We had a similar problem with msxsl:script tags in XSLT using .NET compiled transform. Note that the error you reported occurs in the compile method of the serializer.

You have checked disk space and permissions, but perhaps the process user is not admin, example, asp.net process.

WARNING: The Microsoft .NET XslCompiledTransform class causes several problems when msxsl:script is used. The XslCompiledTransform creates a DLL in the temporary folder and locks it in memory.

1. The ASP.NET process may not have access to the temporary folder and the XSLT will fail.
2. The temporary DLL is not temporary and remains in the folder: one DLL for every transform that uses msxsl:script. Eventually the server's hard drive is filled to capacity.
3. The DLL is locked in memory, causing a severe memory leak.

DO NOT USE msxsl:script WITH Microsoft .NET XslCompiledTransform class. Instead, use an extension object to call C# or VB.NET methods outside the XSLT. See Microsoft's documentation on XSLT Extension Objects .

(http://dev.ektron.com/kb_article.aspx?id=482)

Answer 3

You could try to pre-generate the XML serialization assemblies (with sgen.exe or with the option in the Build pane of the project properties) and release them with your app. That way, they won't need to be generated at runtime, and you won't get that exception

Answer 4

Given that the error message states "Not enough storage is available to complete this operation.", I am guessing that the problem is not because the location that has the XML file is out of space or does not have permissions. My guess is that the temporary location where the temporary assembly's intermediate files are being dropped is what is actually causing the problem.

XmlSerialization in .NET uses code generation to create C# source code, wich is then compiled (which ultimately uses CSharpCodeProvider, which is part of CodeDom.) CodeDom compiles source very similarly to the command line csc.exe compiler, so temporary intermediate object files often need to be created on disk before the final assembly can be generated (regardless of whether its an in-memory assembly or not.)

I would figure out where these temp files are being placed, and make sure that drive has enough space. Make sure that the user who has the problem doesn't have any kind of space quota where these temp files are being generated too, as if he has used his quota, that could also cause storage space exceptions. The temporary location for these files is configurable with the XmlSerializerSection in your applications .config file, so if there is indeed a space problem, you could try redirecting them temporarily to a drive that does have enough space (and read/write/delete permissions for the current user.)

Answer 5

A bit of investigation suggests that by "storage", the system is referring to memory for the process rather than disk space.

Given that the XmlSerializer will be creating the assembly in memory from C# code, it looks like that might be a place to start. Some things to investigate could include:

• Is the XML object graph large? (I'll admit that is more likely to be an issue if it was serialization where the problem lay rather than deserialization...)
• Is there anything unusual about the memory configuration of this workstation? Are there lots of other processes running, no virtual memory left, or some other unusual pressure?

In any case, +1 for the suggestion to pre-compile the XML, if this is pre-set configuration-style data that has to be the way to go.

Answer 6

this MSDN article says that you should repair or reinstall the .NET Framework SDK. Can you try that and see if it helps?

Answer 7

Update.

The problem ended up being a conflict with Cisco's Security Agent software and obfuscation performed by Xenocode. If one or the other is removed from the equation, the exception doesn't occur. I've also tried a number of ways to work around it, to no avail. So I've got a query into Xenocode (communicating with Cisco was beyond a waste of time). Maybe they can get to the bottom of what is going on.