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

A stack overflow exception from an XML serializer might indicate an issue with one of you serializable types. If the type declaration by itself is somewhat recursice, the default XML serializer will end up in 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 an IEnumerable<Foo>, and to do that it tries to figure out how to (de-)serialize a Foo — resulting in infinite recursion. Typically, a solution to this would to use a custom serializer as described here.

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

Large recursions can cause out-of-stack errors. Your problem is likely that your program is attempting to consume an infinite amount /very large amount of stack.

Without seeing your stack trace, it's a bit difficult to provide a definitive answer, but I think sticking to the basics leads me to believe the source of your StackOverflow is the PsCmd += which continuously adding the data into the stack and results in StackOverflowException.

You can increase the stack size by using the below code:

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

Have you analyzed your code to find out that how deep your recursion goes on average? Does it always hit a StackOverflow? Try hardcoding a single entity and see the result.

Since 64 bit code can up more stack space than equivalent 32 bit code, large recursions can cause out-of-stack errors to occur earlier.

In that case, making the stack larger is not a good idea either. Instead we should find the deeply recursive algorithm and make it into an iterative one.

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

If the stacktrace exceded a specific threshold that you preset, 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 at all it helps you.