Please see the comments to the question. In response to the comment by Marcus Kramer, I decided to generalize the approach you need to develop. This is easy enough:
- Where debugging is too difficult, devise a facility to make the code feasible for debugging. Not all code has to go to deployment, by the way. Development-only projects can be important, as well as skeleton prototypes.
Example: debugging of the Windows service can be difficult. It the problem persists, it's good to put most of the code in some library assembly and use it from two applications: one being Windows service, and another one, say, a console application doing basically the same job. Most bugs could be detected using just the console variant of the application.
- Where that is still difficult, log sensitive information on everything which is important or can be problematic: "before and after" such actions. Don't forget to catch all exceptions in the stack frame on the very top of the stack of each thread and make sure you always log all the comprehensive exception information at those points.
First of all, I would advice to use the class