none
VB6 Application Process Does Not Exit under Windows 7/2008

    Question

  • While we are porting our product to VS2010, all the applications are in C/C++ except one which is designed under VB6.  Since it is an complex reporting tool,  it will be done last and well into the future.

    A compliant was issued when a customer was trying to use its command line option to automate a report:

    START /WAIT WCREPORT  /C:CreateReport.pro

    and it would never return from his batch file.    He had Windows 7 and I was able to repeat it under Windows 2008 and saw under Task Manager that WCREPORT was not exiting,  thus explaining why START /WAIT never finished.

    Can someone explain this and what is a solution?

    I tried changing the exe properties running it under Windows 95 emulation, didn't work.    I really need to resolve since we are not be able to port the VB6-based application for a while due to its vast complex reporting capabilities that needs to be redone.

     

     


    Hector Santos, http://www.santronics.com
    Via Wildcat! Live Exchange NNTP Gateway http://opensite.winserver.com
    Tuesday, December 27, 2011 9:27 AM

All replies

  • Hi Hector Santos,

    I am not sure if you are the author of the "WCREPORT" tool, but you just concern the issue that the tool cannot run in Windows 7/2008. So could you please provide more information about this tool, specially the development information, how to you design it, and what technology/libraries/tools it used?

     

    Unfortunately, VB6 is very old, and no information said its runtime will be supported in the next version Windows, (please refer to http://msdn.microsoft.com/nb-no/vbrun/ms788708%28en-us%29.aspx  the official word is that this configuration will likely not be supported: ...there are no plans to include VB6 runtime in future versions of Windows beyond Windows 7. So your VB6 application may run on the furture Windows, but the VB6 IDE is not supported to use and develop)

     

    For running it, you could choose to install the Windows XP Mode on the Windows 7 (http://www.microsoft.com/windows/virtual-pc/download.aspx), and you could run the VB6 application in the XP mode as a workaround. But for the root cause, we should get more information, and then we could analyses it. Please try to check the system event log, and does your tool write and log file? Please test your tool in one 32-bit Windows system, not in the 64-bit system.

    Sincerely,


    Bob Bao [MSFT]
    MSDN Community Support | Feedback to us

    Wednesday, December 28, 2011 1:54 AM
    Moderator
  • Hi Bob,

    First, happy new year :)

    Bob, we don't plan on using the VB6 IDE any more.  We are just supporting the legacy VB6 application as it is expected to work on all WIN32 OSes since 1996 and new 4 bit WIN32 sub-systems, not just because we said so but because Microsoft said so ever since WIN32 OSes first came out.  

    Until WCREPORT is redeveloped under a new language, most likely C#,  until then we have to support it when customers upgrade to Windows 7/2008/VISTA.

    Keep in mind, they will not do so UNLESS we tell them its ok, and that was the problem - we had no expectation that MICROSOFT will break any our Win32 applications including the single VB6 application and hence we had provided the support information it is ok to upgrade.

    But this support information will now have to change and come with the exception that WCREPORT will not work under Windows 7/2008/VISTA.  So if they are not using it, no problem.  But if they are, it will no longer work under the new Microsoft Windows OSes.

    Since there is no Microsoft KB or information regarding the VB6 RTE having problems and any specific remedy a VB6 application to do to resolve this,  I had to write a wrapper CreateProcess() kludge (RunWcReport.exe) that will start wcreport.exe and monitor when it finally ends in order to terminate it from memory.  We can do that because the applet is a RPC client to a RPC server, so when the context is lost, the wrapper can detect that and terminate it if it wasn't gracefully signaled from a Wait on process handle.

    We needed a solution first, the kludge will be suffice until we can determine the specific new OS reason issue.  All I can tell you that this 1996 VB6 application never had an issue with any OSes until now and its a typical VB6 application with a Form Load and Form Unload where things are cleaned up and the END command is called!

    The only major difference with this VB6 application is that is an RPC client to our RPC server.  So in the Form Load, it discovers the RPC Server, binds to it and creates a client context which the interface DLL creates a marshaling channel communications thread for call back events, if established by the VB6.    And in the Form Unload, the context is deleted and the background marshaling thread deleted.

    So if you can appreciate the issue, this is *NOT* a design question on our 1996 to present RPC client/server framework that is single sourced for all native languages, including VB6 p-code and .NET.

    While we can revisit it when it comes to VB6 based p-code/RTE related issues to real DCE-based RPC framework, not COM+ or DCOM,  it is 7/2008/VISTA that changed, not our code.    I have no desire to continue using VB6 IDE, so until the "subtle" new issues are discovered, the temporary RPC connection monitoring wrapper launcher will work for now.

     


    Hector Santos, http://www.santronics.com
    Via Wildcat! Live Exchange NNTP Gateway http://opensite.winserver.com
    Sunday, January 01, 2012 10:50 AM
  • Happy new year.

    Oh, yes, start from Vista, Win OS changes many things. Regarding to your specific scenario, it is hard to find one KB or document. I searched the documents and KBs, unfortunately no result. However, I can give some general suggestions. Like:

    • Run you Command Line console as Admin

    I want to know which part in your Load handler occur the error. Better to trace your application, and log the information. Yes, it may be the Win OS issue, but we cannot know the scope, RPC related issue or Process/ACL issue? So we still need your log information. Thanks.

    Sincerely,

     


    Bob Bao [MSFT]
    MSDN Community Support | Feedback to us
    Monday, January 02, 2012 8:41 AM
    Moderator
  • >with a Form Load and Form Unload where things are cleaned up and the END command is called!

    If you are having to use the END command to end the program it suggests that things are not being cleaned up sufficiently. Please post the Form_Unload event code.

    Tuesday, January 03, 2012 8:39 AM
  • If you are having to use the END command to end the program it suggests that things are not being cleaned up sufficiently. Please post the Form_Unload event code.

    Even if that is so, why wasn't an issue with 95/NT/2000/2003?

    You are right.  END is used only when there is an problem during start up.  Its not used in Forum_Unload()   This is exactly what it has/

    Private Sub Form_Unload(Cancel As Integer)
        ExitApplication
    End Sub

    Private Sub ExitApplication()
      WildcatServerDeleteContext() 

      If bDebug = True Then
        Close #DebugFile
      End If

    End Sub

    The WildcatServerDeleteContext()  releases a RPC Server context thread created for the main thread.  A WildcatServerCreateContext() was called during Form_Load() and END is used in FORM_LOAD() when an start up error is found. 
    Private Sub Form_Load()
    ....
     
     ' RPC Server discovery
      If WildcatServerConnectSpecific(0, SVR) = False Then
         End
      End If
      ' Create server context
      If WildcatServerCreateContext() = False Then
        EmitErrorCode
        End
      End If
      ' Establish RPC context security level
      If LoginSystem() = False Then
        EmitErrorCode
        End
      End If
     ...

    End Sub
    This has all worked fine for all OSes since 32 bit Windows OS came.  So whatever is going on now with Windows 7/2008/VISTA, we just don't know.   These 32 bit native RPC server functions are part of our Wildcat! SDK, found here:
    The WCSDK has example for all native languages. include the legacy VB6 and with newer WCSDK has .NET WCSDK interop ports libraries with examples.    We were not aware of ANY report regarding 7/2008/VISTA issues until now with this particular WCREPORT which is our ADD-ON product.
    As I stated, the quick solution was to write a C/C++ RunWcReport.exe wrapper that calls one of the SDK functions to get a snapshot of the server's connected clients.   When it is no longer found, the spawned WcReport.exe process is terminated.
    BOOL Run(const BOOL UseDos, 
                    const char *szCmd, 
                    const char *pArg, 
                     int &exitcode)
    {
        exitcode                 = -1;
    
        SECURITY_ATTRIBUTES sa   = {0};
        sa.nLength = sizeof(sa);
        sa.bInheritHandle = TRUE;
    
        STARTUPINFO si           = {0};
        si.cb = sizeof(si);
    
        char cmd[MAX_PATH] = {0};
        char args[MAX_PATH] = {0};
    
        if (UseDos) {
            strcpy(cmd,getenv("comspec"));
            strcat(cmd," /c ");
        }
    
        strcat(cmd,szCmd);
    
        if (pArg && pArg[0]) {
            strcpy(args,pArg);
            strcat(cmd," ");
            strcat(cmd,args);
        }
    
        PROCESS_INFORMATION pi = {0};
    
        DWORD dwFlags = 0;
        const char *P1 = NULL;
        char *P2 = cmd;
    
        if (!CreateProcess(P1,
                           P2,                   // command line
                           NULL,                 // process security attributes
                           NULL,                 // primary thread security attributes
                           TRUE,                 // handles are inherited
                           dwFlags,              // creation flags
                           NULL,                 // use parent's environment
                           NULL,                 // use parent's current directory
                           &si,                  // STARTUPINFO pointer
                           &pi)) {               // receives PROCESS_INFORMATION
            int err = GetLastError();  // preserve the CreateProcess error
            SetLastError(err);
            return FALSE;
        }
    
        //
        // let go of the child thread
        //
    
        CloseHandle(pi.hThread);
    
        //
        // wait for process to finish, capture redirection and
        // send it to the parent window/console
        //
        BOOL Done = FALSE;
        int DoTerminate = 1;
        while (!Done){
           DWORD ret = WaitForSingleObject(pi.hProcess, 1000);
           if (ret == WAIT_OBJECT_0) {
               GetExitCodeProcess(pi.hProcess, (DWORD *)&exitcode);
               Done = TRUE;
               break;
           }
           if (ret == WAIT_TIMEOUT) {
               if (!IsWcReportRunning()) {
                  DoTerminate--;
                  if (DoTerminate == 0) {
                     TerminateProcess(pi.hProcess,2);
                  }
               }
               continue;
           }
           break;
    
        }
        CloseHandle(pi.hProcess);
        return TRUE;
    }
    
    


    IsWcReportRunning() just calls the SDK GetConnectionInfo() function to enumerate thru the server's context list looking for the process name "wcreport.exe."
    Yes, this is all more info probably than necessary, but it is to show this is not just a NEWBIE issue. This has never a problem with any OS prior to Window 7/2008/VISTA and it appears to be only for VB6 and its has not yet to be tested or confirm if it is relationship to the background Thread created during Form_Load() and released during Form_Unload().  


    Hector Santos, http://www.santronics.com
    Via Wildcat! Live Exchange NNTP Gateway http://opensite.winserver.com
    Tuesday, January 03, 2012 2:32 PM
  • 1. Did you try the START /WAIT WCREPORT /C:CreateReport.pro under an Admin Command prompt

    2. There has not been a rash of such problems since introduction of Vista/ W7 so I expect the app is failing to Unload for classical rather than new reasons. It could be a timing issue found out by a quicker CPU. Look again at the classics, have all forms been unloaded/ set to nothing without being accidentally being reloaded, have Timers on any such forms been disabled first, have all references to Com objects been set to nothing etc.

    Wednesday, January 04, 2012 1:54 PM
  • 1. Did you try the START /WAIT WCREPORT /C:CreateReport.pro under an Admin Command prompt

    2. There has not been a rash of such problems since introduction of Vista/ W7 so I expect the app is failing to Unload for classical rather than new reasons. It could be a timing issue found out by a quicker CPU. Look again at the classics, have all forms been unloaded/ set to nothing without being accidentally being reloaded, have Timers on any such forms been disabled first, have all references to Com objects been set to nothing etc.

    Hi, thanks for your input.

    1) Yes, I specifically check for this and asked the customer to try that but I was already about to repeat this a Windows 2008 machine and it already running as the admin. But I did try it again by specifically right clicking "Run As" the admin just in case.   As stated earlier, all the other legacy advanced startup emulations options were tried too, including the timing consideration.

    2) Well, wcReport is a legacy application that will not be developed any more.  It will be "ported" eventually, it is feature rich so that will take some time to finish.  So we expected to continue supporting the current version under the newer OSes without issue.  

    However,  given the fact it is P-CODE, I would not be surprise the VB6 p-code runtime engine modules, dlls modules, what have you, have changed under Windows Vista/2008/7, especially with its new system wide attempts to better manage memory, threads, etc for all native "compiled", i.e. not .NET, applications.    In any case, with wcReport, since we never saw any issue,  its hard to tell at this point what exactly is the issue other than perhaps the VB6 p-code RTE is doing something differently or expecting something differently.  

     Thanks


    Hector Santos, http://www.santronics.com
    Via Wildcat! Live Exchange NNTP Gateway http://opensite.winserver.com
    Saturday, January 07, 2012 10:20 AM