DOCUMENT:Q175948 25-JUN-2002 [vbwin] TITLE :INFO: Running Visual Basic Applications as Windows NT Services PRODUCT :Microsoft Visual Basic for Windows PROD/VER::4.0,5.0,6.0 OPER/SYS: KEYWORDS:kbtophit kbOSWinNT kbVBp kbVBp400 kbVBp500 kbFAQ kbVBp600FAQ kbVBP500FAQ ====================================================================== ------------------------------------------------------------------------------- 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 2002.