Click here to Skip to main content
15,558,083 members
Please Sign up or sign in to vote.
4.00/5 (1 vote)
See more:

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

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

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

Updated 3-Mar-11 19:47pm

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.

Share this answer
Iain Wiseman 4-Mar-11 1:47am    
Many thanks for replying and the advice.

I am looking to process files which arrive in configurable directory. This process sits and waits for files. If not a service what would you use. The standard out is for debugging to a file.

Sergey Alexandrovich Kryukov 4-Mar-11 2:23am    
This is simple: read my update (after [EDIT]) -- this is ready-to-use solution.
Iain Wiseman 4-Mar-11 1:48am    
Perhaps a c# app which calls the .exe may work for me. Basically it reads an xml files and produces a result.
Sergey Alexandrovich Kryukov 4-Mar-11 2:27am    
What do you mean "calles .exe"? (there is not a call to a file) You mean starting a process from the Service using executable file? Listen to a good advice, save yourself from some trouble. Do all in you service (a separate thread, of course). If you don't do it all in the service, better give up and develop the regular application. But I feel you really need a service. Look, running any file is the same as interactive. Makes no sense and will cause problems.
Espen Harlinn 4-Mar-11 3:15am    
Good reply
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 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

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[^]

Espen Harlinn
Share this answer
Iain Wiseman 4-Mar-11 15:08pm    
I have a binary which works on windows and linux. In Linux I use upstart to run it. myBinary.exe > MyBinary.log. I do not want to write lots of code just to make it work in window using a service. It already works in a DOS prompt doing the same. All I want is to run it when the machine starts on a permanent basis. I thought that Services did this but it appears that they do so long as you do not use cout. If cout is a limitation of running a service can people tell me how to avoid it with the least code as this must run on linux
Espen Harlinn 5-Mar-11 12:56pm    
I believe this was a fairly simple recipe for solving your problem, so a vote of 1 was a bit surprising :)
Sergey Alexandrovich Kryukov 6-Mar-11 18:58pm    
This is very reasonable considerations and advices, could be down-votes by a complete idiot; this happens ofter these days.
My vote is certainly 5, and not just to counter-act the low vote.
Espen Harlinn 8-Mar-11 11:50am    
Thanks SAKryukov, very much appreciated :)

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900