Debugging windows service adding db log to catch cluase bad idea?
I'm not 100% clear on what you are trying to do when you mention both debugging and logging.
Registering in a catch clause is usually a good idea if it's part of the overall registration approach.
if you are after debugging the service you have two options - if you can control when the code you are trying to debug is from outside the service (via some external stimulus), or if you have time before the code is executed , you can just open source in VS and, if compiled in debug mode, you can plug VS into the servicing process.
Then any breakpoints set in the source code will give you access to the code debugger.
If you cannot do this (for example, if you need to debug the startup event), you can add System.Diagnostics.Debugger.Break () to your source code, which would start the debugger when this line is hit at runtime.
I usually wrap such statements in #if #endif area elements with the compiler.
source to share
In the services for which I am responsible, any errors that occur after initialization (after the code has confirmed that it can connect to the database, has access to the log file, and starts running) ends up in its log file. Errors that occur on startup or shutdown are reported to the event log.
source to share
In general, logging exceptions is a good idea. Especially when debugging services, which is always a frustrating task.
The only problem you may run into is that the log itself is throwing an exception. This happened to me when I entered the event log (see this question ). This means that you are not getting any information about the loss of service exception.
For debugging purposes, I think it's helpful to write exceptions to a local text file, optional for any other logging. This is the least likely to fail. When you're done debugging, you can remove these additional logging commands. (Well, you have to be careful not to introduce a new error while doing this ...)
source to share
It depends on the code. In some of my services, I log information to the database (because this is the policy here), but I have an additional logging mechanism that adds messages to the event log in case of a database login failure. The question you should be asking yourself is "what happens to erros if you can't connect to the database?"
source to share