PRB: Call to ExitProcess() from Visual Basic Application Hinders Process Exit (288216)
The information in this article applies to:
- Microsoft Win32 Application Programming Interface (API)
- Microsoft Visual Basic Professional Edition for Windows 4.0
- Microsoft Visual Basic Professional Edition for Windows 5.0
- Microsoft Visual Basic Professional Edition for Windows 6.0
- Microsoft Visual Basic Enterprise Edition for Windows 4.0
- Microsoft Visual Basic Enterprise Edition for Windows 5.0
- Microsoft Visual Basic Enterprise Edition for Windows 6.0
This article was previously published under Q288216 SYMPTOMS
If a Visual Basic application makes a direct call to the ExitProcess() API, the process may not properly exit. In some instances, a call to ExitProcess() will even cause an access violation or cause the process to deadlock.
Calling ExitProcess() from a Visual Basic application is unsupported.
CAUSE
The ExitProcess() API should not be called by a thread when other threads still need to clean up their own resources. If there are other running threads that have not exited, the ExitProcess() routine will abruptly terminate them. This can cause data loss and other unpredictable behavior.
The Visual Basic run-time engine is responsible for the execution of a Visual Basic application. Not only does this engine interpret and execute the code within the application, but it also initializes and cleans up the process. Because the Visual Basic run-time engine allocates resources, only it can know when the resources are released. Thus, only the run-time engine can safely call ExitProcess().
RESOLUTION
The proper way to exit a Visual Basic application is to naturally exit Sub Main or unload the form specified as the "Startup Object" within the application's Project Properties.
MORE INFORMATION
One particular instance in which a call to ExitProcess() is known to cause a problem involves COM objects. If a Visual Basic application has an outstanding reference to an out-of-process COM object when it calls ExitProcess(), the calling process is likely to "hang" or cause an access violation. A direct call to CoUninitialize() immediately before the call to ExitProcess() will usually prevent this problem. Although this approach allows you to work around the problem, it is not recommended or supported by Microsoft.
The only advantage that would arise out of calling ExitProcess() from a Visual Basic application is the ability to set an exit code for the process. But because of the unpredictable nature of calling ExitProcess() from Visual Basic, it is better to communicate the success or failure of the process through some other means, such as writing an exit code to a file or sending a windows message to another process.
| Modification Type: | Minor | Last Reviewed: | 7/14/2004 |
|---|
| Keywords: | kbAPI kbKernBase kbprb KB288216 kbAudDeveloper |
|---|
|