Windows Server 2012 R2 - Process is terminated due to StackOverflowException.

[Amir Luzon]

I am running a playbook on this machine an i am recieving the following error:

2015-09-29 15:35:46,339 p=13487 u=deploy_rn |  failed: [some_host] => (item=default) => {"failed": true, "item": "default", "parsed": false}

2015-09-29 15:35:46,341 p=13487 u=deploy_rn |  Process is terminated due to StackOverflowException.

i have searched about this issue and mainly found discussions regarding installing a hotfix https://support.microsoft.com/en-us/kb/2842230 on the machine.

in my case this fix is not relavent since the server is 2012 R2 and should have the hotfix already installed (either way i cannot install it on that machine, tried but received error that it is not compatible version)

I am not sure how to proceed i do not have any information besides that error. another annoying fact is that this sometimes happens, sometimes does not happen.

Any ideas?

[Trond Hindenes]

That's weird. Any particular Ansible module you're seeing this on?

[Amir Luzon]

We are running a custom module we wrote in powershell. this module basically runs about 5 parallel jobs which conduct SSDT work (sqlpackage.exe). it seems that the actual work done by each job is completed successfully yet still we receive the StackOverflowException.

[J Hawkesworth]

I wonder if you are hitting one of the quota limits.

https://msdn.microsoft.com/en-us/library/ee309367(v=vs.85).aspx

[Nikolai Shornikov]

Really want to know if you've found a workaround. This exact executable on a patched 2008R2 machine is giving me the same error.

[Trond Hindenes]

Nikolai, you're saying a sqlpackage job is giving you the same error?

[Nikolai Shornikov]

Yeah. Wrapping sqlpackage.exe, I would get the above CLR error, and sometimes Out of Memory, and sometimes success. I'm specifically wrapping a 32-bit sqlpackage.exe, but I don't know which "plugin" settings below ultimately applies to the process, which I start via Start-Process.

I'm having a long run of successes presently, so I think this last thing I tried may have been the fix. 

I raised memory per shell up to a few gigs, both on the top level, and in each plugin:

cd WSMan:\localhost\Shell

Set-Item .\MaxConcurrentUsers 25

Set-Item .\MaxMemoryPerShellMB 4096

cd WSMan:\localhost\Plugin\microsoft.powershell\Quotas

Set-Item .\MaxConcurrentCommandsPerShell 4096

Set-Item .\MaxConcurrentUsers 25

Set-Item .\MaxMemoryPerShellMB 4096

cd WSMan:\localhost\Plugin\microsoft.powershell32\Quotas

Set-Item .\MaxConcurrentCommandsPerShell 4096

Set-Item .\MaxConcurrentUsers 25

Set-Item .\MaxMemoryPerShellMB 4096

Restart-Service winrm

-Nik

[Trond Hindenes]

Nice. I doubt its the last one, since that seems to deal with the 32-bit think, but that's just an assumption. Amir, care to test out these values and see if they help?

[Amir Luzon]

Hey guys,

I forgot to get back to this thread :)

anyways what did the thing for us was to increase the memory of powershell from 1024 to 2048 (i guess this depends on size of dacpacs, schemas loaded to memory, etc.)

i used this guide to do it step by step:

http://blogs.technet.com/b/heyscriptingguy/archive/2013/07/30/learn-how-to-configure-powershell-memory.aspx

you should play around with the value till you find what works for you.

BTW, notice that in my case it was not the SQLPackage that was throwing the exception, it was powershell. i saw this from logs of sqlpackage that it completed it's work.

[Amir Luzon]

PS, we dont use Start-Process but use '&', as in "& c:\....\sqlpackage.exe ...."