An unhandled exception of type "System.StackOverflowException" occurred in VimService55.XmlSerializers.dll

Question

I am working on an asp.net mvc-5 web application and I am using ap.net version 4.5.

Inside my web application, I run some shell scripts to get some information about the hardware of some servers and virtual machines and return the results inside my code, as shown below:

var shell = PowerShell.Create(); string PsCmd = "add-pssnapin VMware.VimAutomation.Core; $vCenterServer = '" + vCenterName.Trim() + "';$vCenterAdmin = '" + vCenterUsername.Trim() + "' ;$vCenterPassword = '" + vCenterPassword + "';" + System.Environment.NewLine; PsCmd += "$VIServer = Connect-VIServer -Server $vCenterServer -User $vCenterAdmin -Password $vCenterPassword;" + System.Environment.NewLine; PsCmd += "Get-VMHost " + System.Environment.NewLine; shell.Commands.AddScript(PsCmd); dynamic results = shell.Invoke(); var temp_result = results[0].BaseObject == null ? results[0] : results[0].BaseObject; var otherIdentityInfo = temp_result.ExtensionData.Hardware.SystemInfo.OtherIdentifyingInfo; 

now when I run this inside my Visual Studio 2012 professional, I get the following exception: -

 System.StackOverflowException was unhandled An unhandled exception of type 'System.StackOverflowException' occurred in VimService55.XmlSerializers.dll 

on

 var otherIdentityInfo = temp_result.ExtensionData.Hardware.SystemInfo.OtherIdentifyingInfo; 

So can anyone accept this? I know that in general the "StackOverflowException" exception is due to the fact that there is too much data on the stack, but in my case I have no control over this data, as I am viewing the VM server information. So can anyone advise this?

EDIT

I'm not sure what really causes the error (debugger OR code)? because when I try to call this code in a hosted application inside IIS (not inside Visual Studio), I get null for the otherIdentityInfo variable, and not get an exception. However, when I debug code inside Visual Studio using Autos, I get an exception since @JmaesP mentions that the exception is thrown by the debugger, but not sure how I can debug this value to understand why I get null?

Answer 1

An exception from the XML serializer may indicate a problem with one of you serializable types. If the type declaration itself is somewhat recursive, the default XML serializer will end with inifite recursion. Consider this example:

 [Serializable()] public class Foo : IEnumerable<Foo> { public Foo() { } IEnumerator IEnumerable.GetEnumerator() { throw new NotImplementedException(); } public IEnumerator<Foo> GetEnumerator() { throw new NotImplementedException(); } public void Add(Foo item) { throw new NotImplementedException(); } } 

The default XML serializer first tries to figure out how to (de-) serialize an instance of Foo , then it tries to figure out how to (de-) serialize IEnumerable<Foo> , and do that, figure out how to (de-) serialize a Foo , which leads to infinite recursion. Typically, a solution to this would be to use a custom serializer, as described here .

However, in your case, the serializer is provided by a third-party component. The exception probably occurs during serialization / deserialization, which occurs when objects are transferred from a PowerShell session to your process. So you can change the object that is returned from the PowerShell script. Instead of returning a VMHost object (requiring serialization of the entire tree of objects of the VMHost object), you can simply return SystemInfo or OtherIdentifyingInfo .

Answer 2

Large recursions can cause errors outside the stack. Probably your problem is that your program is trying to consume an infinite amount / very large number of stacks.

Without seeing the stack trace, it’s a little difficult to give a final answer, but I think that sticking to the basics, I believe that the source of your StackOverflow is PsCmd + = , which continually pushes data onto the stack and throws a StackOverflowException.

You can increase the stack size using the code below:

Editbin.exe / Stack: 14000000 "$ (TargetDir) MyProject.exe"

Have you analyzed your code to see how deep your recursion is on average? Does it always get into StackOverflow? Try hardcoding one object and see the result.

Since 64-bit code can increase more stack space than equivalent 32-bit code, large recursions can lead to off-stack errors earlier.

In this case, making a stack is no longer a good idea. Instead, we must find a deeply recursive algorithm and turn it into an iterative one.

For Stack-Trace; You can read this property: Environment.StackTrace .

If stacktrace has reached the specified threshold, you can return the function.

Note. From .NET 2.0 and above, you cannot get a StackOverflowException object using a try-catch block.

Let me know if this helps you.