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.
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.
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
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?
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.)
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.