2147024882 - Not enough storage is available to complete this operation - WMI   

I am using WMI to create a process and run a VB6 program.  The
following VB6 program starts TRIADHandler.exe, a VB6 program:


Private Sub Form_Load()

    Dim objWMIService, objProcess, objCalc, strShell, objProgram

    Set objWMIService = GetObject("winmgmts://./root/cimv2")
    Set objProcess = objWMIService.Get("Win32_Process")
    Set objProgram =
objProcess.Methods_("Create").InParameters.SpawnInstance_
    objProgram.CommandLine = "d:\bin\TRIADHandler.exe " &
Replace(Command$, """", "")
    Set strShell = objWMIService.ExecMethod("Win32_Process", "Create",
objProgram)
    Unload Me

End Sub



The TRIADHander.exe program is VB6 and it makes some calls to SQL
Server using OLEDB and uses CREATEOBJECT to instantiate ActiveX
programs written in VB6.  This all works well unless the program is
moving large chunks of data in and out of memory (10 Mb +).  Often, in
this case, the program will fail with "-2147024882 - Not enough
storage is available to complete this operation."

However, when I start the TRIADHandler.exe interactively (Start -
Run), it executes properly without ever producing the error regardless
of how large the data chunks are.  Why would a process created using
WMI have a memory limitation that does not exist with processes
instantiated interactively with Start - Run?  For processes that must
be started programatically in their own process space, what would work
better than using WMI to create the process?  Or, is there some kind
of setting in WMI that gives the program authority to use more memory?


Note:  This is running on a fairly new server (Windows Server 2003
with all service packs) with 4 Gb RAM, and all indications show that
there is a ton of physical RAM unused when the program is failing.

Thanks.
-Steve

date: Mon, 11 Aug 2008 11:07:42 -0700 (PDT)   author:   Steve

Re: 2147024882 - Not enough storage is available to complete this operation - WMI   

This is pretty stupid but could be a workaround..
What if you remotely start a simple program (even a script) that just
starts a new thread with your TRIADHandler.exe? As your program won't
be ran through WMI, maybe those weird memory limitations will only
apply to the script.
Just my 2 cents anyway..
Rob'

On 11 août, 20:07, Steve  wrote:
> I am using WMI to create a process and run a VB6 program.  The
> following VB6 program starts TRIADHandler.exe, a VB6 program:
>
> Private Sub Form_Load()
>
>     Dim objWMIService, objProcess, objCalc, strShell, objProgram
>
>     Set objWMIService = GetObject("winmgmts://./root/cimv2")
>     Set objProcess = objWMIService.Get("Win32_Process")
>     Set objProgram =
> objProcess.Methods_("Create").InParameters.SpawnInstance_
>     objProgram.CommandLine = "d:\bin\TRIADHandler.exe " &
> Replace(Command$, """", "")
>     Set strShell = objWMIService.ExecMethod("Win32_Process", "Create",
> objProgram)
>     Unload Me
>
> End Sub
>
> The TRIADHander.exe program is VB6 and it makes some calls to SQL
> Server using OLEDB and uses CREATEOBJECT to instantiate ActiveX
> programs written in VB6.  This all works well unless the program is
> moving large chunks of data in and out of memory (10 Mb ).  Often, in
> this case, the program will fail with "-2147024882 - Not enough
> storage is available to complete this operation."
>
> However, when I start the TRIADHandler.exe interactively (Start -
> Run), it executes properly without ever producing the error regardless
> of how large the data chunks are.  Why would a process created using
> WMI have a memory limitation that does not exist with processes
> instantiated interactively with Start - Run?  For processes that must
> be started programatically in their own process space, what would work
> better than using WMI to create the process?  Or, is there some kind
> of setting in WMI that gives the program authority to use more memory?
>
> Note:  This is running on a fairly new server (Windows Server 2003
> with all service packs) with 4 Gb RAM, and all indications show that
> there is a ton of physical RAM unused when the program is failing.
>
> Thanks.
> -Steve

date: Thu, 14 Aug 2008 01:26:00 -0700 (PDT)   author:   RD