Link to home
Start Free TrialLog in
Avatar of arvind_cs
arvind_cs

asked on

NT Service

I get the following error while trying to stop a service from control panel/services applet in Windows NT-4.0 environment. I have not used MFC.

"Error 0109: The pipe has been ended". I do not see any errors in EventLog and everything else seems to be fine.

What's going on? Can someone help?

Thanks!
Avatar of jkr
jkr
Flag of Germany image

This usually happens when a service does not report the "stopped" state to the SCM by calling

SERVICE_STATUS          ssStatus;       // current status of the service
SERVICE_STATUS_HANDLE   sshStatusHandle;

ssStatus.dwCurrentState = SERVICE_STOPPED;
ssStatus.dwWin32ExitCode = 0;
ssStatus.dwWaitHint = 0;
ssStatus.dwCheckPoint = 0;
SetServiceStatus( sshStatusHandle, &ssStatus);
Avatar of arvind_cs
arvind_cs

ASKER

No, that code exists! I get the error despite that.
No, that code exists! I get the error despite that.
Is there any message box or blocking code is there?
No message box. This is a NT service, there can be no message boxes even if I wanted to display one. NT Services, by definition, cannot have user interfaces.
U can use dialogs or messageboxes by specifying

SERVICE_INTERACTIVE_PROCESS with

SERVICE_WIN32_OWN_PROCESS  or SERVICE_WIN32_SHARE_PROCESS


if this flag is not specified SERVICE_INTERACTIVE_PROCESS

MessageBox or dialog creation will create error
This is OT, but 'MessageBox()' with MB_SERVICE_NOTIFICATION would do it also :o)
It sounds like it may not be a Service problem but rather a problem with the access of a thread from a pipe after it has been closed.

Resolution:
 1)Check that all network operations e.g. File, Database etc Access has stopped before terminating your service thread (SERVICE_STOP).
 2)Confirm that you are not experiencing a hardware issue.  
Question:
 1)What external resource are you trying to access?
job_s and jkr: this service would run from an unattended NT Server so displaying message box is not an option - it is a kludgy way to do things anyway (who'd be there to click on OK buttons on message boxes?). Besides, what's the point? How are message boxes related to my problem? :-)

Wildfire: you are on the button...my service is multithreaded so it is definitely a pipe issue. I have taken care to close all resources and I terminate threads on event by WaitForMultipleObjects.




>>job_s and jkr

You misreaad my comment - it said 'OT' :o)
jkr: OT?! = On Target? or = Over the Top? or = OhwhatTheheck?  :-)

...just kidding..:-)

It is extremely hard to debug a service. Any ideas apart from inerting timestamps into a log-file at suspect points in code?
OT = off topic :o)

To get back to to your problem - set the service to "interact with the desktop" and issue a "DebugBreak()" from your code at a point of interest. That should start the debugger on *your* desktop.
ASKER CERTIFIED SOLUTION
Avatar of Wildfire
Wildfire

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
>>The best way to debug a service is to attach to the
>>Visual C++ debugger while the service is running.
>>To do this, start the service, obtain the process
>>identifier, and then connect the debugger to the running
>>process.

That'sm mainly what I explained above. Witth the subtle difference that you have to allow the service to "run" on the user's desktop, otherwise VS will show up on the "invisible" service's desktop, which is not really helpful...
Thanks for answering in detail. I agree with you that messageboxes are not the way to go in services. A message-box blocks execution for that thread until it is dismissed so I would not be able to replicate the 'natural' sequence of events. Logging into eventlog is a better approach but unfortunately I cannot get precision details about the exact timing upto millisecond in the eventlog. I feel that my 'pipe-ended' problem is primarily a timing issue with respect to how and when exactly I inform the scum that I'm quitting the service.

I am not sure if I would be able to debug much using this technique since I would not be able to dig into the scum anyway but I will give you the points as you described an approach that could lead me on to finding more clues.