Windows Services和stdout似乎不起作用 [英] Windows Services and stdout does not seem to work

问题描述

使用一个工具包，该工具包获取对std :: out的引用，然后输出一些调试信息.这将导致0xc0000005.我不是Windows上的佼佼者，我的经验更多是在linux平台上.

我已经设法将软件作为.exe移植到Windows上，并且工作正常.但是，当我将它包装在msdn的示例Windows服务代码中时，它在输出到stdout时出错.

令人反感的行在dcmtk consap.cc
中

Hi,

Using a toolkit which get a reference to std::out and then outputs some debug. This causes a 0xc0000005. I am not the best at windows, my experience is more on a linux platform.

I have manage to port the software to windows as an .exe and it works fine. However when I wrapped it in the sample windows service code from the msdn it fault on outputting to stdout.

The offending lines were in the dcmtk consap.cc

log4cplus::tostream& output = (logToStdErr ? ofConsole.lockCerr() : ofConsole.lockCout());
output << "I will not crash"

认为大致是cout << "I will not crash" or cerr << "I will not crash"

Iain

Which is think is roughly cout << "I will not crash" or cerr << "I will not crash"

Iain

推荐答案

Windows服务不应以这种方式工作.您可以写入文件(注意权限，服务在特殊帐户中运行，具体取决于安装方式，但您也可以将其安装为以经过身份验证的用户身份运行)或系统日志(即由OS保证的首选日志记录方法).

Windows服务通常通过网络套接字或命名管道进行响应和通信，但是可以使用任何其他IPC原语.当一个进程作为Windows服务运行时，它不能直接与UI或控制台一起使用，这有一个很好的原因:当没有人登录，没有UI或控制台可用时，该进程就会运行.

有时，某些UI用于控制正在运行的Windows Service进程，但是-这是这样:您有一个单独的进程，该进程充当用于控制Windows Server进程的特殊客户端.它甚至可以与Windows Service应用程序构建为同一应用程序(这是我的方法)，但仍可以在特殊的交互模式下作为单独的进程运行.

例如，用于Windows的Apache在系统托盘中有一个应用程序.此启用UI的进程用于与Apache Windows Service通信以跟踪其状态并发送诸如Start/Stop/Restart之类的命令.

因此，解决问题的方法是重新设计代码，使其按照我刚才描述的方式工作.正确的方法是将纯服务代码与代码彻底隔离，具体取决于平台，与操作系统的交互以及控制过程.


如果您需要等待文件，请不要等待等待！您可以使用类System.IO.FileSystemWatcher以事件驱动的方式进行操作；它将通知您有关您要订阅的文件系统更改.

—SA

Windows Service is not supposed to work this way. You can write to a file (be careful about permission, the services are run in special accounts, depending on how to install it, but you can install it to run as an authenticated user as well), or the System Log (which is the preferred method of logging guaranteed by OS).

A Windows Service typically responds and communicates through network sockets or named pipes, but any other IPC primitive can be used. When a process is run as a Windows Service, it does not work with UI or console directly, for a good reason: such process runs when nobody is logged in, when no UI or console is available.

Sometimes some UI is used to control a running Windows Service process, but — here is how: you have a separate process which act as a special client used to control the Windows Server process. It can be even built as the same application as the Windows Service application (this is my approach), but still run as a separate process, in a special interactive mode.

For example, Apache for Windows has an application sitting in the System Tray; this UI-enabled process is used to communicate with Apache Windows Service to track its status and send commands like Start/Stop/Restart.

So, the resolution of your problem would be to re-design your code to work in the manner I just described. Right approach would be a thorough separation of pure service code from the code depending on the platform and interaction with OS and controlling process.


If you need to wait for files, don''t do spin-wait! You can do it in event-driven way using the class System.IO.FileSystemWatcher; it will notify you about file system changes you want to subscribe for.

—SA

伊恩，

看一下 ACE [

Hi Iain,

Take a look at ACE[^]

It has a very useful logging framework, including the ability to write log output to another console process - something that is very useful when you are working on windows services.

Under the

(ACE_ROOT)\ examples \ NT_Service下，您将找到一个非常好的示例，说明了日志记录以及如何使用该框架实施Windows服务.该框架还具有用于处理配置文件的非常灵活的机制:)

要监视目录，可以使用 ReadDirectoryChangesW [ CreateProcess [ ^ ]简单的Windows服务，传递 STARTUPINFO [ CreateFile [此处详细了解Windows服务 [ ^ ]

问候
Espen Harlinn

(ACE_ROOT)\examples\NT_Service you will find a very nice example illustrating both logging, and how the framework can be used to implment a windows service. The framework also has a very flexible mechanism for dealing with configuration files :)

To monitor a directory you can use ReadDirectoryChangesW[^] - this the windows api implmenting the functionality used by the System.IO.FileSystemWatcher class mentioned by SAKryukov

Update
Leave your working executable as is, and use CreateProcess[^] from a simple windows service, passing a STARTUPINFO[^] with valid handles for hStdOutput and hStdError.

Use CreateFile[^] to create the handles hStdOutput and hStdError, this will cause your existing program to write to those handles for stdout and stderr, respectively.

Use CreateEvent to create an event object to set during the stop event and monitor the process handle and the event to determine when to stop your program.

You can read more about Windows services here[^]

Regards
Espen Harlinn

这篇关于Windows Services和stdout似乎不起作用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！