Windows Service Timed Action

[d000hg]

It would have to be running long enough to attach a debugger I guess, plus the server it is running on is in NY and the connection from my machine is laggy.

Can't you do the standard thing of while(!debugFlag)sleep(100) and put a breakpoint - so it gives you plenty of time to attach a remote debugger? I do this in C++ where we have all kinds of processes spawned by COM, etc.

I don't think you answered my question - does the process terminate between C&D? If it's running as a service, do you not get service start/stop/fail events logged by Windows that you can check out?

e.g: logging - Are there any log file about Windows Services Status? - Stack Overflow

[suityou01]

Can you fake the outputs of ABC so that it doesn't have to do it?

How does C# handle exceptions within exception handling? In C++ it can cause the whole process to abort...

I think you probably need to break down D() with lots of logging to work out where it stops.

D stops at the very first line AFAIK

PSeudoCode

Tick_Event()
{

    try{
        LogEvent("I'm getting started");
        DoA();
        LogEvent("Done A");
        DoB();
        LogEvent("Done B");
        DoC();
        LogEvent("Done C"); //Gets this far
        DoD(); //Doesn't seem to step into this function, rather just pops off the stack
        LogEvent("Done D");
    }
    catch (Exception dragon)
    {
        LogEvent("Uh oh" + dragon.ToString());
    }
}

private DoD(){

    LogEvent("I'm doing D"); //Never hits this line

}

[suityou01]

Can't you do the standard thing of while(!debugFlag)sleep(100) and put a breakpoint - so it gives you plenty of time to attach a remote debugger? I do this in C++ where we have all kinds of processes spawned by COM, etc.

I don't think you answered my question - does the process terminate between C&D? If it's running as a service, do you not get service start/stop/fail events logged by Windows that you can check out?

e.g: logging - Are there any log file about Windows Services Status? - Stack Overflow

OK, good thought. Yes I have 60 seconds to attach a remote debugger. I think I did answer your question in that to remotely debug over a laggy connection to NY is not really feasible. I will try of course.

Yes the process terminates after calling C, and then writing to the event log. Then it does not call D.

[VectraMan]

I also know C++ so know what you mean. In C Hash land, we are bottle fed. The code is called "Managed code", which means as long as you play nice and only use .net functions all objects are garbage collected and it's all nice. The moment you make an API call, say, then you are stepping outside managed code and there be dragons.

This is all managed code. There is no place to roam other than the next instruction, or the exception handler. To just stop like this is most odd.

Oooh "managed code" - I've never heard of that before.

You have absolute faith that the language/platform can only work a certain way, even though it patently isn't. What does that tell you?

I think you need to stop telling yourself what's happening can't be happening, and get on with debugging it.

[suityou01]

You do realise this is why I asked what D is doing, specifically if it involved unmanaged code

We commented out the guts of D, so it does

DoD()
{
    LogEvent("Doing D");
    /*
    Guts and not glory
    */
   LogEvent("Finished Doing D");
}

With the guts commented out it runs ok, and now both LogEvents fire.

[suityou01]

Can you fake the outputs of ABC so that it doesn't have to do it?

How does C# handle exceptions within exception handling? In C++ it can cause the whole process to abort...

I think you probably need to break down D() with lots of logging to work out where it stops.

Oooh "managed code" - I've never heard of that before.:rolleyes:

You have absolute faith that the language/platform can only work a certain way, even though it patently isn't. What does that tell you?

I think you need to stop telling yourself what's happening can't be happening, and get on with debugging it.

Erm

Getting under the bonnet with how the CLR handles the exceptions would require better debuggers than I currently have at my disposal. Namely SOS.dll and the Windows debugger.

[d000hg]

VM are you thinking along the lines of Windows structured exceptions Vs C++ exceptions? That crossed my mind as a way a C++ app can still crash even though you have catch(...) but whether that translates to .NET I have no clue.

Maybe .NET API methods which merely wrap WinAPI calls can still crash and burn this way, but that doesn't sound too likely. Sorry to digress Suity...

I still reckon looking for automatic logging of service failure events is worth checking.

[jmo21]

We commented out the guts of D, so it does

DoD()
{
    LogEvent("Doing D");
    /*
    Guts and not glory
    */
   LogEvent("Finished Doing D");
}

With the guts commented out it runs ok, and now both LogEvents fire.

good to see you're getting somewhere.

Now start uncommenting until you find the culprit.

[VectraMan]

VM are you thinking along the lines of Windows structured exceptions Vs C++ exceptions? That crossed my mind as a way a C++ app can still crash even though you have catch(...) but whether that translates to .NET I have no clue.

Not structured exceptions (that's a whole different can of worms), but the way it'll abort if something causes an exception during the stack unwinding phase of exception handling. I.e. a destructor throws an exception. In .NET you can't have objects on the stack, but you can use using to do the same thing. If an exception is thrown inside a using it'll automatically call Dispose before it gets to the exception handler, so then what happens if Dispose throws an exception?

And I'd always translate structured exceptions to C++ exceptions so catch(...) does catch them and the program can continue after access violations and the like. But that may well be Visual C++ specific.

[suityou01]

Yep getting somewhere and grateful for all of your thoughts.
What is weird is how the code seems to look ahead before it fails.

So in DoD() the commented out lines means the first instruction to log to the event log now fires. Comment them back in and it doesn't fire.

Or alternatively what I was thinking that the function in it's entirety fails to be hauled onto the stack with the code commented in, which means some kind of early binding problem which just ain't there. If for example the function took a strongly typed object for example, but it doesn't.

Anyway it looks like cheese slice has a solution over in general.