Article:
 |
|
Debugging Windows Services
|
| Subject: |
|
It's not either/or, it's both |
| Date: |
|
2003-09-04 13:23:17 |
| From: |
|
kez_higgins
|
|
|
|
Wrapping your service up and running as a normal application is *not* the same as running as an actual service.
Services run with different priviledges to to user applications. They, generally anyway, can't interact with the desktop. If you're using COM to talk to another service there are security issues which may means your code will work as a service but not as an application (or vice versa). It affect interprocess communication via mutexes or events. That code you spent all week gleaming up, might plain not work as a service. I happned to me not three days ago, so I speak from uncomfortable experience here :)
It's true that attaching to a running service can be a bit fiddly, and you can't see what happens during start up, but sometimes it really is the only way to get a handle on what's happening.
|
Showing messages 1 through 1 of 1.
-
It's not either/or, it's both
2004-03-02 10:26:49
amatlock
[View]
I think that a combination of several approaches is optimal. I agree that the only way to accurately ensure that the code is going to execute properly is to debug it running as a service like kez_higgins says. I also spawn a new thread to execute my start up code like blowery mentions.
However, I take one more step and add a conditionally executed DEBUG block of code that causes the new thread to sleep for 10 seconds. This gives me enough time to attach to the process and step through the startup code if necessary.