VBS script run from a C++ program hangs onto thread, wont allow shut down and clean up

I have a program written in Visual Studio 6.0 using C++. The program should run until it receives a message to switch, then it should shut itself down, wait a few seconds, and then start up its sister program.  Currently if I open the first program and close it manually, then run the sister program manually (double-clicking on it) everything works fine.  I am trying to make it simpler for the user though and use a script that will run to handle this action when a special message is received.  

Currently the flow of the program is for the main program to shut itself almost all the way down before it opens a VBScript file that will loop, waiting for the main program to close.
The main program then finishes closing itself.  When the main is closed the vbs file will then wait 30 seconds and then run the sister program.  The problem is that when I use ShellExecute to run the vbs file it seems to create a new thread.  When MAIN closes and the sister program attempts to open I run into numerous errors with memory and inabilty to acess things that should have been cleaned up and freed when MAIN shut down (They share many resources).  But if I run the script on my own from outside of my main program then it works fine... it is only if I call it from main that I receive the problem.

Anyone have any ideas /sample code on how I can run this vbs script from my program but not have this thread attaching back to the parent program?  Not much to it but I included the code on how I call ShellExecute.
HINSTANCE nResult = ShellExecute(NULL, NULL, _T("C:\\Projects\\EMMT\\Software\\Scripts\\Switch_Over.vbs"), _T("1"), NULL, SW_HIDE);
if( (int)nResult == ERROR_FILE_NOT_FOUND)
//not found

Open in new window

Who is Participating?
DanRollinsConnect With a Mentor Commented:
Using the TaksKill command within the script might not be such a good idea, however, it seems to me that it would cause the system to free up all resources -- memory, file handles, etc -- as expected.  One thing worth trying is
   Taskkill /T
...which will also terminate any child processes that were started by it.
Having the original EXE die normally would be preferrable.  It could loop, waiting for a change in a registry value or the creation of a certain file (or other globally-available signal) and then exit normally.
I can say that it seems to work as expected when I try it....
#include "stdafx.h"
#include <windows.h>
#include <shellapi.h>
int main(int argc, char* argv[])
	char szFile[]="c:\\temp\\test.vbs";
	HINSTANCE nResult = ShellExecute(NULL, "open", szFile, "1", NULL, SW_SHOWNORMAL );
	if( (int)nResult == ERROR_FILE_NOT_FOUND) {
		//not found
	if( (int)nResult <= 32 )  {
	return 0;  /// exit from this console app

Open in new window

Here's the VBS I used "test.vbs"
Option Explicit
Const cIMG = "<img src='file:\\C:\TEMP\sourcegray.bmp' border='1'>"
Dim oIEA : Set oIEA = CreateObject("InternetExplorer.Application")
With oIEA
  .ToolBar = 0
  .AddressBar =false
  .StatusBar = 0
  .Width = 700
  .Height = 550
  .Left = 0
  .Top = 0
  .MenuBar = false
  .Navigate "about:blank"
  While oIEA.Busy
  .Document.Title = "Murphy Gets The Finger!!!"
  .Document.Body.InnerHTML = cIMG
  .Visible = 1
End With 
WScript.Sleep 10 * 1000
On Error Resume Next 
set oIEA = Nothing

Open in new window

Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

In the Task Manager, I can see that CONSOLE22.EXE starts, then WSCRIPT.EXE starts, then CONSOLE22.EXE ends, then WSCRIPT.EXE ends a few seconds later (WSCRIPT.EXE is the program that actually runs a VBS or JS script file) .
BTW, always use SW_SHOWNORMAL for testing!! -- never leave yourself in the dark :-)
yelowsnw2Author Commented:
The bigger problem I was having was that the C++ program would call the script , the script would run and TASKKILL the C++ program that called it, then would start up it's sister C++ program.  The only issue was that the C++ program that got killed would never clean up or free up the memory it was using until the script went away.  As if Windows saw the child thread was still running, not allowing end of program cleanup.  The sister program that then starts up (basically same exact program with a different name) and is not allowed to hook into that memory because it is still in use by the first program as the script hasn't finished yet.

We have since had our main C++ program gracefully close itself down (no more TASKKILL) but the problem still remained as it still called a script.
yelowsnw2Author Commented:
Oops, forgot to add.  We have since found a workaround and it works now, but not in the best of ways.  We had to create a new unrelated exe that basically just sits there and watches for a sign that it is time to switch over from one to the other.  Once the main C++ program exits on its own then it just calls the same script and it works fine now.  The memory gets released by windows now.

But I would still like better clarification on the problem, and I do wonder if there is a way to better avoid it.
yelowsnw2Author Commented:
Haven't had a chance to test this out yet but it's something I haven't tried yet!
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.