|
I'm working on a Windows Service and I'm looking for a straight-forward way to monitor its responsiveness while in the SERVICE_RUNNING state. I know that the Service Control Manager watches for hangs during startup with SetServiceStatus() and the checkpoint parameter, but what if the Service hangs while it's running?
I've thought about making another service to watch the service, but this seems a bit circular.
Any ideas?
Rodney
|
|
|
|
|
You ultimately have to be looking at it with something else, right?
And what can you do, or what is your goal, once you detect it is hung?
It could be sufficient to have your primary service thread (the one that MGHT hang) periodically update some counter or timestamp. A secondary thread (not likely to hang) within the same service can wake up periodically or be awoken with an event set by the first thread. It could examine the counter/time stamp. If the counter/timestamp has not bene updated 'recently' then maybe the secondary thread writes an event to the event log indicating the 'service' is hung and needs attention. Then you don't need to write two services.
An administrator can look at the event viewer to see if your service got stuck. Programs exist that can periodically scan the event log looking for particular items, and that might be sufficient to document the stuck service. There may be other things your secondary thread could do to bring attention to the stuck service.
|
|
|
|
|
Once I detect it as hung, I want to kill it and restart it. Using a counter-monitoring thread sounds good. I was also thinking of calling ::ControlService() with SERVICE_CONTROL_INTERROGATE to see if the call returns in a timely fashion, but I've heard this might not work because the Handler might still be processing commands when the rest of the service is hanging. Although, arranging the Handler to wait on an event to be set within ServiceMain() could still timeout the ::ControlService() call appropriately. Does this approach make sense, or do you think it's over-complicating things?
Rodney
|
|
|
|
|
ANY properly written Windows service should posess at least two threads. One thread does the service-specific work, and the other one services the control requests. In your case, I was proposing a third thread, which would monitor the status of your service and 'report' that it had hung. Now, I am not sure that a service can send a STOP control request to itself, this is something I have never thought to do or try. (Yoda was wrong, there is TRY and there is DO...) Anyway, you need to figure out what will 'terminate' your hung thread or cause your service to restart.
I suppose I would also encourage you to figure out why your service hangs. Is this truly unavoidable? Are you dealing with poor legacy design or something? I write and maintain a lot of code, and I don't think we have anything that we 'expect' to hang. That just does not seem right.
Maybe if you could describe for us here at CP what the underlying problem is, we could make some additional suggestions
|
|
|
|
|
Actually, my service is still relatively simple and has never hung, except when I make it do so on purpose. I'm just trying to develop defensively. At this point, my questions are "what-if". I plan on developing a service that never hangs! Never say never, though.
The three-thread approach sounds good. I figured I'd kill the hung service (as gently as possible) so that the Service Control Manager would boot it up again according to the set preferences.
One other thing, I was encountering difficulties when testing a service that hangs starting up. I was under the impression that the SCM would monitor the service and kill it if it takes too long to start up. In my case though, after two full minutes, the SCM tells me my service could not start, and then just leaves the struggling service in memory. It never actually kills it or tries to restart it. Am I misunderstanding the role of the SCM in this case?
Thanks for your responses!
Rodney
|
|
|
|
|
If you stop the service you need to restart it. The SCM will only start 'automatic' services when Windows is starting up or if another dependent serice is trying to start. At other times, you need to start it yourself.
When adjusting the service properties, I see a 'Recovery' tab in the dialog. It seems the default recovery options are to 'do nothing'. One of the choices is 'Restart Service'. Maybe you can try adjusting the options to see if you obtain a desired result.
|
|
|
|
|
Yeah, the "Recovery" options is what I meant by "set preferences" in my previous post. The "Restart" option works well when the service is killed, but restart doesn't seem to work when the service hangs during its start phase, even though I was led to believe that the SCM would kill a service unable to start up.
Rodney
|
|
|
|
|
I would have beleived the same thing, based upon all the MS documentation.
They would make you think your service is going to suffer hellfire and damnation if it does not report 'service start pending' periodically to the SCM during start up. And now your testing makes it look like the SCM does not do anything (except maybe report the service is hung or failed to start, to the event logger.
Regardless of recovery options settings, it seems your service is not killed and restarted. That sucks
|
|
|
|
|
I used the code below to create a slider control. I tried to put the code into another initialize function of my own but it wouldnt work. Can the code be put into another function?
What I really dont understand is why do I need to include:
CDialog::OnInitDialog()...to make the project run? Without it I get a run time error condition.
Jerry
/////////////////////////////////////////////////////////////Create slider control here
BOOL dialogWnd::OnInitDialog()
{
CDialog::OnInitDialog();
CWnd* pWnd = GetDlgItem(IDC_SLIDER1);
CRect rect;
pWnd->GetWindowRect( &rect );
ScreenToClient( &rect );
m_Slider.Create( WS_VISIBLE|WS_CHILD|TBS_HORZ, rect, this, IDC_SLIDER1 );
return TRUE;
}
|
|
|
|
|
Is your question why does OnInitDialog() exist or why you call it there ?
OnInitdialog contains initialisation code that is required by a number of functions such as Create() and DoModal().
As to why call it, your derived OnInitDialog() must call the base class function to use this code. It's that or write it again yourself.
Elaine
The tigress is here
|
|
|
|
|
The bigger question is why are you creating the slider control at run-time?
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
I wasnt sure how else to do it. I have many objects of type dlg that may or may not contain a dialog with a slider. I was attempting to create a slider dynamically only if the dialog window needed it...depending on the requirements. I dont know if I am explaining it very well, but thanks for your help.
Jerry
|
|
|
|
|
There are a few situations where a control created at run-time makes sense but this is not one of them. Add the control to the dialog's template, create a member control variable for it, and then put the following in the dialog's OnInitDialog() method:
BOOL dialogWnd::OnInitDialog()
{
CDialog::OnInitDialog();
if (some_condition)
{
m_Slider.ShowWindow(SW_SHOWNORMAL);
m_Slider.EnableWindow(TRUE);
}
else if (some_other_condition)
{
m_Slider.ShowWindow(SW_HIDE);
m_Slider.EnableWindow(FALSE);
}
return TRUE;
} Why disable a hidden control? Some folks assume that once a control is hidden, it can no longer be interacted with. Wrong. A hidden control can still receive input focus, even if you can't see it.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
Thanks...I am a SW Eng and sometimes I really struggle with MFC. Is there a place where I can get a sample dialog program that really explains all the intricate details of what is going on?? I like stepping through all the code to really understand what is happening.
You gave me some good ideas...
Have a good day.
Jerry
|
|
|
|
|
jerry1211a wrote:
Is there a place where I can get a sample dialog program that really explains all the intricate details of what is going on??
Just keep plugging away at it. Come up with a (small) problem, and then create a little application to solve it.
When I started using MFC back in 1993, I created dialog-based applications exclusively. The concept of a document and a view made no sense to me. It was not until the late 90s that the light bulb came on. Once I had a grasp of what role the document and view played, it opened up other possibilities.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
Ok sounds like a good plan.
Jerry
|
|
|
|
|
Is it valid to create document in one process and get node info in another process. What pointer I need to pass. I think pointer to COM object or interface are local process.
Thanks.
We yesterday got drunk with Bacchus ...
|
|
|
|
|
Do I need to marshal XMLDOMDocument pointer?
We yesterday got drunk with Bacchus ...
|
|
|
|
|
Do anyone have an example code on Winsock2 UDP written in C language for windows XP. Please help
Heaven's on me
|
|
|
|
|
|
<br />
CMenu menu;<br />
CMenu *sub=NULL;<br />
VERIFY(menu.LoadMenu(IDR_MENU));<br />
sub = menu.GetSubMenu(0);<br />
UINT state = sub->GetMenuState(IDC_CHOICE, MF_BYCOMMAND);<br />
ASSERT(state != 0xFFFFFFFF);<br />
if(state & MF_CHECKED)<br />
{<br />
sub->CheckMenuItem(IDC_CHOICE, MF_UNCHECKED);<br />
}<br />
else<br />
sub->CheckMenuItem(IDC_CHOICE, MF_CHECKED);<br />
Why doesn't it check or uncheck my menu item? it remains as it is initially...
|
|
|
|
|
How about:
if (state & MF_CHECKED)
sub->CheckMenuItem(IDC_CHOICE, MF_BYPOSITION | MF_UNCHECKED);
else
sub->CheckMenuItem(IDC_CHOICE, MF_BYPOSITION | MF_CHECKED);
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
nope...but here is the problem...the if works, but CheckMenuItem doesn't...so the first part is good, it sees if the item is checked, but it doesn't change this thing.
|
|
|
|
|
I think I gave you the wrong code. MSDN states that a pop-up menu item must be checked by position since it does not have a menu-item identifier associated with it. Figure out what position IDC_CHOICE is in and use that for the first parameter to CheckMenuItem() .
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
Hi!
I have an SDI application which, at a certain moment, creates a child dialog box. Therefore, when the app. is active, this dialog box (which is a popup window) is the active and it's really easy to get a CWnd* to it through GetActiveWindow().
The problem arises when the user switched to another app. (using Alt+tab for example) this function returns NULL. How can I find which window was active before my app. lose focus ?
Thanks for help
|
|
|
|