KnowledgeBase Archive

An Archive of Early Microsoft KnowledgeBase Articles

View on GitHub

Q175948: INFO: Running Visual Basic Applications as Windows NT Services

Article: Q175948
Product(s): Microsoft Visual Basic for Windows
Version(s): 4.0,5.0,6.0
Operating System(s): 
Keyword(s): kbtophit kbOSWinNT kbVBp kbVBp400 kbVBp500 kbFAQ kbVBp600FAQ kbVBP500FAQ
Last Modified: 25-JUN-2002

-------------------------------------------------------------------------------
The information in this article applies to:

- Microsoft Visual Basic Professional Edition for Windows, versions 4.0, 5.0, 6.0, used with:
   - the operating system: Microsoft Windows 2000 
   - the operating system: Microsoft Windows XP 
   - the operating system: Microsoft Windows NT 4.0 
- Microsoft Visual Basic Enterprise Edition for Windows, versions 4.0, 5.0, 6.0, used with:
   - the operating system: Microsoft Windows 2000 
   - the operating system: Microsoft Windows XP 
   - the operating system: Microsoft Windows NT 4.0 
- Microsoft Visual Basic Standard Edition for Windows, version 4.0, used with:
   - the operating system: Microsoft Windows 2000 
   - the operating system: Microsoft Windows XP 
   - the operating system: Microsoft Windows NT 4.0 
-------------------------------------------------------------------------------

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
-----------------------------

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 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.

REFERENCES
==========

For more information, see the following directory on MSDN:

  \Platform SDK\Windows Base Services\Executables\Services

For more information, refer to the following book:

  Francesco Balena Programming Microsoft Visual Basic 6.0
  (http://go.microsoft.com/fwlink/?LinkId=8386 ), Microsoft Press, 2001

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          : kbtophit kbOSWinNT kbVBp kbVBp400 kbVBp500 kbFAQ kbVBp600FAQ kbVBP500FAQ 
Technology        : kbVBSearch kbAudDeveloper kbZNotKeyword6 kbZNotKeyword2
Version           : :4.0,5.0,6.0
Issue type        : kbinfo

=============================================================================

THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Copyright Microsoft Corporation 1986-2002.