Windows Service Debugging - TEARING HAIR OUT !!!

[Mr Newbie]

Im going insane trying to sort this out. The following code has been tested
and works fine ( without the Diagnostic.Debugger.Break() line of course, on
windows forms application ). In a windows service ( Assembly has full
trust ) and with the Debugger line in, if Im lucky and it doesent lock up, I
get to line *************** HERE ********** and it Gives me the message that
the Service has shutdown, because it does this when there is no work to do.

How the hell are you supposed to debug this crap ????

-----------------------------

Protected Overrides Sub OnStart(ByVal args() As String)
'If file exists then read it into the TimesDS Dataset
'Otherwise, simply create and store it.
'We are using strings to represent times.


Diagnostics.Debugger.Break()

Dim fi As New System.IO.FileInfo("Times.xml")
If Not fi.Exists Then
Dim nr As Times.TimesRow = TimesDS.Times.NewRow
nr.TimeOff = "23:03:00"
nr.TimeOn = "09:00:00"
TimesDS.Times.Rows.Add(nr)
TimesDS.WriteXml("Times.xml")
Else
TimesDS.ReadXml("Times.xml")
End If

TimeOn = TimesDS.Times.Rows(0)("TimeOn") '*************** HERE
**********
TimeOff = TimesDS.Times.Rows(0)("TimeOff")
hrOn = Convert.ToInt32(TimeOn.Split(":")(0))
minOn = Convert.ToInt32(TimeOn.Split(":")(1))
secOn = Convert.ToInt32(TimeOn.Split(":")(2))
hrOff = Convert.ToInt32(TimeOff.Split(":")(0))
minOff = Convert.ToInt32(TimeOff.Split(":")(1))
secOff = Convert.ToInt32(TimeOff.Split(":")(2))

Timer1.Interval = 2000
Timer1.Enabled = True


End Sub

 

[Roger Rabbit]

Chill out baldy someone here will help you out.

 

[Phill. W]

Im going insane trying to sort this out. The following code has
been tested and works fine (without the Break() line of course,
on windows forms application ). In a windows service with the
Debugger line in, if Im lucky and it doesn't lock up, .. . .
Protected Overrides Sub OnStart(ByVal args() As String)

I suspect what's happening is that the Service is running, attempting
to execute the Break and issuing a Dialog into the virtual, invisible
Desktop on which Services run. Since you can never get at this
"desktop", you can't answer the dialog, so the service appears to
"lock up".

It is extremely fiddly to debug OnStart - the rest of the Service is
far, /far/ easier to get at. Instead of the Break statement, try this

Protected Overrides Sub OnStart(ByVal args() As String)

#If DEBUG Then
Threading.Thread.Sleep( 10000 )
#End If

(BreakPoint on) Dim fi As New System.IO.FileInfo("Times.xml")
. . .

Start the Service, then go back into Visual Studio and attach the
debugger to the now-running Service process. With the Sleep
in there, you should have time to attach to the process /before/ it
gets as far as the BreakPoint, which it should stop on.

HTH,
Phill W.

 

[Mr Newbie]

Yep, I tried this, in fact I tried this at the beginning before I found out
about the Diagnostics.Debug . . .

comamnd, howeverm it still give me this crap message and simply stops the
service. I tried removing all code from the OnStart sub and only
breakpointing the code in the Timer1.Tick event but it never ran the event.

If writing a service is this difficut then I really think its not worth it.

 

[Chris Dunaway]

breakpointing the code in the Timer1.Tick event but it never ran the event.

What kind of timer are you using? If you are using a
Windows.Forms.Timer, then that is likely part of the problem. You need
to use either the System.Threading.Timer or the System.Timers.Timer.

 

[Mr Newbie]

Ahh, I am using the aforementioned Windows.Forms.Timer as a matter of fact.
I will try one of the others, but I am curious as to why it would allow me
to add these to the design canvass if it does not expect them to work.

 

[Chris Dunaway]

I suppose, technically, you can make it work with a Windows service if
you allow the service to interact with the desktop, but it's not
recommended.

 

[Mr Newbie]

Thanks Chris.

I has some success with simply writing to a file, however, when I want to do
anything more complex the bloody things simply falls over for no apparent
reason with stuff which has been tried and tested already ( No interaction
with the desktop I might add ).

I'll keep trying, but my overall opinion is that this sucks big time, and
its probably one of those items which if you know all the rules you would be
OK, but if not you are snookered.

There does not seem to be much data out there I have to say most general
books dont seem to give it much treatment.

Thanks - Mr Newbie.

 

[Brian Gideon]

Mr Newbie,

The System.Windows.Forms.Timer works by posting windows messages. For
it to work the thread that created the timer must have a message loop.
By default services do not create the message loop. You could,
theorectically, create the message loop by calling Application.Run and
expect the timer to work then.

In your case the System.Threading.Timer or System.Timers.Timer would be
a much better choice.

Brian

 

[Mr Newbie]

Thanks Brian,

I have used the System.Timers.Timer class which now seems to be working
fine. BUT, the reason that things were failing was not down to the
Windows.Forms.Timer( Well that could also have been a primary reason ), but
using member functions which were able to find a simple file name as an
argument and find it in the Bin directory were generating errors which I
never saw, and although the service seemed to continue to run, it had
basically stopped functioning. When I used absolute paths, this did not play
up and worked fine.

This is a whole new ball game for me, which I need to get a grip on. Not
sure if things have improved in VS2005 Services.

Regards - Mr N...

 

[Roger Rabbit]

I cant remember the last time i created a windows service however given your
still having problems despite some good answers I have to wonder why your
not using any kind of error handling "try catch finally" in which to trap
your errors and then use a simple output to the Windows event log.

I have no idea why you're having the problem you describe but debugging the
methods you posted do not require a breakpoint.

RR

 

[Mr Newbie]

Yes, I'm aware that there is a construct called Try/Catch/Finally, despite
my handle I am not a complete beginner here, the code was already tested
working.

My point was that no Unhandled Exception was thrown ( or at least
witnessed ) , and yet it caused unexpected, and to my mind unusual
occurances. The code I had written had already been tested under Windows
Forms, and worked well.

Differing environmental conditions exist for Windows Services when compared
with Windows Forms. These are what I am discovering now.

Thanks for your replys, even though neither of them actually offered any
constructive help.


Regards Mr N . . .

 

[Roger Rabbit]

try catch finally is not a debugging only construct. You dont take it out
once you deploy?
A suggestion of logging to the Event Viewer for a Windows Service is about
as constructive as i can be given that your break point option has you
tearing your hair out.

RR

 

[Mr Newbie]

Yes, I'm aware that there is a construct called Try/Catch/Finally,See, I didnt say it was a 'debugging only' construct.

Never mind, thanks anyway. I'll find my own way through this.


Regards Mr N

 

[Mr Newbie]

If you had of had some exception handling in the runtime code you posted
then you could have caught the resulting exception. Looking at one of your
posts above it might have been a file exception resulting from the fact
that
you were using a relative path in a windows service.

Yes, ive already said this.


Lets just end this, as we are not really making any ground here.

 

[Roger Rabbit]

Yes, ive already said this.

You did? Oh sorry that must have been on one of the other 3 threads you
started on the problem. I must of missed it. I thought you had instead
dismissed the idea of some exception handling and logging as "non
constructive".

Each to his own then.

RR

 

[Mr Newbie]

Christ your worse than my fifteen year old son.