title: powershell java invalid thread stack size error
body: <p>I'm tasked with converting some Windows scripts to PowerShell versions. The conversion is going good except for some minor issues. Top issue involves a Java call that we use to query a database and generate XML or HTML files. When I run this from a Windows script no problem:</p>
  
  <p>java  <strong>-Xss1m</strong> -cp ../lib/;../lib/jtds-1.3.1.jar;../lib/ojdbc6.jar DBDownloader TMPDBNAME ../sql/MTD_MTTR_Detail_v7.sql ../out/drilldown/%fileName1%  >> ..\logs\mtd.log 2>&amp;1</p>
  
  <p>But when I run this from a PowerShell script I get this error:</p>
  
  <p><em>LASTEXITCODE:1 Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit.
  <strong>Invalid thread stack size: -Xss1m -cp</em></strong></p>
  
  <p>The call is made using the &amp; call operator. I wrote a library function for all the script to use and it make a call similar to the following:</p>
  
  <p>*$output = [string] (&amp; $jvApp $jvArg1 $jvArg2 $jvArg3 $dbArg $sqlArg $lastArg <em>>> $logArg 2>&amp;1)</em></p>
  
  <p>The args for this call are the following:</p>
  
  <p>sqlName: MTD_MTTR_Detail_v7 </p>
  
  <p>jvArg1:  -Xss1m -cp </p>
  
  <p>jvArg2:  ../lib/;../lib/jtds-1.3.1.jar;../lib/ojdbc6.jar </p>
  
  <p>jvArg3:  DBDownloader</p>
  
  <p>dbArg:   TMPDBNAME </p>
  
  <p>sqlArg:  ..\sql\MTD_MTTR_Detail_v7.sql </p>
  
  <p>lastArg: ..\out\drilldown\MTD_MTTR_Detail.xml </p>
  
  <p>logArg:  ..\logs\mtd.log</p>
  
  <p>I also set these environment variables:</p>
  
  <p>env:Path:      C:\Program Files\Java\jre8\bin;...</p>
  
  <p>env:JAVA_HOME: C:\Program Files\Java\jre8\;</p>
  
  <p>env:CLASSPATH: C:\Program Files\Java\jre8\lib;</p>
  
  <p>What is weird is that the call will work and produce the XML or HTML file if I take out the stack size argument. I've also tried several smaller stack size settings down to 128k with no luck.</p>
  
  <p>While the call works now without the setting, I'm concerned it may fail in the future. I believe they put this due the complex SQL statement used the large amounts of data they were querying and processing.</p>
  
  <p>Any ideas?</p>