Console output from within a service

Peter Fröhlich

unread,

Jan 23, 2001, 5:38:16 AM1/23/01

to

Hi,
I've build a NT/W2K-service. Now I want to allocate a console for debugging
purposes. The service's account has admin rights.
I switched to Winsta0\Default, added the appropriate ACEs to it (as I did
befor for other services) and called AllocConsole().
AllocConsole() et. al. seem to work properly but the problem is: the console
window is never displayed on the desktop!

What's wrong?

Luc Kumps

unread,

Jan 23, 2001, 7:50:51 AM1/23/01

to

Have you indicated "Allow interaction with desktop" in Control Panel,
Services, Startup?

Luc

"Peter Fröhlich" <me...@online.de> wrote in message
news:94jmvn$rmd$07$1...@news.t-online.com...

Peter Fröhlich

unread,

Jan 23, 2001, 11:06:09 AM1/23/01

to

No I didn't, cause 'Interaction' with the Desktop is only allowed for the
LocalSystem account.
LSys hasn't network access besides NullSessions - that's not acceptable.
I could Impersonate LoggedOUser(), but this doesn't load the UsersProfile
afaik.

"Luc Kumps" <NOkum...@pandora.be> schrieb im Newsbeitrag
news:L6fb6.257547$MA1.8...@afrodite.telenet-ops.be...

Jarmo Muukka

unread,

Jan 23, 2001, 12:08:28 PM1/23/01

to

This can be done with few lines of code. I debug my services inside Visual
Studio. I have #ifdef _DEBUG in my class library and it is a console
application in debugging and true service when Release version is compiled.
My approach is not perfect though. When I'm debugging, I don't have enough
rights to call e.g. LogonUser().

In a service you could create an extra thread, attach it to current desktop
with SetThreadDesktop() (please, do not hardcode window station and desktop.
Use OpenInputDesktop()) and then AllocConsole(). I haven't tried this, but
it could work.

--
JMu

"Peter Fröhlich" <me...@online.de> wrote in message
news:94jmvn$rmd$07$1...@news.t-online.com...

Peter Fröhlich

unread,

Jan 23, 2001, 3:05:13 PM1/23/01

to

Thanks for your suggestions, Jarmo. I already did this (#ifdef'ing around
crucial parts), but a (console) program does
not exactly behave like a service.

Maybe I didn't explain my purpose detailed enough: primarily I don't want to
supply real debug infos, but some logging
infos for service technicians to verify that the service is running well
without the hazzle of analyzing large logfiles.
Besides that I could ask a customer to read the content of a console window
but I can't request them to read large logs :-)

I already tried the approach with SetThreadDesktop in the interactive
Winsta0 - but it didn't work: AllocConsole() succeeded but the console
window was never displayed on the screen.

"Jarmo Muukka" <jarmo.muukka@helsoftreplacewithdotfi> schrieb im Newsbeitrag
news:e3glc8VhAHA.1324@tkmsftngp05...

Steve Feldman

unread,

Jan 23, 2001, 3:20:56 PM1/23/01

to

Hi,

A technique I employ in all my services, and it works as well from GUI
programs as well, is the use of a named pipe.

I have a simple named pipe server program I start in a separate window
that listens on a specific (or specified on cmd line) pipe name and
waits for a connection. When it receives one, it simply prints all data
it receives to its console.

From inside the service program, I do fopen ( "\\\\.\\pipe\\pipename",
"w" ) and subsequently use fprintf() to output debug stuff to the other
window. It works very well. You could, of course, #define it in/out
based on whether your build should allow for debug info or not.

Steve