INFO: Running Visual Basic Applications as Windows NT Services

ID: Q175948


The information in this article applies to:
  • Microsoft Visual Basic Learning, Professional, and Enterprise Editions for Windows, versions 5.0, 6.0
  • Microsoft Visual Basic Standard, Professional, and Enterprise Editions for Windows, version 4.0


SUMMARY

Microsoft does not currently recommend, and does not support, running Visual Basic applications as Microsoft Windows NT Services because the applications may exhibit unstable behavior when installed and run as Microsoft Windows NT Services. Microsoft Visual Basic 4.0 does not support callbacks nor is Visual Basic 4.0 thread-safe. While Visual Basic 5.0 and 6.0 is apartment-model thread-safe, there is no way to marshal calls back into a Visual Basic program through the AddressOf operator. This behavior is by design. This article includes some examples of this unstable behavior, a short explanation of the possible causes of the instability, and a possible workaround. Microsoft provides programming examples for illustration only, without warranty either expressed or implied, including, but not limited to, the implied warranties of merchantability and/or fitness for a particular purpose. This article assumes that you are familiar with the programming language being demonstrated and the tools used to create and debug procedures. Microsoft support professionals can help explain the functionality of a particular procedure, but they will not modify these examples to provide added functionality or construct procedures to meet your specific needs. If you have limited programming experience, you may want to contact a Microsoft Certified Solution Provider or the Microsoft fee-based consulting line at (800) 936-5200. For more information about Microsoft Certified Solution Providers, please see the following page on the World Wide Web:

http://www.microsoft.com/mcsp/
For more information about the support options available from Microsoft, please see the following page on the World Wide Web:

http://www.microsoft.com/support/supportnet/overview/overview.asp


MORE INFORMATION

Examples of Unstable Behavior

  1. When a Microsoft Visual Basic application displays a dialog and then terminates, the name of the .EXE file disappears from the Services applet dialog, but the Visual Basic application dialog leaves behind a gray rectangle on the user interface.


  2. When the Microsoft Visual Basic application is launched from a service, the .EXE file name briefly appears in the Services applet dialog but the Visual Basic application does not seem to launch.


  3. Microsoft Visual Basic applications that are OLE Servers will return read-only properties successfully and, when the OLE Server terminates, the .EXE file name disappears from the Services applet dialog. Yet, subsequent attempts to instantiate that OLE Server fail with OLE automation errors or the Services process will hang.


  4. An error message appears because the callback function is called by a thread that was not created by Visual Basic. Some API functions use a free threading model. Visual Basic only supports apartment model threads. For additional information about this behavior, click the article number below to view the article in the Microsoft Knowledge Base:
    Q198607 PRB: Access Violation in VB Run-Time Using AddressOf


Why This Unstable Behavior Occurs

A service in Microsoft Windows NT is a program that is written as a console application and runs whenever the operating system is running. Services are commonly employed to provide facilities such as directory replication, system activity auditing, process monitoring, or communications support.

Services log on to Microsoft Windows NT under the LocalSystem account, which is a predefined local account used by system processes.

A service that runs in the context of the LocalSystem account inherits these characteristics:
  • The service cannot open the registry key HKEY_CURRENT_USER.


  • The service can open the registry key HKEY_LOCAL_MACHINE\SECURITY.


  • The service has limited access to network resources, such as shares and pipes, because it has no credentials and must connect using a null session.


  • If the service opens a command window and runs a batch file, the user could hit CTRL+C to terminate the batch file and gain access to a command window with LocalSystem permissions.


  • The service cannot share objects with other applications unless they are opened using a DACL, which allows a user or group of users access, or NULL DACL, which allows everyone access. Specifying a NULL DACL is not the same as specifying NULL, which means that access is only granted to applications with the same security context.


  • Service programs that require anything more than a brief moment to perform necessary initialization may be required to create another thread to do the common initialization while the main thread continues with processing.


By convention, Microsoft Windows NT Services are designed to be non-interactive. That is, in most cases, they do their work without any user interaction. Services are usually configured and controlled with an applet installed in the Control Panel. This requires that the programmer add code to provide for these additional requirements:
  • Report warnings and errors in the system or application logs. You typically can't use output to the screen because there may be no user logged on.


  • Control the service through a separate application or through a Control Panel applet. This involves implementing a communication mechanism for your service.


  • Install and remove the service from the system.


However, with Microsoft Visual Basic 4.0, the possibility remains that your application will eventually post an unhandled error dialog from the Services process which will hang the Microsoft Visual Basic application.

The Unattended EXE compile option available with Microsoft Visual Basic 5.0 and 6.0 does address the unexpected dialog problem, but thread safety remains an issue. Visual Basic 5.0 and 6.0 is apartment-model thread- safe unless or until a program uses the AddressOf operator. There is currently no way for Visual Basic to marshal multiple calls back into a Visual Basic 5.0 or 6.0 application through the AddressOf operator. Therefore, we do not recommend installing a Microsoft Visual Basic application as a Microsoft Windows NT Service.

Workaround

The Microsoft Technical Article, "NT Service: An OLE Control for Creating Windows NT Services in Visual Basic," describes an OLE Control that enables developers to create Visual Basic applications that function as Microsoft Windows NT services. With the NTService control, you can install a service, log events, and respond to start, stop, pause, and continue events. You can find this article at the following Web site:
http://msdn.microsoft.com/library/techart/msdn_ntsrvocx.htm

Other Technologies

Developers can expect difficulties with efforts to employ Microsoft technologies such as MAPI, ODBC, DCOM, OLE Automation, and DAO in a Microsoft Windows NT Service written in Microsoft Visual Basic. For instance, MAPI contains user interface elements that must be anticipated and suppressed, and may require access to parts of the registry that are either unavailable to a service or require a special security context for use.

For this reason, and those already noted, Microsoft advises developers to avoid using these technologies in a Microsoft Windows NT Service written in Microsoft Visual Basic.


REFERENCES

For more information, see the following directory on MSDN:

\Platform SDK\Windows Base Services\Executables\Services
For more detailed information on "Using MAPI from a Windows NT Service", refer to:
http://msdn.microsoft.com/isapi/msdnlib.idc?theURL=/library/psdk/mapi/book_9jqc.htm
For additional information, please click the article numbers below to view the articles in the Microsoft Knowledge Base:
Q198607 PRB: Access Violation in VB Run Time Using AddressOf
Q170883 HOWTO: Use NTSVC.OCX from Visual Basic
Q150777 INFO: Descriptions and Workings of OLE Threading Models
Q137890 HOWTO: Create A User-Defined Service

Additional query words:

Keywords : kbNTOS kbVBp kbVBp400 kbVBp500 kbVBp600FAQ kbVBP500FAQ
Version : WINDOWS:4.0,5.0,6.0
Platform : WINDOWS
Issue type : kbinfo


Last Reviewed: December 15, 1999
© 2000 Microsoft Corporation. All rights reserved. Terms of Use.