INFO: Running Visual Basic Applications as Windows NT Services (175948)

SUMMARY

Microsoft does not currently recommend, and does not support, running Visual Basic applications as Microsoft Windows NT, Windows 2000 and Windows XP Services because the applications may exhibit unstable behavior when installed and run as Microsoft Windows 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 Partner or the Microsoft fee-based consulting line at (800) 936-5200. For more information about Microsoft Certified Partners, please visit the following Microsoft Web site:

http://www.microsoft.com/partner/referral/

For more information about the support options that are available and about how to contact Microsoft, visit the following Microsoft Web site:

http://support.microsoft.com/default.aspx?scid=fh;EN-US;CNTACTMS

MORE INFORMATION

Examples of Unstable Behavior

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.
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.
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.
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:
198607 PRB: Access Violation in VB Run-Time Using AddressOf

Why This Unstable Behavior Occurs

A service in Microsoft Windows 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, Windows 2000 and Windows XP 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 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

NOTE: Microsoft does not recommend, and does not support, running Visual Basic applications as Microsoft Windows NT, Windows 2000 and Windows XP Services, even when you use Ntsrv.ocx.

Other Technologies

Developers can expect difficulties with efforts to employ Microsoft technologies such as ODBC, DCOM, OLE Automation, and DAO in a Microsoft Windows Service written in Microsoft Visual Basic. For this reason, and for those reasons already noted, Microsoft advises developers to avoid using these technologies in a Microsoft Windows NT Service written in Microsoft Visual Basic.